You have four or five engineers now. Pull requests are sitting for two days before anyone reviews them. Two people spent last week building toward the same surface without knowing it. Someone has to own coordination, and the obvious move is to promote your strongest engineer into a lead role. Before you do, stop and check whether you are solving a coordination problem or just handing your best builder a job they never asked for.
Headcount is not the trigger. Coordination overhead is
"We have five engineers, so we need a lead" is the wrong test. Plenty of five-person teams run flat and fast because the work is naturally partitioned and the people talk. The real trigger is when coordination starts costing you shipped work.
The signals are concrete, not vibes. Pull requests wait more than a day or two for review. Two engineers build overlapping things because nobody held the map. Decisions that should take an hour take a week because there is no one whose call it is. A founder who used to answer technical questions in the hallway is now the bottleneck for every one of them. When you see those, coordination has become real work, and real work needs an owner.
If none of those are happening, adding a lead is premature. You will create a layer, slow decisions down, and pull your best person off the keyboard to fix a problem you do not have yet. Wait for the signal.
Diagnose what you actually lack first
There are two different jobs hiding inside "we need a lead," and conflating them is the most common mistake here.
One is a technical decision-maker: someone who owns the architecture, breaks ties, sets the bar for what good looks like, and keeps the map so two people do not build the same thing. The other is a people manager: someone who runs one-on-ones, handles growth and performance, and absorbs the human overhead of a growing team.
Early on you almost always need the first one more than the second. A five-person team rarely needs formal performance management. It badly needs someone to hold the technical map. If you hire or promote for the people-manager job when the real gap is technical direction, you get more process and no more clarity.
Your best engineer is not automatically your best lead
The instinct to promote the strongest coder is understandable and often wrong. Being excellent at the work is not the same as being excellent at multiplying other people's work, and the two skills can even be in tension.
The skills barely overlap
A great IC optimizes their own output. A great lead optimizes everyone else's, which means less time in the code, more time in reviews, planning, and unblocking. Some of your best engineers will hate that trade. They took the job to build, and the day you make them a lead you have quietly demoted them out of the thing they are best at, then wondered why they are unhappy six months later.
Ask the person directly before you assume. "Do you want to spend less time building and more time making other people effective?" is a fair, clarifying question. A no is not a failure. It is one of your strongest builders telling you to keep them building, which is valuable information.
The failure mode to avoid
The worst version of this is promoting your best coder into people management purely because no other obvious candidate exists. Now you have lost your most productive engineer at the keyboard and gained a reluctant manager who was never trained for it. Two problems where you had one.
If the real gap is technical direction, you have options that do not burn your best IC: give one engineer explicit ownership of the technical map without a management title, or bring in experienced technical leadership part-time to set the architecture and mentor the team. There is a real difference between needing a full engineering lead and needing fractional technical direction, and getting that distinction right saves you an expensive miss.
How to make the call
Start with the diagnosis. Write down which signals you are actually seeing and which job they point to, technical direction or people management. Then look at who you have. If someone genuinely wants the lead role and has shown they make the people around them better, that is your candidate, and you should invest in them deliberately rather than just adding a title.
If nobody fits, do not force it. A reluctant lead is worse than a clear owner with no title. Use an explicit tech-lead-of-a-surface arrangement, or get outside technical leadership to hold the standard until the right internal person emerges. The goal is not an org chart that looks like a real company. It is that the work stops colliding and decisions stop stalling.
If you are staring at this decision and cannot tell which gap you have, that ambiguity is itself worth a conversation. Book a call and we can pressure-test the org move before you hand someone a job they may not want.
FAQ
When does a startup actually need an engineering lead?
When coordination starts costing shipped work: reviews stalling, duplicated efforts, decisions taking a week, or the founder becoming the bottleneck for every technical question. Headcount alone, like hitting five engineers, is not the trigger.
Should I promote my best engineer to lead?
Not automatically. Being the best builder is a different skill from multiplying other people's output, and many strong ICs do not want to leave the keyboard. Ask them directly before assuming, and separate the need for technical direction from the need for people management.
What if no one on the team wants to be a lead?
Do not force a reluctant person into it. Give one engineer explicit ownership of the technical map without a management title, or bring in experienced technical leadership part-time to hold the standard until the right internal candidate emerges.
What is the difference between a tech lead and an engineering manager?
A tech lead owns architecture, ties, and technical standards. An engineering manager owns people, growth, and performance. Early-stage teams usually need the technical decision-maker first and the formal people manager later.