Allocation, not consumption: what an engineering manager should measure

There is a request that arrives in every engineering organisation eventually, usually from outside engineering, usually phrased helpfully. Could we see how people are spending their time? Could we get completion rates per engineer? Could we have a delivery score?

The request is not malicious. It comes from someone accountable for outcomes who has no instrument, and it is asking for an instrument. The problem is that the instrument being asked for measures the wrong thing and damages the thing it measures.

Two categories that get confused

Allocation is what people are committed to. Person A is committed at 0.6 of their time to this demand this quarter. This team has agreed to four FTE-months of work and has three available. This task is assigned and due Friday. This task is three days overdue. This initiative's timeline moved by two weeks.

Consumption is what people actually spent. Hours logged against a task. When someone started work. Average completion rate across tickets. Velocity across sprints. Billable hours. A per-person delivery score.

Both look like "visibility into engineering". They are not the same instrument and they do not answer the same question.

Allocation answers the questions you are accountable for

Consider the decisions an engineering manager actually has to make in a given month:

• Can we take this on? — needs allocation.
• What breaks if we do? — needs allocation.
• Who is overloaded right now? — needs allocation.
• What is late, and what does it block? — needs allocation.
• What did this initiative cost us in people-time, roughly? — needs allocation.

Not one of those needs an hour count. They need to know what has been promised, to whom, at what size, and what is currently not on schedule. Allocation data is sufficient for the entire job.

Consumption answers a question nobody needs, badly

The stated purpose of per-person consumption metrics is to find who is underperforming. Set aside whether that is a good goal and look at whether the data can support it.

Completion rate is a function of what you were assigned. Whoever gets the gnarly integration will have a worse rate than whoever gets the copy changes, and the difference measures the assignment, not the person. Velocity is a function of estimate inflation, and it is self-correcting in the wrong direction: a team that knows velocity is watched produces a rising velocity curve and unchanged output. Hours logged measure the diligence of the logging.

Each of these numbers is real, in the sense that it exists and can be put in a chart. None of them is valid, in the sense of measuring the construct it claims to measure. And a manager who genuinely has an underperformance problem already knows, from the work, without any of it.

The measurement destroys the measurement

This is the part that matters most and gets discussed least. Allocation data stays accurate when it is watched, because being honest about your load is in your interest — an accurate picture is how you avoid being given more.

Consumption data stops being accurate the moment it is watched, because being honest about your hours is against your interest. Time gets logged to the ticket that looks best, estimates drift upward, tickets get split to raise the count. Everyone involved understands what is happening and nobody says so, and the organisation now runs on a number that is systematically wrong in a direction it cannot detect.

So the choice is not "more data versus less data". It is "data that survives being looked at versus data that does not".

The second-order cost

There is also what it does to people, and it is worth stating without sentimentality. An engineer whose workload is visible feels acknowledged — someone can see they are carrying three things. An engineer whose hours are visible feels monitored. These produce opposite behaviours. The first makes people flag overload early, which is exactly the signal you want. The second makes people hide it, because admitting slack invites more work and admitting slowness invites scrutiny.

You end up paying for a system whose main effect is to suppress the information you built it to collect.

What to say when you are asked

"No" is a bad answer to someone with a legitimate need. A better one is to offer the allocation view and be specific about what it can and cannot do:

I can show you what every team is committed to this quarter, how much capacity that consumes, what is currently overdue and what it blocks, and a forecast of what an initiative costs in people-time. I can't show you per-person hours or throughput scores — those numbers stop being true as soon as people know they're being read, and then we'd be making decisions on them anyway.

In my experience this lands, because the person asking wanted an instrument and you just handed them one.

Where I have drawn the line

DeliverySheet is built on this distinction and refuses the other side of it as a matter of design, not backlog order. It shows allocation — who is committed to what, at what size, what is overdue, what a commitment forecasts in cost. It does not do time tracking, per-person completion rates, velocity, delivery scores, or actual-cost consumption, and those are on a written list of things it will never do.

On cost specifically the line is: forecasting, not tracking. A monthly estimated cost per person exists so that a commitment can carry a defensible figure. It is visible to workspace administrators only, never to the person it describes, and it is an estimate for planning — never a salary, never a record of what was actually spent. The product surfaces the data a finance team needs to do inter-departmental chargeback; it does not perform the chargeback.

Constraints like these are easy to write and only mean something when refusing a paying customer's request. So consider this the public version, written down in advance.