How to measure the performance of your developers?

Most of the time, there's only one correct answer: by the value they deliver.

For years companies have tried to measure developers using all sort of hard metrics, like the number of lines of code they typed, or the bugs they fixed, or the bugs they introduced, or how early they finished. It doesn't matter how you try to slice it, every one of these metrics can (and will) be manipulated, which makes them useless.

Developers produce intellectual property. They don't have an algorithmic job where you can easily predict the path and outputs given a set of inputs. This makes it very hard to measure their job, so you need to step back and look at the big picture.

(How do you measure the performance of a musician that's writing a song, or a painter working on a mural, or a novel writer? In all these cases the only thing that matters is the final result.)

So the key is defining what "value" means for your project, and make sure whatever it is; it gradually tends to increase. (Scrum teams use "velocity" for this, in which case you add all your individuals into one single number to measure their performance.)

Getting a project back on track

Here are some specific notes to keep in mind to help a software project get back on track. Some of there might not apply to you, but take a look and see if there's something that helps you get things where you want them to be.

  1. Make sure that user stories have as much information as possible. Don't skim on details. Never think that "things are clear enough as they are."

  2. Actively find opportunities to keep the less senior members of the team busy, and the more senior folks relatively open. The more work the team is ready to delegate, the better understanding they'll have about it, and the more efficiently they'll be using their personnel.

  3. Simplify the work as much as you can. After you are done, try and simplify it again. Your goal is to maximize the amount of work not done. Keep asking the same "do we need this?" question over and over again until people get used to it (or pissed off at you).

  4. Assuming you are running Scrum and have some members working remote, make sure they fully feel part of the team and are invited to all the ceremonies just like the internal team is.

  5. Try to minimize the number of epics the team tackles every sprint. It will help them keep focused, and they'll have a better chance to finish features completely.

  6. Make sure you have plenty of work planned and ready in your backlog (Scrum practitioners usually recommend two sprints). This is the only way the team will have time to solve dependencies, avoid surprises, and have enough material to stay busy.

  7. Avoid working on new features that your stakeholders haven't fully approved. You should present as many details as possible of your planned solutions a couple of sprints ahead of time, so your client has a chance to review and approve.

  8. Stakeholders will always try to maximize the amount of work they can squeeze out of the team for the same budget. The more you can drive the project, the higher chance you'll have of keeping the team on track and avoiding death marches at the end.

  9. Try to minimize the time in meetings for the production team outside of the regular Scrum ceremonies. The more you can accomplish via email or by just involving non-production members, the more time you'll have to get work done.

  10. Making sure your next two sprints are successful is much more important than the outcome of the current sprint. If you are falling behind with your backlog, take less work today and use the time to plan for tomorrow.

When the target becomes an anchor

Target dates you are asked to hit can easily become anchors for your estimates. This could bias the way you think about the effort that will truly take to complete something.

If possible, try to come up with your estimates before a date is planted in your mind. If you know beforehand, try not to work backwards from that date because you'll increase the chances of biasing your estimates. Put the date aside, and estimate your work trying not to think about it.

Anchoring is a real threat to accurate estimation. The further away you get from it, the better the outcome will be.

An estimate is not a commitment

Just make sure everyone understands what your estimate means. You aren't committing to anything by telling someone how long you think something will take. You are just giving your best judgment about it.

One idea is to start giving your estimates as a range (from the most likely outcome to the worst case); ranges spark conversations most often than straight values. Another idea is to mention your estimate separate from your commitment: "I think it will take 2 days, so I can commit to have it in 3". A third idea is to just stall when you aren't ready to commit; ask for more time until you have an appropriate answer.

The best and worst case scenario

Some people like to talk about the best case scenario to complete their projects. Some people instead like the opposite, and they always refer to the worst case.

I think there's a better way.

The likelihood of a best case scenario happening is usually very low. You are calling it "best case" on the first place because you know something could (probably will) happen. So you make sure to label it as "best case" to properly set expectations and let people know that it won't likely happen.

If it won't happen, why do you talk about it?

The worst case scenario happens when multiple things go wrong at the same time. The interesting thing here is that, when too many things don't happen the way they should it becomes really hard to determine how they will impact the timeline, thus the worst case scenario is usually a fictitious date far enough in the future to put everyone's mind at ease. Perfect storms could happen, but our plans for them will likely be insufficient.

Again, if it won't happen, why do you talk about it?

Giving best and worst case scenarios is a simple way to dodge the real solution to the problem: a realistic plan that accounts for risks and dependencies, and covers multiple possible situations and their outcome.

Coming up with this realistic plan is hard. You can't just hide behind a date far enough in the future, nor behind the unlikely perfect picture. You have to think hard enough about the work, dependencies, and risks, connecting all of these and determining their impact and how to mitigate them.

Whenever you've done your job you'll feel confident standing behind your plan. Whenever you haven't, you'll probably try to masquerade it behind unrealistic expectations.

Protecting clients from themselves

I've always thought that is my responsibility to protect clients from themselves. If not specifically mine as an engineer, then it's definitively my team's job to help them achieve their goals.

Clients are rarely experts at software development; that's exactly why they come to us in the first place. Sometimes we forget the extent of our responsibilities and let them hurt themselves when making uninformed decisions.

Imagine you are working within a budget of 40 hours. If you chase after every single idea the client puts on the table, and end up spending the whole budget while working on superficial things, you can't just go back and blame the client for it.

Think about it: you are supposed to be on the driver's seat. You are supposed to provide support helping the client make the right decisions and tradeoffs. You are here to inform, help to understand, and provide alternatives. Is not about you shutting down every idea coming from clients, but about helping them understand the implications of implementing those ideas.

Looking at everything you do as your own offers an invaluable perspective that will help you make the right decisions. Every time I'm not sure what to do I like to force myself into thinking what would I do if I were the owner. All of the sudden answers become clearer than ever.


Today my company announced that I'll be filling the position of Director of Engineering.

At Levatas, I've always worked with very talented people, so I'm not just honored but extremely blessed for having a great team trusting me with such an important role.

It's a huge responsibility and I'll have to fill pretty big shoes, but I'm excited and can't wait to pour all the passion I've always had for this company into my new job.

Sometimes is not just about more time

Of course, the difference between finishing a 4-hour task early or being late is usually about time. "If I can only get another extra hour, I'll wrap it up for sure!"

Time is an integral part of software development (and pretty much everything else), but sometimes we use it a little bit too much to cover for our lack of understanding about processes governing our projects.

When a 6-month project finishes 3 months late, we can't just blame it on the calendar. It's the easy answer to the problem, I'm sure, but it isn't the real cause for why the project got extended 50% over the original timeline. Time is just the low hanging fruit that everyone loves to use to answer the hard questions.

In the long run, more time is not a solution by itself, but a consequence of needing to execute a different process, or to add another person to the team, or to revamp creative work, or to focus more on quality, or to spend more on upfront design. Whatever it is, that's what you need to find out; that's the real exercise we need to go through to make sure we properly fix the problem.

I'm voting for America

I'm not going to tell you for whom I will vote for on 2016. But maybe you can infer that from this post.

(Sorry for all of you who read my blog for pure technical reasons. This is not about software, but 100% about politics. You're free to skip if you desire.)

I was born in Cuba and endured 28 years of socialism. I did not come to this country just for "economic reasons" like a lot of my fellow countryman did; I came because I believe America is the best country in the world. I wanted to live in a place that fights for the rights of human beings and doesn't push personal agendas or ambitions over the well-being of its citizens. I wanted a place ruled by a common sense economical system and not the equalitarian chimera that has doomed my island for over 5 decades.

So I'm sure you will excuse me if I don't support a government that tries to bring me back to what I want to keep in the past. Today I'm an American citizen, and my vote in 2016 will not help chip away the liberty after which I uprooted my whole life.

I'm an immigrant who came here with pretty much the same as most immigrants: nada. But I didn't just ask the government for money, or free health, or started a fraud ring, or sold drugs. I started working immediately and have been making a decent living for the past 7 years. This country received me with open arms, and I want the same for everyone in the world as long as they come to do honest work and stop living off the rest.

I don't believe in government interfering with businesses in any way or enabling people to rely on welfare. I don't believe in a minimum wage and think free health and education are just nice ideas on paper but completely unreasonable and unachievable (unless you are willing to completely destroy both).

I believe in free speech. Free speech as the way it's meant in the Constitution and not the modern version that some have been trying to create. People should be able to express whatever they want, not whatever "it's appropriate" for them to say.

I believe in the Second Amendment. I'm grateful to be able to protect my family and my home. I'm also grateful to have an answer for anyone trying to do what a dictatorship regime has done in Cuba.

I came here because socialism destroyed my former country. I wanted to live guided by those principles that made this country great and I'd hate for a crooked president to keep destroying everything I came looking for.

But although you can call me "latino" or "Cuban-American", in 2016 I'm voting as another American. I'm looking out for this country, my well-being and my children. I want them to grow with the same rights I've fought really hard to get, and I really don't care who you think I'm supposed to vote for, because I'm voting for America.

The more you have, the more you should protect it

People care more about things they don't have enough of.

If you have tons and tons of money, you probably spend it less carefully than somebody who lives paycheck to paycheck. Water is more valued in California than in Florida where it rains all the time. Scarcity makes everyone think twice.

The same happens in software projects.

Teams usually get up in arms near the end, when budget is running out and deadlines are rapidily approaching. When both money and time are scarce, everyone starts thinking about them, and bend over backwards to fix the problem.

I think we can do better.

Precisely, it is at the beginning of the project where teams waste more; right when budgets are big enough and deadlines not yet in the horizon. Every decision seems inconsequential so nobody cares.

But this quickly catches up with the team. And just when everything should be coming together for a landing to successfully close the project, is when more and more pressure everyone feels from every angle.

The more you have, the harder you should work to avoid wasting it. You need to start looking at consequences right from the get go, not just when things get tight.