I Counted 14 Direct Reports on One Manager — the 5 Numbers That Fixed Our Singapore Org Chart

The engagement that taught me this started as a hiring brief. A Singapore company wanted four more backend engineers because delivery had slowed. Before writing the specification I did something I now do every time: I counted the org chart. One manager had 14 direct reports. A typical release touched three teams. There were four management layers over thirty-one engineers. They did not have a hiring problem. They had a structure problem that four more hires would have made measurably worse, because every new engineer would have landed inside the same bottleneck.

The 5 Numbers to Count Before You Draw Anything

Org design conversations usually start with a whiteboard and end in opinion, because nobody established the facts first. These five numbers take an hour to gather and they diagnose most of what is wrong:

1. Direct reports per manager. The single most predictive number. Count actual reports, including the two people who “informally” report to someone.
2. Engineers per team. Teams of two are not teams; teams of twelve are two teams sharing a name.
3. Layers between an engineer and the head of engineering. Count honestly, including tech leads who do performance reviews.
4. Share of managers who still ship code. Not whether they should — whether they do, measured in commits last month.
5. Teams that must coordinate to release one typical change. The most informative number and the one almost nobody measures.

Number five is the one I would keep if I could only have one. It converts an abstract debate about structure into an observable property of your delivery pipeline, and it is very hard to argue with.

The 7 Steps, In Order

Step 1. Count the five numbers before you draw anything

Gather the five numbers above for the current structure and write them down where others can see them. This matters more than it sounds, because org design is the area of engineering leadership where opinion most reliably defeats evidence. A manager defending a span of fourteen will argue about philosophy indefinitely and has nothing to say about the number itself.

Step 2. Fix any span above eight before anything else

Five to eight direct reports is the working range for a manager whose job is actually managing people, and eight assumes they are not also carrying their own delivery commitment.

What matters is the specific failure mode, because it is not the one people expect. A manager with fourteen reports does not fail visibly — standups still happen, tickets still move, the chart still looks fine. What disappears is the one-to-one, because it is the only part of the week with no external witness. First it shortens, then it slips, then it is “let’s catch up when something comes up”. Nothing in your delivery metrics changes. Two quarters later you lose three people and the exit interviews say “no growth”, which is what someone says when nobody has had a career conversation with them in six months.

If you cannot split the team, promote a senior engineer into a tech lead role with a defined subset of reports. If you are hiring into that gap instead, hiring a first engineering manager in Singapore covers what the role genuinely requires.

Step 3. Draw team boundaries on deployment units, not skills

The test is concrete: can this team release something a user would notice without another team changing code in the same week? If yes, the boundary is real. If no, you have drawn a line across a dependency.

Skill-layer teams — a frontend team, a backend team, a mobile team — are seductive because they concentrate expertise and make job specifications trivial to write. They also guarantee that every user-visible change crosses at least two boundaries, which quietly converts engineering work into scheduling negotiation between managers with different priorities. In any single sprint the cost is invisible. Over a year it is the dominant tax on your delivery.

The legitimate exception is genuine platform work, where the team’s customers are other engineers. That is a real team type, and it should be created deliberately rather than by default when nobody wants to own shared code.

Step 4. Cap layers at three below the head of engineering

Up to roughly eighty engineers, three layers is enough. Most Singapore teams I review are far smaller than the structure they have built — thirty engineers running four layers is a pattern I see repeatedly.

It is worth being fair about why that happens, because it is not incompetence. Layers get created as a retention response: a strong engineer is at risk, the only available reward is management, so a layer appears. Understandable, and expensive. Each layer adds a translation step in both directions. Context from leadership degrades as it descends; information from engineers is summarised on the way up by someone whose own standing depends on how that summary reads. Both distortions are unintentional and entirely reliable.

The structural alternative is a published technical track that reaches the same compensation band as management, which removes the incentive to invent a layer to keep somebody. If the only mechanism you have for paying an engineer more is giving them reports, your org chart is a compensation artefact rather than a design. The retention angle is covered in retaining senior developers in a competitive Singapore market.

Step 5. Decide explicitly whether managers ship code

Both answers are defensible. A manager of five who writes code two days a week works. A manager of eight who writes none works. What does not work is leaving it unstated, which is the default in most companies under fifty engineers.

In the ambiguous case the manager attempts both, does each at perhaps 60%, and resents whichever one they neglected that week. Worse, their engineers cannot tell which role they are being addressed from in any given conversation — is this a code review or a performance signal? State the expectation as a proportion of time, write it in the role definition, and hold it. Then make sure your review process matches: a manager assessed on commits will manage less, whatever the org chart says. Running developer performance reviews covers how to keep those two things aligned.

Step 6. Test the draft against three real changes from last quarter

This is the step that catches the error no amount of discussion will. Take three changes you actually shipped — not hypothetical future work, which is always imagined to fit whatever structure you just drew — and trace each one through the proposed org chart. Who would have written it? Who would have reviewed it? Which teams would have needed to agree?

If a typical change still crosses three teams in the new structure, the boundaries are wrong, and no process layer will compensate. You will instead spend the next year inventing coordination rituals to work around a line you drew in an afternoon. Redraw it now, while it is still free.

