Short version: do not hire your first engineering lead by headcount, and do not hire one because a blog said twelve engineers is the number. Hire one when specific pain shows up: standups that run long, work that stalls on dependencies, engineers who cannot tell you what the priority is. That pain usually arrives somewhere between seven and fifteen engineers, but the pain is the trigger, not the count. Hire too early and you add overhead to a team that was fine. Hire too late and you watch good engineers quietly disengage.
This question lands on my desk in two opposite flavors. One founder has six engineers, things feel a little chaotic, and they want to hire a manager to fix it. Another has fifteen, the founder is still personally unblocking every decision, and they are wondering why velocity has cratered. Both are reading the wrong dial.
Headcount is a weak signal. Pain is a better one.
There are numbers floating around, and they are not useless as a rough prior. Teams tend to work well up to roughly seven plus or minus two people, and beyond that communication overhead climbs and velocity starts to drop. Many engineering leaders put the first dedicated manager somewhere around ten to fifteen engineers. Treat those as a range to expect the question in, not an alarm that goes off at a specific headcount.
The reliable signals are operational, not numerical. Standups that used to take five minutes now run twenty because there are too many people and too many threads. Work keeps stalling because tasks depend on each other and nobody is sequencing them. Engineers cannot tell you what the top priority is this week, or three of them give you three different answers. Decisions that used to take an hour now take a week because no one owns them. You, the founder, have become the bottleneck for every technical choice and you are doing it badly because you have a company to run. When two or three of these are true at once, you have outgrown the flat structure, regardless of whether the count says ten or six. This is the same kind of pattern-reading I apply to premature scaling: the headcount is a tempting number to optimize, and the real signal is the friction it is supposed to relieve.
Manager or tech lead first?
These are different roles and founders conflate them constantly. A tech lead owns technical direction, architecture, and code quality, and is usually a senior engineer who still writes code. An engineering manager owns people, priorities, unblocking, and the health of the team, and may write little or no code. The pain you are feeling tells you which one you need first.
If the pain is technical, inconsistent architecture, no one owning quality, decisions about how to build things scattering, you need a tech lead, and you very likely already have the person on your team. Promote or formalize a strong senior engineer into the role. If the pain is coordination, unclear priorities, dependencies stalling, people pulling in different directions, nobody is helping engineers grow, you need management, and that is harder to fill from within.
There is a counterintuitive lesson worth knowing. Hiring a pure people manager before a tech lead often works better than the reverse. A capable manager can coach a senior engineer into acting as tech lead for a while, but a tech lead with no manager rarely backfills the people and coordination work, because it is not what they want to do or are good at. Teams that brought in management first tend to hold onto people better over the following year and a half than teams that hired a tech lead first and left the coordination gap open. This is a smaller-scale version of the CTO versus VP of engineering question: the title matters less than honestly naming which kind of leadership the pain is asking for.
What the founder should hand over, and what to keep
Until the pain is real, you, the technical founder or your fractional leader, should keep owning the management of a small team. That is correct and you should not feel behind for doing it. The mistake is holding on past the point where you can do it well, which is the moment you become the bottleneck I described above.
When you do bring in a lead, hand over the right things and keep the right things. Hand over day-to-day prioritization, unblocking, one-on-ones, and the sequencing of work, the operational load that is eating your week. Keep, for a good while longer, the overall technical vision, the biggest architectural bets, and the hiring bar, because those still need a founder's context and should not be delegated on day one to someone who just walked in. The transition is a real handoff with a real ramp, not a switch you flip, and it works best when you are explicit with the team and the new lead about exactly which decisions move and which stay with you.
Don't hire structure you don't need yet
The opposite failure is just as expensive and more common among founders who have read too much about scaling. They hire a manager for a team of five, and now five productive engineers have meetings, process, and a layer between them and the founder, in service of solving coordination problems they did not have. Layers of management on a tiny team slow it down and signal to good engineers that the place is getting bureaucratic before it has earned the right to be.
The discipline is the same one that applies to most early-stage scaling decisions: add structure in response to real, observed pain, not in anticipation of pain you imagine is coming. If your standups are short, your priorities are clear, and work is flowing, you do not need a lead yet, no matter what your headcount is. Wait for the friction, then hire to relieve it. If you genuinely cannot tell whether the chaos you are feeling needs a hire or just needs better habits, that diagnosis is exactly the sort of thing worth a second opinion, and a good reason to book a call before you add a layer you cannot easily remove.
Frequently asked questions
How many engineers before I need a manager?
There is no exact number, but the question usually becomes real somewhere between seven and fifteen engineers, because small teams work well up to about seven and overhead climbs past that. Use the range as a prior, not a trigger. The actual trigger is pain: long standups, stalled dependencies, unclear priorities, and you becoming the bottleneck for every decision.
Should I hire a tech lead or an engineering manager first?
It depends on the pain. Technical pain, inconsistent architecture and no one owning quality, calls for a tech lead, often someone you promote from within. Coordination pain, unclear priorities and stalled work, calls for a manager. If unsure, a people manager first tends to work better, because a good manager can grow a tech lead but rarely the reverse.
Can I just promote a senior engineer into the lead role?
Often yes for a tech lead, since that role stays close to the code and a strong senior engineer can grow into it. For a people manager it is riskier, because managing people is a different job that a great engineer may neither want nor be good at. Promote into technical leadership readily; promote into people management deliberately.
What if I hire a lead too early?
You add meetings, process, and a layer between the founder and a team that was working fine, which slows good engineers down and reads as premature bureaucracy. Add leadership in response to observed pain, not anticipated pain. If standups are short and priorities are clear, wait.