One hundred 1-hour tasks or one 100-hour task

Are these the same really? I know that mathematically they are, but do they represent an equivalent effort for your product?

Most of the time they don't.

On one hand, having multiple low-complexity tasks is good to keep a large team busy. You will usually find ways to parallelize the work by having different people work on different tasks at the same time. There's no reason you can't do this with only one big task, but the former is usually simpler.

Smaller estimates will also tend to be more accurate than bigger estimates, where there's a lot of hidden complexity that we can't understand until we get close enough to the work.

On the flip side, one hundred tasks are just too many opportunities to make a mistake, to harbor scope creep, to have too many balls in the air at the same time. More moving things represent more complexity.

Make sure you consider everything at play before you let math play tricks with your estimates.

Estimates vs. Process

Where would you rather invest your time? Upfront to try and come up with a more accurate estimate, or throughout the project to manage around an inaccurate estimate?

In other words, what would you prefer? A good estimate paired with a flawed project management process or a poor estimate together with a robust process?

Coming up with good estimates is something that we all should work to get better, but we need to make peace with the fact that there's no such thing as "a perfect estimate," and the only solution to an imperfect estimate is a strong process to manage projects.

That's what I'd do: invest as much as possible into building a strong project management foundation that helps navigate our imperfect estimates. This formula will certainly win every time.

Prioritization

"Prioritization" as in having a conversation regarding all the tasks assigned to the team and coming up with the best plan to achieve our goals.

After we know what we need to be working on, there are too many times when we pick up something completely random and focus on it. Some people do it by the size of the task; some people take whatever is at the top of their list; some others can't even tell what method they use.

There's a better way; before anything else, you should set up a strategy to tackle your list. The plan will always vary, but it will certainly run laps around the lack of one.

Here are some different questions that you can ask when determining the order of your list:

  1. Is there anything that could potentially change the direction we are going?
  2. Do we need early feedback about anything?
  3. Is there anything that we can quickly complete and forget about it?
  4. Is there a way we can organize the work to maximize the skills of our team?
  5. Is there anything that excites us more than everything else?
  6. Is there anything that will unblock another task?
  7. Is there anything that will unblock another team member?
  8. Is there anything that will facilitate our work on something else?
  9. Is there anything that will increase our confidence going forward?
  10. Is there a way we can organize the work to increase the collective ownership of the project?

Prioritizing work is like solving a puzzle; the order in which you put new pieces down matters a lot.

Averages

There are three people in the room helping you out with an estimate. You discuss the next feature, then ask for everyone's opinion. A guy and a girl think it will be two days. The other guy thinks it will be five.

Alright, then (2 + 2 + 5) / 3 = 3 days. You average the estimates out, write down the result and move on. As easy as that.

Except that's an awful idea.

Averaging estimates is even worse than picking the lowest or the highest estimate. When taking a side, at least you are giving credit to someone, but by using the average, you are forsaking and distorting everyone's opinion.

What should you do? Start a discussion. Ask why it should take five days. Ask why it could be as easy as two days. Find out what's making different people give different estimates. The conversation will likely float hidden requirements or misunderstandings about the work. That's what you need to happen before moving on.

Guilt-free

One of the biggest changes from moving to a management position after being a developer is getting used to having other people do what you've been doing your entire life.

Understanding that you are moving away from doing the work into a leadership role within the team is a big adjustment that came for me with a substantial ration of guilt; not only I started feeling like I was always dumping tasks on other people, but it was hard to feel participant on their victories.

Whenever my team did something remarkable, I felt it was all them. I felt jealous I wasn't part of it and struggled to value my contribution. I was "delegating" tasks after all, and they were doing the hard work, right?

Fortunately, I've learned to give credit to my job as well. It turns out that what I do is important after all! If you are in a management position, your actions will have a profound impact on your team, and their success will be closely related to your ability to guide them.

Think about everything you do for your staff every day, and you'll see there's a direct line connecting your job with their ability to do great things. Even things that appear trivial or disconnected at first will certainly provide support and contribute to your victories.

