Growing an engineering team without growing the queue

The reflex is always the same. Deliveries slip, the team says it is overloaded, and the CEO opens a position. It is the only visible action within reach: a hire can be budgeted and explained to the board. Six months later the team has two more people and ships barely more. Sometimes less.

A team does not grow by hiring. It grows by delegating decisions, and hiring is only the consequence of that delegation. Every arrival costs before it pays: time from the people already there, more reviews, more questions converging on the same three people. If you have not decided who decides before you hire, you are not adding capacity. You are lengthening the queue.

I lived through this at Ipedis, moving from lead developer to CTO while the product team grew from 5 to 25 people. Here is what I learned.

PubliSpeak started as a proof of concept. I built the V1, and the monolith that came out of it held until the precise moment the team began to grow. That is no coincidence. With five people, everyone touches everything without treading on each other. Beyond that, every new feature made the release riskier, for clients who depended on the platform every day.

So we ran both projects at once, because they were one project. On the technical side, an incremental migration to ten microservices, one business domain at a time, with a RabbitMQ event bus so that teams stopped depending on each other at every deployment. No big bang, no service interruption. On the human side, hiring and structuring in parallel: distributed ownership, structured onboarding, continuous skills development.

The lesson fits in one sentence. Splitting the architecture and splitting the organisation is the same decision: fixing what each person can change alone and what forces them to go and see someone. A team that has to coordinate for the smallest feature is not too small. Its boundaries are in the wrong place.

With five people, your best developer writes code, reviews everyone else’s, picks the tools and answers your questions. It works. With twenty-five, that same person is the bottleneck of the whole company. They know it. And they will not let go of anything, because nobody has told them what to let go of.

Before hiring, ask the awkward question: who owns the architecture, who runs each team, who settles priorities, who hires? As long as the answer is “him” for all four, you do not have a team. You have one person and some assistants.

This is where the lead developer appears. A lead developer makes a team effective within a frame: breaking down the work, organising reviews, flagging what is blocked. The CTO sets that frame with you. The difference is in CTO vs lead developer. The lesson I draw here: naming a lead developer without taking code off their plate and without giving them real decisions is handing out a title to someone who keeps the whole load.

Then split, and split along the product, not along skills. A front-end team and a back-end team coordinate for every screen. A team that owns a business scope end to end ships alone. If most changes need the agreement of three teams, do not hire. Move the boundaries.

At Gridky, I asked a candidate whether he wrote automated tests. No, he told me, but asking an AI would be enough to generate them. He sincerely believed it was a good answer, and that is what worried me: he did not know what a test protects, or why anyone writes one. He was not applying as a developer. He was applying as a relay between my request and a coding agent.

I call this the proxy candidate, and you are going to see more of them. Producing code has become a commodity. What I am buying is someone who understands every stake in the code they deliver, whether they typed it or not. The take-home test is still useful on one condition: you no longer assess the code, you assess the choices, on six points:

• security
• performance
• edge cases
• architectural choices
• error handling
• understanding and restating the initial request

Generating tests with AI does not answer my question. The question is: can he read them, challenge them, and keep a project with strong business rules stable over the years?

Next, know what you are buying. I do not hire a junior to make architectural trade-offs alone. I owe them support and decisions they can own at their level. A senior will arrive with strong opinions about your project, and that is what you are paying for, provided you decided before they arrived who settles a disagreement. Otherwise you will have paid dearly for a conflict.

Finally, pace. Hire in small rounds, a few people at a time, spread out. A big wave looks like a strong decision. In practice it scatters the people doing the supporting, and the team spends a quarter onboarding instead of shipping. And do not let the selection drag: the good ones sign elsewhere while you deliberate.

The day someone arrives, your capacity drops. Someone has to explain the product, open access, review the first contributions, answer the questions, and those questions land precisely on the people who were already the bottleneck. Whatever is only ever said out loud will be said again to the next person. A team that writes nothing down pays full price for every arrival.

My rule: every newcomer has a buddy, one person to turn to for anything, and a buddy never supports more than two newcomers at a time. The rule has a hidden virtue: it sets the size of the round. Two available buddies, and you are not hiring six people this month, whatever the plan says.

Onboarding is a process, and a process gets tested: the development environment, the business vocabulary, who answers what, and a first real change, a small one, shipped to production. Then ask the newcomer what was missing. They are the only person who can still see what everyone else takes for granted. In a month they will not see it any more.

And track access: who received what, when, and for what purpose. Without that record, every arrival opens doors that will be forgotten, and every departure leaves one ajar. I described the same mechanism for tools in the access that outlives the tools: the use stops, the access remains. Because a growing team also sees people leave. Tracked access lets you close on departure what was opened on arrival.

You know the one. They alone know how the billing works, or the deployment. Questions converge on them, their reviews are mandatory, their holidays block releases. Everyone knows it. Nobody fixes it.

I distrust the explanation that they simply will not cooperate. Sometimes urgent work leaves no time to pass knowledge on. Sometimes being indispensable has become a place the person no longer knows how to leave. Asking them to “document” without making time or discussing what comes next addresses neither case.

So start with a map. For each part of the system, three names: who can change it, deploy it, repair it in the middle of the night. The areas with a single name are your real emergencies, well ahead of the next job description. Pair on them, rotate the reviews, and have the documentation written by someone other than the expert: at least they will know what they did not understand.

And give the indispensable person something else to be: running a domain, supporting newcomers, the overall architecture. You are not taking their place away, you are offering them a bigger one, and it is the only way I have seen work.

When a team of fifteen ships more slowly than a team of eight, I start with the queues: review, tickets, deployment. Each of these steps protects quality. Each becomes a funnel as soon as the team grows faster than the number of people able to handle it.

Code review first. If two people review everything, every hire lengthens their queue. Share out the reviewing, write down what a review should check, have newcomers review early. Tickets next. If one person writes every request, the team waits on their work. Give each team the right to write the tickets for its own scope. Deployment last. It should depend on neither a person nor a time slot. I told the story of what that waiting costs in a fix finished on Tuesday and released the following week.

Meetings follow the same slope: every stage of growth adds some, almost none are removed. Keep the ones that produce a decision or remove a blocker. The rest can be replaced by something written.

One signal does not lie: if waiting time grows with headcount, a process has not kept up. If developers coordinate more than they produce, a meeting is one too many or a boundary is in the wrong place. Reading that slowdown in the tickets and the delivery metrics is the subject of the article on engineering team health.

I would never judge a team’s growth by its headcount. Only by what it ships, compared with before. The team health radar opens another view: the same questions to leadership and the team show where their perceptions diverge. These are not delivery measurements.

Before each round, I would answer four questions in writing:

• why this role, which profile, which seniority
• which buddy for each newcomer, two at most per buddy, and who writes down what is said out loud
• which access will be opened, and where it will be tracked
• which review will saturate first: code, tickets or deployment

If an answer is missing, I would establish what it prevents us from preparing before setting a start date. A hire may be precisely what adds the missing review or mentoring capacity. The decision then depends on the time available for onboarding and the cost of waiting, rather than a fixed delay applied to every hire.

The pace that worked at Ipedis may not suit your market. I would keep this requirement: know which decisions the role will help distribute and who will support the newcomer, rather than simply counting one more person. The page on engineering team organisation takes these questions further. And if nobody in your company can carry those trade-offs while the team grows, that is the work I do as a fractional CTO, for an agreed period.