A team of six owns nineteen services and is missing every deadline. They ask for more engineers. Is that the right answer?

What the interviewer is testing

Whether you can diagnose an ownership problem rather than accepting a headcount request at face value.

The diagnosis

Nineteen services across six people means each engineer must hold three services in mind — their domain, dependencies, deployment, telemetry, failure modes and history. Add on-call across all nineteen and the team is operating past its cognitive load capacity.

Adding engineers helps only if the load is genuinely additive. Frequently it is not: the coordination cost of a larger team, and the fact that each new engineer must learn nineteen services, means the throughput gain is much smaller than the headcount suggests.

The questions to ask first

How many of the nineteen are actually alive? Estates like this usually contain services with no meaningful traffic. Decommissioning is the cheapest capacity available.

Should some of them be one service? Nineteen services for six people usually indicates services split by technical layer or by entity rather than by capability — a distributed monolith where every feature touches several. Merging reduces both operational surface and change coordination.

Which services belong to a different team? Some were probably inherited during a reorganisation and have no relationship to this team's domain.

How much of the load is extraneous? If deployment is brittle, the runbooks are absent and there are twelve tools to ship one change, that burden is removable by platform investment rather than by hiring.

The reframing

Service boundaries should be drawn so that a team's total load fits. That is a design constraint, not a soft consideration — and the standard argument for splitting or merging services is often really a cognitive load argument.

What a strong answer adds

If headcount is genuinely needed, splitting into two teams with a clean domain boundary is far better than one team of ten owning nineteen services, because it reduces per-person load rather than distributing the same load more thinly.

Common weak answers

Approving the headcount without diagnosis. Refusing it and telling the team to prioritise better.