Today I celebrate with them. I've learned to respect and value my work, which has given me the strength to do it better. Now free of guilt.

Engineering values

Having values is something crucial, not only for your social life but also at work, to guide everything you do.

Values are a little bit aspirational, but they are critical to understanding what's important, to guide the decisions we make every day, and to help us grow and create the future we want to develop.

Last week we shared with our team our Engineering Values. They took some time in the making, but I think it was worth it. Hopefully, they will give us a guide to keep growing our team.

Here they are, all ten of them:

  1. A great Software Engineer is passionate about software development. Great engineers have a passion for coding beyond anything else. They are passionate about helping shape the future of the Industry. They are experts in their craft and use it to push the boundaries of what they know.

  2. A great Software Engineer is humble and self-motivated to learn. Great engineers understand the importance of growing their skills. They are willing to leverage existing solutions, listen to others, and keep challenging the status quo to make things better every single day.

  3. A great Software Engineer pursues technical excellence. Great engineers continually try to get better at what they do and the way they do it. They never stop or get complacent. They are their biggest critic and strive to elevate the quality of every facet of their work.

  4. A great Software Engineer share experiences. Great engineers understand the real value of sharing experiences with their peers. They constantly look for ways to make the team around them look better by finding areas where others struggle and supporting them.

  5. A great Software Engineer runs towards problems, not away from them. Great engineers aren't afraid of failure. They look forward to solving difficult challenges as soon as they arise. They never back away from problems, and instead find a way to put themselves right at the front line.

  6. A great Software Engineer has a strong commitment to meet deadlines. Great engineers understand the importance of meeting deadlines. They make sure deadlines are both achievable and understood by the entire team. They help those around them get across the finish line if necessary.

  7. A great Software Engineer upholds a clear standard of quality. Great engineers take a lot of pride on the quality of their work and aren't willing to compromise it under any circumstance. They know how to manage competing priorities to deliver the best possible solution within the imposed constraints.

  8. A great Software Engineer has a "get stuff done" mentality. Great engineers are eager to build things, and they don’t stop until they finish them. They understand the importance of results over the process to achieve them, and while there's value on the latter, they value more the former.

  9. A great Software Engineer criticizes ideas, not people. Great engineers criticize ideas on merit alone and never the people who hold them. They believe that ideas should stand or fall on their own merits.

  10. A great Software Engineer constantly looks for ways to make Levatas a better workplace. Great engineers love their workplace and work together to make it a little bit better for everyone to enjoy. They understand that everything around them exists because somebody made it happen, so they respect it and improve upon it.

Advancement opportunities

I'm sure you've asked the question before.

From our "Engineering handbook", here are several areas that you can focus on to make sure you achieve success:

  1. Increase your technical competence. Find ways to increase your value to your company by improving your technical skills. From picking up an entirely new language to familiarize yourself with a different section of your project, you should have plenty of room to grow and stretch your abilities. Look at those areas within the technology stack used by your company that most interest you and go for them.

  2. Improve your professional communication. Communication is usually overlooked by engineers when growing their careers. However, it's probably the single most important area we all can improve that quickly pays off. From flawless writing skills to understanding how to communicate with non-technical people effectively, there's a lot to cover that will quickly increase your value to your company.

  3. Improve your problem analysis skills. We solve problems every day. Large or small, every project needs people to come up with solutions that keep the company in the forefront of the industry. Get on the action! Try to improve the way you tackle problems. Ask the reason behind decisions made by other people, and soon you'll be able to contribute your own.

  4. Actively add value and take initiative. This is probably the simplest thing you can start doing right away. Don't wait until somebody tells you what to do. Look, and you'll see how every single thing around you is ripe for disruption, from making your project a little bit better to your workspace more enjoyable.

  5. Become the "go-to person". There's hardly anything else that will get you more attention than becoming the "go-to person" for your projects. Start by focusing on an area that's difficult or annoying and become an expert. Never lose sight of the quality of your work, don't over do it, and be ready to take responsibility when things don't go your way.

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 backward 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.