VI. We Will Not Allow Our Devs to Multitask

Until a project is shipped, its value is zero. Having 10 almost-complete projects is a lot worse than having one shipped project. We all know this—and yet we allow our devs to pile up more and more unfinished work.

Let’s say you have five projects that need to get done, and it takes two days to complete each one. Would you rather have them completed all at once on the 10th day or would you prefer to have the first completed on the second day, the next on the fourth day, and so on? This should be a no-brainer. You want the first project out in the world as soon as possible. Until it’s complete, it’s not making money, saving you time, or making customers happy.

Here’s a simple model: An engineer costs $1/day and you have five projects that will each generate $1/day when completed. It takes a day of work for the engineer to complete a project. If the engineer spreads their time evenly over the five projects, all will be complete at the end of day five. At the end of day five, you’ll have made $0 from the projects and will have paid $5 to the engineer.

If, instead of doing all the projects in parallel, the engineer does them serially, the first project will be making money on day two, the second project on day three, the third on day four, and the fourth on day five. The engineer still costs $5, but that’s $10 of income by the end of day five.

We’ve gone from losing $5 in the parallel example to making a profit of $5 in the serial version. That’s a big swing.

In reality, most released features don’t translate into immediate revenue. However, the sooner a feature is shipped, the sooner we get user feedback and analytics to know if it’s achieving our goal. It could be direct revenue, or it could be preventing churn, removing friction, saving time, or just adding more visibility. There’s truth to the saying that time is money. A feature shipped today is worth a lot more than the same feature shipped next year.

We like our devs to be busy. We do not want our devs sitting idle; we want them to be fully utilized. Unfortunately, this focus on being busy causes problems. While a developer is waiting on code review, they may as well start on the next project, right? Nope. They should be doing everything in their power to get their changes through code review, through QA, and into production.

We don’t want developers hiding behind others to excuse why their projects aren’t shipped. We want to be aligned. If a developer thinks that they are “done” as soon as they submit their code for review, they aren’t going to be incentivized to make sure any ROI ever comes from their work. It’s not their fault if the review is slow. It’s not a big deal if QA finds bugs; they can fix them later, after they finish what they’re working on.

You don’t want a developer’s task to become someone else’s problem. There’s a tendency to let devs off the hook as soon as they “finish” writing the code. The truth is that code itself isn’t valuable. It’s only valuable when it’s being used in production. That code needs to be reviewed, go through QA, and be deployed. If the dev thinks they’re off the hook before any of that happens, you’ll hear a lot of “not my problem.” You want your dev to do absolutely everything in their power to make sure their code gets through review and QA as quickly as possible. Therefore, it must be their problem if it doesn’t.

It’s common for devs to mark their code changes as “needs review” and then move on to the next thing. If their changes stall here for some reason or another, they won’t notice because they’ll be distracted by the new ticket.

At this point, you may hear things like, “It’s not my fault nobody reviewed it.” This is exactly what you’d expect to hear from someone who is not invested in the outcome. They did their job already; it’s now someone else’s problem. This is not what you want.

The situation gets even worse when, after review, their feature gets bounced back for failing QA. If the dev considers their only responsibility to write code that works on their own machine, they’re not incentivized to do any serious testing to ensure that it passes QA on the first try. This additional loop adds a ton more time. To make matters even worse, if there’s a long delay between when the developer last worked on the code and when they start on it again after failing QA, it’s going to take them twice as long to get their bearings and fix the issue. Context switching is costly for everyone, but this goes double for engineers.

The more projects a dev has “in progress,” the more these issues get exacerbated. When a dev is focused on a new project, they’re not ensuring their last feature is being reviewed. If there are issues that come up in review, they’re going to be less responsive in addressing them because they’re busy with the next thing.

Devs may think all of this is unfair. They can write the code, but everything else is outside their control. This is a dangerous way of thinking. Life is uncertain for all of us. We can’t predict the future or control all outside forces. What we can do is prepare for different scenarios and adapt. It all comes down to motivation and responsibility.

Maybe you’re not excited about meeting an acquaintance for dinner. If your car doesn’t start, you can send an apologetic text message and spend the rest of the evening ordering in and playing video games. You said you were going to do something and you were thwarted by the universe; oh well.

What about a different scenario? This isn’t just any acquaintance. This is a VC who is interested in investing, and there’s a good chance you’ll get a term sheet after this meeting. I’d bet that earlier that day you’d double-check that your car is ready to rock. I’d also wager that even if it didn’t start, you’d pay for a rideshare, convince a friend to drive you, borrow a car, or take public transportation. In other words, with sufficient motivation, you’d prepare ahead of time and not let any inconvenience get in your way.

You don’t want your devs ordering takeout and playing video games every time they encounter a minor obstacle. You need them committed to getting to the destination.

Do not reward your devs for being busy. Reward them for delivering finished products.