Step 7. Move one boundary per quarter, never all at once

Most organisations do this as a reorg: announce the new chart, move everyone, absorb a bad quarter. I would argue against it in almost every case.

When every boundary moves simultaneously, every working relationship resets at the same time, delivery slows for reasons nobody can isolate, and you learn nothing transferable because twelve variables changed together. Move one boundary. Hold it a full quarter. Re-measure the same five numbers. Then decide the next one. Slower on a spreadsheet, faster in reality, and each change is individually attributable.

The exception: if the current structure is actively losing people, speed outweighs attribution. Even then, move two boundaries rather than all of them.

Two Things That Are Specific to Singapore

Most of the above is general engineering management. Two factors genuinely change the calculation here.

Distributed teams are the norm, not the exception. A very large share of Singapore engineering organisations run part of the team in the region — Vietnam, Indonesia, Malaysia, the Philippines — which interacts badly with wide spans. A manager with eight reports in one office is stretched. A manager with eight reports across three time zones has, in practice, closer to twelve, because every coordination act costs more and the informal signals that tell you someone is struggling do not travel. If your team is distributed, treat six as your ceiling, not eight. The operational side is covered in managing a remote developer team, and if you are standing up a regional pod, staff augmentation in Singapore is a useful comparison of the structures available.

The market rewards title inflation. Engineers here are approached constantly, and the approaches come with titles. That creates steady pressure to hand out lead and manager titles as a retention measure, which is precisely how a thirty-person team acquires four layers. The defence is not refusing titles — it is having a technical track that pays competitively so a title is not the only currency available. Organisations building out AI and platform capability feel this most acutely; structuring an enterprise AI deployment team covers how those roles slot into an existing chart, and hiring a fractional CTO is worth considering if nobody currently owns the structure at all.

Frequently Asked Questions

What is the right span of control for an engineering manager?

Between five and eight direct reports for a manager whose job is genuinely managing people, and the top of that range assumes they are not also carrying a delivery commitment of their own. Below five the manager usually does not have enough to do and starts doing their engineers’ work for them, which is its own problem. Above eight something has to give, and in practice what gives first is always the same thing: the one-to-ones get shortened, then rescheduled, then quietly dropped, because they are the only part of the week with no external witness. Nobody notices on the org chart. You notice two quarters later in regretted attrition, and by then the causal link is invisible. If a manager has eleven or fourteen reports, the honest reading is that you have not got a manager with a big team, you have got a team with no manager and someone attending meetings on its behalf. The fix is either to split the team or to promote an existing senior engineer into a tech lead role with a defined subset.

Should we organise teams by product area or by technical layer?

By deployment unit, which in practice usually means product area, and the test is concrete rather than philosophical. Ask whether a team can release something a user would notice without a second team changing code in the same week. If yes, the boundary is real. If no, you have drawn a boundary across a dependency and you will pay for it in every sprint. Organising by technical layer, so a frontend team, a backend team and a mobile team, is appealing because it concentrates expertise and makes hiring specifications easy to write. It also guarantees that every single user-visible change crosses at least two team boundaries, which converts ordinary engineering work into scheduling negotiation between managers who have different priorities. The cost is invisible in any individual sprint and enormous over a year. The exception worth respecting is genuine platform work, where a team’s customers are other engineers rather than end users. That is a real team type and it should be staffed deliberately rather than created by accident when nobody wants to own the shared code.

How many management layers does a Singapore engineering team need?

Three below the head of engineering is enough up to roughly eighty engineers, and most teams here are considerably smaller than the structure they have built. The pattern I see repeatedly in Singapore specifically is a company of thirty engineers running four layers, because the organisation grew by promoting people into management as a retention response rather than because a layer was needed. That is an understandable decision made for good reasons, and it is expensive. Each additional layer adds a translation step in both directions: context from leadership degrades as it descends, and information from engineers is summarised on the way up by someone whose own performance depends on how it reads. Both distortions are unintentional and both are reliable. The structural alternative to promoting a strong engineer into management is a published technical track that reaches the same compensation band, which removes the pressure to create a layer in order to keep somebody. If the only way to pay someone more is to give them reports, your org chart is a compensation artefact.

Can we fix span of control without doing a full reorg?

Yes, and you should, because a full reorg is usually the most expensive available way to solve this and the hardest to learn from. When every boundary moves at once, every working relationship resets simultaneously, delivery slows for a quarter for reasons nobody can attribute, and you cannot tell which of the twelve changes helped. Move one boundary per quarter instead. Split the one overloaded manager, or shift the two misplaced engineers, then hold the new shape for a full quarter and re-measure the same five numbers you started with. This is slower on a spreadsheet and faster in reality, and it has a property a reorg never has: each change is individually attributable, so you learn something you can apply to the next one. The exception is when the current structure is actively losing people, in which case speed matters more than attribution. Even then, move two boundaries rather than all of them.

Bryan

Delivery & Offshore Teams Expert at HireDeveloper.sg. Structures dedicated and distributed engineering teams for Singapore employers and reviews reporting lines before headcount is approved.