Your headcount requests keep getting rejected as unclear. How do you make a better case?

Tie it to data and outcomes (interrupt load, incidents, roadmap slips), state the expected effect of the hire, the cost, the deadline, and what you'll drop if the answer is no.

What should come first in a monthly update to leadership?

The headline — what changed and what's at risk — followed by outcomes, risks and concrete asks; activity details belong in linked appendices.

Why should managers surface problems early rather than at scheduled reviews?

Early warnings give leadership time to use their levers (priorities, budget, people); late surprises remove options and damage trust.

Reporting Up and Representing Your Teams — The Engineering Manager Handbook (Development Manager)

Scenario

Example organisation: the director runs a monthly business review. Each engineering manager presents 15 slides of activity: tickets closed, features shipped, meetings held. Risks appear on slide 14. Headcount requests are rejected because "the case isn't clear".

What you see on the team

Leadership surprised by delays, attrition or incidents.
Long, activity-heavy reports that nobody reads fully.
Requests (headcount, budget, priority changes) rejected or delayed.
Teams feeling their work is invisible to leadership.

The common mistake

Reporting activity and good news at length, with risks buried and asks vague, instead of outcomes, risks and decisions in a format leadership can act on.

Why it happens

Managers want to show their teams are busy and doing well, and they mirror the format they've seen. But leaders have limited attention and many teams; they need to know what changed, what's at risk and what they should do.

The playbook

Lead with what leadership must know or decide:

Payments org - October update
Headline: card migration 85% likely by 14 Nov (2 weeks late); attrition risk on Team B.
Outcomes: payment success rate 99.93% (SLO 99.9%); checkout p95 640 ms (-18%).
Risks:
 - Card migration: fraud-team dependency unscheduled -> asking for decision below.
 - Team B: 2 of 6 engineers interviewing elsewhere (pay below market, see data).
Asks:
 1. Decision by 20 Oct: prioritise fraud-team change in their Q4 plan.
 2. Approve market adjustment for 2 engineers (attached comparison).
People: 1 promotion (Senior), 1 hire accepted, 1 open role.

Use outcomes and trends, not activity: SLOs, delivery metrics, customer impact.

Make asks concrete: what, why, cost, by when, the alternative if not.

Represent people honestly: workload, morale and wins — leadership can only advocate for what it knows.

No surprises: escalate significant risks as soon as you see them, not at the monthly review.

What to say

Making a headcount case:

"Team A carries 40% of on-call incidents and runs at about 70% interrupt load; their roadmap slips every quarter. One additional engineer would bring planned work from 30% to roughly 50% of capacity. If we don't add one, I recommend dropping the partner-API project this half."

Trade-offs

Brevity hides nuance; link to details for those who want them.
Honesty about problems can feel risky; leadership trusts managers who surface problems early more than those who are always green.
Asks can be refused; always include the alternative if the answer is no.

Signals it's working

Leadership isn't surprised by delays, incidents or departures.
Your asks get clear yes/no decisions quickly.
Your updates are short and read.
Your teams' work and people are visible in leadership discussions and promotions.

Key points

Lead with what leadership must know or decide: headline, outcomes, risks, asks.
Report outcomes and trends, not activity.
Make asks concrete with cost, deadline and the alternative.
No surprises: escalate early; represent people and wins honestly.