When a team is drowning, a new headcount request feels like the responsible thing to do. The backlog is long, people are tired, and another pair of hands looks like the fastest fix.

I have approved plenty of those requests, and I have learned that headcount does not turn into output in a straight line. One strong hire can remove a bottleneck that has blocked a team for months. The wrong hire, or the right person at the wrong moment, can add meetings, handoffs and rework before adding anything useful.

The difference is rarely the quality of the candidate. It is whether the team, the manager and the structure around them can absorb another person. Every hire brings skills and time. Every hire also brings onboarding, context-sharing, decisions to align and one more person who needs feedback and support.

So the question I ask is not "Do we need more people?" It is "What exactly is constrained, and will this person remove that constraint?" Here are the breakpoints where that answer tends to change.

The jump from zero to one specialist is often the most valuable hire a growing team makes. Before you have a dedicated designer, data engineer, SRE or engineering manager, that work still happens. It just happens by whoever has time, using whatever standard they personally prefer.

A capable first specialist changes that. They set the patterns other people follow: the design system, the metric definitions, the on-call practice, the way one-on-ones and performance conversations run. Their impact reaches far beyond the tickets they close because everyone else now works to a clearer standard.

That is also why the first hire in a function is so consequential. A weak data foundation can haunt reporting for years. An inexperienced first manager can leave a whole team unsure what good looks like. When I hire a first specialist, I weigh judgment and the ability to set foundations well above raw speed.

The second hire in the same function is a different decision. The instinct is simple: one designer helped, so two should help twice as much. In a small team, though, the second person often arrives before there is a clear way to split the work. Two people now make overlapping decisions, patterns start to diverge, and engineers spend time reconciling two opinions instead of shipping.

The same thing happens with senior roles. Splitting one leadership area into two before the work truly needs two owners usually divides accountability rather than doubling it. Decisions get slower because nobody is sure who has the final call.

There are exceptions. In support, sales or on-call rotations, a second person adds real coverage and gives you a point of comparison. With one person, it is hard to tell whether a problem comes from the individual, the workload or the process. With two, the pattern becomes clearer.

Tip: Before duplicating a role, write down what the second person will own that nobody owns today. If you cannot draw a clean line between the two roles, fix the scope first, then hire.

Most teams hit a management limit before they hit a talent limit. A manager who runs a team of six well can start to struggle at ten or twelve, even when every person on the team is capable. Nothing dramatic happens. The cracks are small at first.

A follow-up gets missed. A pull request waits two days for a decision. A one-on-one is moved, then moved again. Each issue looks minor on its own, but together they signal that the manager no longer has enough attention to keep the basics under control.

If the load keeps growing, bigger things slip. Performance conversations get postponed. Conflicts linger. Career growth becomes something discussed only at review time. The manager is working harder than ever, yet the team feels less supported, because most of that effort goes into reacting rather than leading.

There is no universal right number of direct reports. Experienced engineers working on well-defined systems need less day-to-day support than a team full of new hires on an ambiguous project. Remote and cross-time-zone teams add their own overhead. The useful question is not "How many people does this manager have?" but "Does this manager still have time for the work only a manager can do?"

Adding another engineer to an overloaded manager's team rarely helps. On paper it raises capacity. In practice it adds one more person who needs context, direction and feedback from someone who is already out of time.

Tip: Track the early signals, not just the headcount: delayed decisions, skipped one-on-ones, slow reviews and unresolved conflicts. When those start to rise, address management capacity first. That might mean a new manager, a tech lead taking on more, or splitting the team, before you add anyone else to it.

The hidden cost of hiring is coordination, and it does not grow in a straight line. The number of possible one-to-one connections in a group grows much faster than the group itself. A team of five has 10 possible pairs. A team of ten has 45. A team of fifteen has 105. Not every pair needs to talk, but every extra person adds more people to keep informed, more opinions to align and more ways for context to get lost.

New hires also cost time before they add it. Someone has to onboard them, review their early work and answer their questions. That someone is usually your most experienced engineer, the same person you most need on the critical path. This is why adding people to a late project so often makes it later.

Small teams get a lot of coordination for free. People know who owns which system, who can approve a change and why a decision was made. As the organization grows, that shared memory stops being reliable. Questions bounce between teams, decisions get relitigated, and new joiners have nobody obvious to ask.

At that point, more people only help if you also invest in the structure that lets them work together: clear ownership of services and decisions, written decision records, predictable planning and an onboarding path that does not depend on one generous colleague. This is not about adding bureaucracy. It is about making the organization understandable enough that people can act without waiting for someone to explain it.

The goal is not to stay small at all costs. If customers need more coverage or the business needs a new capability, refusing to hire creates its own bottleneck. The goal is to make growth deliberate, so each new person adds more than they consume.

Tip: Before adding people to a team, check the basics: Is ownership of every service clear? Are important decisions written down? Can a new joiner become productive without monopolizing a senior engineer? Fix the gap that would hurt most, then hire.

AI tools change the hiring math in a real way. When drafting, searching, summarizing, test scaffolding or routine analysis take less time, one capable engineer can cover more ground. That makes it worth asking whether a new role is the only way to relieve a capacity problem.

Before I open a role, I look at where the team's time actually goes. Are people rebuilding the same report every week? Copying information between tools? Writing boilerplate that could be generated and then reviewed? If better tooling or a process change frees up meaningful time, I can delay the hire or point it at a capability the team genuinely lacks.

But AI does not make every team endlessly scalable. Automated workflows need maintenance. Generated output needs review, and someone stays accountable when it is wrong. And the hardest parts of engineering leadership, such as building trust, giving difficult feedback, resolving conflict and making trade-offs under uncertainty, do not get faster because information is easier to find.

I am especially cautious about using AI as a reason to stretch managers further. A tool can summarize status updates. It cannot have the honest conversation with an engineer who is struggling. Giving a manager AI support is a reason to give them more time for people, not more people.

Tip: Before approving a role to relieve workload, run a short experiment: pick the most repetitive part of the team's work, automate or simplify it, and measure the time actually recovered after review and maintenance. Then decide whether you still need the hire.

Hiring is neither good nor bad on its own. Its value depends on the role, the person, the stage of the team and whether the organization can turn extra capacity into results.

A first specialist can create a capability that lifts everyone. A poorly scoped second hire can blur ownership. An overloaded manager needs support before another direct report. A growing organization needs better coordination before more people. AI can change when you need the next person, but not the need for judgment and leadership.

The practical lesson is to stop treating headcount as a proxy for progress. A bigger team can do more, but only when responsibilities are clear, managers have room to lead and the work can be coordinated without excessive friction.

The goal is not to build the biggest team. It is to build a team where every additional person makes the whole group more capable.

Hit reply and tell me: what is one hire that slowed your team down before it sped things up, and what would you do differently? I read every answer.

One more from today's sponsor, which helps keep Tiny Big Spark free:

Keep going, one small spark at a time.

Erwin