Last updated: September 2, 2026
By Tom Kenaley, President and Senior Partner, KORE1
An engineering org chart runs on six staffing ratios, and only one of them has real research behind it. That one is span of control, and it lands near six engineers per manager. Everything else on the chart is convention borrowed from a company that looked nothing like yours.
Thirty-one boxes on one slide. One manager had fourteen reports. Another had two.
A VP of engineering at a payments company in Costa Mesa sent me that chart last November. Not a req. An org chart, which happens more than people outside recruiting would guess, because heads of engineering want to know what a shape costs before they commit to it in a board deck. She wanted six hires priced. What she had was a structure that would have broken two of the six inside a year. Maybe three.
The work was fine. The boxes described real problems the company actually had. The ratios were the part nobody had checked.
AI and ML teams run on their own set of ratios, and they are tighter. The AI/ML org chart and its ratios covers that side.
Worth saying where I sit before you take any of this as neutral. KORE1 fills engineering seats for a living, so a chart with more boxes on it is a larger invoice for us, and you should discount my headcount enthusiasm accordingly. There are two seats below I will tell you to fill yourself. Handing those to an agency wastes your money and our time. The rest of the technology side runs through our IT staffing services desk.
Six Ratios, and Only One of Them Was Measured
An engineering org chart is a map of who answers for what, drawn as reporting lines. The boxes name the accountability. The spans between them, meaning how many people hang off each box, decide whether that accountability survives contact with a normal quarter.
Here is what the ratios look like across the searches we run, and how much evidence sits behind each one. Read the last column first. It is the honest part.
| Ratio | Common Range | What Actually Sets It | Evidence Behind It |
|---|---|---|---|
| Engineers per manager | 5 to 8 | Coaching load and how junior the team skews | Strong. Large national workforce datasets. |
| Managers per director | 4 to 6 | Number of distinct product areas, not headcount | Convention. No published dataset. |
| Product engineers per platform engineer | 10 to 25 | How much infrastructure you own versus rent | Partial. Adoption is measured, the ratio is not. |
| Engineers per dedicated QA or SDET | 5 to 15, or zero | Regulatory exposure and release cadence | None worth citing. |
| Engineers per product manager | 6 to 10 | Count of product surfaces, not team size | None, though the internet pretends otherwise. |
| Engineers per product designer | 8 to 12 | How much of the product a human touches | None. Varies wildly by product type. |
Five of those six are folklore. Useful folklore, repeated by enough experienced people that the ranges are probably directionally right, but folklore. If you have ever seen a blog post state a one-to-seven product manager ratio as though it came out of a study, it did not. The surveys behind those numbers are small, self-selected, and usually run by a company selling a tool. No one measured it.
One ratio is different.
Span of Control Is the Only Ratio With Research Behind It
Span of control is the number of people reporting directly to one manager. It is one of the oldest ideas in org design and the only one on that table with a serious dataset underneath it, which is why it deserves more of your attention than the rest of the chart combined.
Gallup published fresh numbers in January 2026, and the headline reads like bad news for small teams. Their span of control research has the average American manager carrying 12.1 direct reports last year, against 10.9 the year before, on a trend line that has climbed roughly half again since 2013. Small teams look finished.
They are not. The median is five to six.
The average moved because a small group of very large teams got larger. Gallup found 37% of managers oversee fewer than five people, 66% manage fewer than ten, 22% carry ten to twenty-four, and 13% supervise twenty-five or more. That last thirteen percent is dragging the mean around. Most managers, including most engineering managers, still run something small. Yours probably included.
Two more numbers from the same work matter for engineering specifically. Almost every manager in that dataset, 97% of them, still carries non-managerial work. The median one gives 40% of the week to it. Forty percent. In engineering that number is the whole argument about whether managers should still write code, which I will not relitigate here because we already covered how much engineering managers should still code in detail.
What it means for your chart is arithmetic. Give a manager eight reports and 40% of a sprint, and you have not staffed an eight-person team. You have staffed one at three-fifths strength, which buys about the coaching attention a five-report manager with an empty calendar would give. Set the span against the real available time, not the title. Titles lie.
Gallup also cites federal labor data putting the whole U.S. workforce at roughly one manager per 11.5 employees. Engineering usually runs tighter than that, because the work is interdependent and the review load is heavy.
Three Moments the Chart Has to Change
Charts do not scale smoothly. They hold, then they snap, and they snap at fairly predictable places. Loudly, when they go. Company revenue does not predict these moments. Engineer count does.
At Eight Engineers, Someone Stops Coding
Under eight, a strong tech lead can carry both jobs. Above eight, the one-on-one load alone eats a day and a half a week, and the person carrying it starts missing their own commitments. This is the transition that produces the most damage per dollar in the entire chart, because the company promotes its best engineer into it without telling them what changed. Nobody hands them the tradeoff.
The failure is not usually incompetence. It is that nobody defined which half of the job loses when the week gets short. We wrote a whole piece on promoting a strong IC into engineering management for exactly this reason.
At Twenty-Five, You Add a Layer or You Add Meetings
Three to four managers plus a lead or two, and now someone has to coordinate across them. Most companies delay this hire because a director feels like overhead. What arrives instead is a weekly meeting that grows a new attendee every month until it consumes four hours of everyone’s Tuesday. Every Tuesday.
A director of engineering at this stage is not a career step for the org. It is a load-bearing wall. The tell that you needed one about two quarters ago is that your VP is doing skip-levels with twenty-two people and calling it staying close to the team.
At Eighty, You Organize Around Interfaces
Somewhere past seventy or eighty engineers, the chart stops being a list of people and becomes a description of how systems talk to each other. Matthew Skelton and Manuel Pais named this properly in Team Topologies, which argues that team boundaries and software boundaries end up mirroring each other whether you plan it or not.
Plan it. The alternative is discovering in year three that your billing service has four owners because it was built by whoever was free.
The Support Seats, and How Many You Actually Need
Product engineers get all the attention in headcount planning. The seats around them are where charts usually go wrong, either by staffing them too early or by pretending they are optional.
- Platform engineering. This one has real numbers now. Google’s DORA program found that by 2025, 90% of organizations had adopted an internal developer platform and 76% had a dedicated platform team, drawn from a survey of nearly 5,000 technology professionals. Near universal. What DORA does not publish is a ratio, so treat 10 to 25 product engineers per platform engineer as a starting hypothesis you test against your own on-call load.
- Site reliability is a different job from platform, and conflating them is a common budgeting error. Platform builds the paved road. SRE answers the pager and owns the error budget. A twelve-person team running on managed services genuinely does not need a dedicated SRE. A forty-person team running its own Kubernetes clusters absolutely does, and the moment you notice engineers rotating through incidents with no owner, you are already late. Months late.
- Quality. The ratio depends almost entirely on what happens if you ship a bug. Consumer app, low stakes, fast rollback? Engineers can own their own tests and many good teams do. Medical device firmware, or anything touching a regulated audit trail? You need dedicated QA engineers, and you needed them before the first release, not after the first finding. Ask any auditor.
- Product management sits outside engineering on most charts and inside the argument on all of them. Six to ten engineers per PM is the range everyone repeats. The thing that actually sets it is how many separate surfaces the team owns, because a PM covering one mobile app and one internal admin tool is doing two jobs regardless of engineer count.
- Design. Eight to twelve engineers per designer, less if the product is mostly interface, much more if it is mostly pipeline.
Two of those seats are the ones I said you should fill yourself. Junior and mid-level QA, and internal-tools product management. Both roles have deep local candidate pools, both get filled off a decent job posting in three or four weeks, and paying an agency fee for either one is a poor trade. Spend the fee where the market is thin. Not on the easy ones.
Which Boxes Are Hard to Fill, and Which Are Not
The chart tells you what you need. It does not tell you what the market will make you pay in time, which is the number that wrecks quarterly plans.
Our average time-to-hire across IT and engineering searches runs 17 days, taken across the thirty-plus metros we recruit in. That average hides a wide spread, and the spread follows the chart almost perfectly. Individual contributor roles in common stacks close fast. Leadership roles do not.
A senior backend engineer working in Go or Java, in a metro with real supply like Austin or the Bellevue corridor, is a two- to three-week search on a good week. A first-line engineering manager who has actually run a team of eight, rather than a tech lead with the title, routinely runs five to seven weeks. A VP of engineering for a company between forty and a hundred engineers is a different exercise entirely, closer to a search than a fill, and I would budget a quarter. Sometimes two.
Compensation follows the same shape. O*NET, the U.S. Department of Labor’s occupational database, puts the 2025 median for software developers at $135,980 with roughly 115,200 annual openings projected through 2034, and computer and information systems managers at $175,140 median with about 55,600 annual openings. Those medians are national and they blend a lot of very different jobs together, so use them as a floor check rather than a band. For a real number on a specific role in a specific market, our salary benchmark tool is faster than assembling three aggregators yourself, and the engineering manager salary guide breaks the leadership bands down by scope.
One more thing the chart hides. Retention differs by box. Our placements hold at 92% at twelve months, and the misses cluster in exactly the seat you would expect, which is the newly promoted manager who took the job because it was the only path to a raise.
If the shape of the org is still moving, and it usually is between thirty and eighty engineers, contract engineering staffing lets you staff a team before you have committed to the reporting line it eventually sits under. Convert once the box stops moving. Not before. When the box is stable and the role is core, hire it direct and stop paying a margin on a permanent seat.
Where These Charts Quietly Break
The first failure is the fourteen-report manager from the top of this piece. It never shows up as a headcount problem, because on paper the team is fully staffed and the manager has not complained. It shows up as attrition among the quietest four people on that team, roughly nine to fourteen months later, and by then the exit interviews are full of people wanting a new challenge, which is what people say when nobody was paying enough attention to give them one. The VP in Costa Mesa had two of those departures already and had attributed both to comp. It was not comp.
The second failure is the reverse and it costs more than anyone admits. Managers with two or three reports, usually created to give a senior person a title during a comp negotiation. Gallup’s data says 37% of managers run fewer than five people, so this is common everywhere, not just in engineering. In engineering it is expensive twice over, because you are paying a manager premium for someone who is functionally still an IC, and you have added a layer that every decision now has to route through. Twice the cost. Half the throughput.
Third, and this is the one that survives longest before anyone notices: the chart that matches the systems you had two rewrites ago. Team boundaries calcify. The service gets split, the team does not, and eighteen months later four engineers are maintaining a codebase that three separate squads depend on, with no shared roadmap between them. Nobody owns the interface because the interface did not exist when the boxes were drawn.
Adjacent functions fail differently. Drawing the whole technology org instead of just engineering means two more shapes to get right, and we mapped both: how to structure a data org and how product teams get laid out. Data tends to break on reporting line, not on span.
What Hiring Managers Ask Us About Org Charts
How many engineers can one manager actually handle?
Six to eight, if that manager is also expected to coach, hire, and hold performance conversations. Gallup puts the national median span at five to six across all industries, and engineering rarely justifies running wider.
Wider spans do work in specific conditions. Senior teams, low hiring volume, a manager who has done the job for a decade and has ruthless meeting hygiene. That is a rare combination. Add two juniors to that same team and the number drops fast, because onboarding is the single most expensive thing a manager does with their calendar.
When does a director layer stop being optional?
Not at a headcount. At a span. Once three or more managers report to the same person and that person also owns strategy, budget, and external stakeholders, the coordination work has already outgrown them.
Twenty-five engineers is the rough marker, but I have seen it arrive at eighteen in a company with four separate products and not arrive until forty in a company with one. Count the reporting lines converging on your VP. If it is more than five and two of them are managers of managers, you are past it.
Should engineers own testing, or do we need a QA team?
Both, usually, and the split depends on consequence. If a bad release costs you an apology, engineers can own it. If a bad release costs you an audit finding or a recall, hire dedicated quality engineers.
The regulated case is not subtle. Medical device, payments, anything with a compliance trail attached. Those teams need someone whose job is to say no, and that person cannot report to the engineer whose feature they are blocking. Structure, not backbone.
Is a platform team worth it under fifty engineers?
Under fifty, almost never as a standing team. One or two engineers with an explicit platform mandate and protected time works better than a formal team, because a two-person platform team becomes a ticket queue within a month.
DORA’s finding that 76% of organizations now have a dedicated platform team is a real signal, but their sample skews toward larger enterprises. The mandate is what matters early. The org box can wait.
Product-based teams or technology-based teams?
Product, once you have more than two products. Technology-based teams, meaning a frontend group and a backend group, look tidy on a slide and produce a handoff at every feature boundary.
There is one honest exception. Very small teams, under about twelve engineers, where everyone works on everything anyway and the labels are decorative. Past that, organize around the thing a customer uses.
Three holes in the chart and budget for one hire. Which one?
The manager, if any manager on your chart is above ten reports. Span problems compound quietly and cost you people you cannot see leaving yet, while an unfilled IC seat costs you velocity you can measure.
If every span is already healthy, hire the seat that is currently blocking two other people. That is almost never the most senior title on the list. It is frequently the platform or data engineer that three teams keep waiting on.
Start With the Spans, Not the Slide
The chart the VP sent me came back to her with fewer boxes and different lines. We split the fourteen-report team into two, folded one of the two-report managers back into an IC role with a comp adjustment attached, and pushed one of the six hires out two quarters because the seat did not have a real owner yet. Five hires instead of six. That is one fewer fee for us, which tells you what I thought of the sixth box.
Draw your spans first. The boxes will mostly draw themselves after that, and the ones that do not are the ones worth arguing about.
If you are sizing an engineering org right now and want a second opinion on what each box will cost you in weeks, talk to one of our recruiters. Our team averages fifteen-plus years on the desk and has priced more of these charts than we have filled, which is the part clients tend to find useful.
