Two are better than one — easy way to boost developer productivity
Being an engineering manager is all about creating an environment for your engineers to be productive. One of the best ways I found to achieve greater execution is to never assign just one engineer on a particular project. By project I mean anything more than a week’s worth of work.
Why do engineering managers assign just one engineer to a project? The answer is because it’s the simplest algorithm we have to distribute the work. We are all under staffed and face an ever increasing backlog of projects. By assigning a single engineer to each project we optimize for the highest number of running projects, which looks like we’re making the most progress. It’s also the easiest way to satisfy our stakeholders, at least in the short term (“OK, let’s start building that new toolbar, it’s important”). In reality, we are shooting ourselves in the foot (“So why aren’t we making progress on the new toolbar? What’s the ETA?”).
What happens when an urgent production issue needs attention? Or someone on the team goes on vacation or sick leave? The project grinds to a halt. So far, this is not news to anyone. But the real reason we should assign more engineers to each project lies in the effect of that on the manager and the team.
Let’s assume that as an engineering manager I assign a project to two engineers: Pearl and Jam. I need to decide which part of the work Pearl will do and which part of the work to assign to Jam. In order to do that, I need to have a pretty in-depth understanding about how the project is going to be accomplished (AKA the design). It forces me to be more in the details, and that is also an opportunity to provide more meaningful feedback and identify potential roadblocks and risks. When I assign a single engineer to a project it’s easier for me to think “fire and forget”. The engineer will worry about the design, and even if we do a design review not sure that as the manager I’ll be able to dive deep enough to provide the same level of value as if I had to make some decisions about the project early on.
From the team’s perspective, when two engineers work together there’s a better chance they’ll build better interfaces between their modules because they actually need to communicate about it. Moreover, they’ll have more conversations about the project, (“Hey Jam, if I return null here, does that work for you?”) which will increase the chances of them producing higher quality work (“Hmm… Not a good idea. All the other interfaces we have use exceptions for that. Let’s stick with exceptions”).
Lastly, as an engineering manager, having the team work on less projects at the same time reduces the overall bureaucracy I have to deal with and it allows me to spend more time with the team or work on my own projects.
Try it for a few weeks and let me know how that goes for you.