Why Running Your Engineering Team Like a Professional Kitchen Works

Once in a while, I’d ask a founder running a Series-A startup: “How did it go with doubling your headcount last year?” Most respond with a version of the same answer: “Things kind of slowed down.”

My next question is usually met with silence: “So, why did you do it?”. Unfortunately, too many companies commit to paying a larger bill for the greater headcount only to see a declining development speed. It doesn’t have to be this way, and I will show you why.

Headcount Does Not Equal Speed

If we had 100 bricks that we wanted to move from one place to another, then the speed of how soon it is done would depend on the number of people working on it. If one person can carry 10 bricks at a time and their journey takes 10 minutes, they would take 3.5 hours to finish the job, walking back and forth. If we wanted to move faster, we could ask 10 people to carry our bricks, who would get the job done in only 10 minutes! The relationship between the speed and the headcount is linear, so hiring as many people as we can to carry bricks is the best option.

Building software is less like carrying bricks and more like creating art. One artist alone can create a masterpiece. Asking more people to help won’t make the art better or faster. If anything, they’re likely to disagree about everything and never finish. Art is personal. It requires the artist to obsess over and get consumed by their work to create something worthwhile. When they work on the smallest element of the piece, there’s always the bigger picture in mind.

It takes one person to see the whole picture, and it’s best when they work on the piece themselves. If they work on the piece alone, they get to have an intimate dance with their work. No need to explain, no need to delegate, no need to educate, no need to align. It’s them and their work. When building a feature, the way to go fast is to go alone. One engineer can build everything.

Run Your Team as a Professional Kitchen

When we expand the engineering team, we push several artists into the same space. The team start to look like a professional kitchen.

In the kitchen, everybody has their designated task for the evening.

The limiting factor of their speed is not the number of people working at the same time. It’s the number of kitchen appliances: stoves, tables, counters and sinks. After you get enough people to operate them, adding more people won’t produce more or better quality food. Too many people will try to do the same tasks at the same time, and the kitchen will become overstaffed.

To run the most efficient kitchen, you have to staff your kitchen with the best cooks, not adding more and more people to help.

Only Hire Senior Talent

One of the most common hiring mistakes I see founders make, and I’m guilty as charged myself, is hiring junior and mid-level talent for a startup. When you hire other-then-senior talent, instead of focusing on building, they will have to focus on mentoring other engineers on their team.

Senior engineers’ time is the most valuable commodity you have in bringing a product to life. You didn’t hire them to educate. You hired them to build. Let them do their job and remove the distraction. Junior and mid-level talent is for big companies. At a startup, there’s no room for anything other than the best, most skillful talent working in their area of expertise.

Building What’s Right vs. Building A Lot

A common reason for hiring more people is so that a company can build more things. While this is a sound argument in theory, it works inconsistently in practice. There’s a fraction of cases where hiring more is the right solution. In most other cases, it leads to the dilution of focus and net-neutral outcomes.

What was the last feature Instagram released? Instagram Stories came out in 2016. They shipped Reels in 2020 and Threads in 2023. What else is there besides the good old big-screen pictures and the like button? It doesn’t take a village to build these features, and the impact from others arguably didn’t make a difference. These outcomes could’ve been delivered by 5 engineers on top of their game, and that’s one of the most popular products in the world we’re talking about.

Conclusion

Building an efficient engineering organization is very much like building an efficient kitchen. Just like the kitchen is limited by its space and appliances, an engineering team is limited by the number of productive work streams they could take on. In the end, a company only has one product, and there are only so many things to do that would make a difference. Achieving your maximum development speed comes down to optimizing one simple ratio:

?? Quality of Your Engineers / Number of Your Engineers

An extreme case would mean all you need is one engineer. In some cases, this might indeed be the best. Keep in mind that what’s productive is staffing your kitchen to its full capacity, and most startup kitchens only have around 10 spots.