How much time does status reporting actually cost?

The numbers people gave us

We interviewed 29 engineering leaders, project managers and developers. We never asked how long status reporting took — they volunteered it, usually with some irritation.

"People set aside an hour to fill in the status tool on a Friday." — group project manager, 180–200 engineers

"Eight hours a week." — product lead, describing his company's weekly status process

"Usually takes about an hour or two to stay current. You can spend as much time as you want on it." — team lead, 7 engineers

Then the meetings. One principal project manager, responsible for 150 engineers, described his week: a thirty-minute scrum-of-scrums with the leadership team at nine every morning, daily leadership standups with all PMs and team leads, plus written updates. That's roughly five hours a week of his own time, before he writes anything, and it's simultaneously consuming an hour a day from everyone else in those meetings.

His summary:

"Keeping abreast of status: a lot of effort and a pain in the ass."

The arithmetic

Take a 150-person engineering organisation with fifteen teams. Conservative assumptions, using the low end of what people reported.

• Production. Fifteen team leads × 1 hour weekly = 15 hours
• Aggregation. Three managers-of-managers consolidating those into their own summaries, 2 hours each = 6 hours
• Meetings. One weekly status meeting, 45 minutes, 12 attendees = 9 hours
• Consumption. Leadership reading the output, 1 hour each across 5 people = 5 hours

Roughly 35 hours a week. Just under a full-time role, spent moving information that mostly says things are proceeding as expected.

Two things that arithmetic misses, both of which push the number up.

Context switching. An hour of status reporting on a Friday afternoon isn't an hour taken from an otherwise fungible day. It's an interruption to the deep work the team lead was doing, and the recovery cost isn't captured by the sixty minutes.

The dread. Several people described the Friday status update as the worst part of their week. That has a cost that doesn't appear on any timesheet.

What the money buys

A full-time role's worth of effort would be defensible if the output were reliable. The uncomfortable part is what people said about that.

"Doubt anyone read it." — developer, describing his organisation's status tool

"It turned into a big deal to fill in and a big deal to consume." — group project manager

And when it is read, it's frequently not in the form the reader wanted. A VP of engineering responsible for 120 engineers:

"Don't care about the words. I want to know if I'm in trouble or not. Does he need my help or not?"

So: 35 hours a week producing detailed narrative documents for an audience that wanted a verdict, with a known tendency to be optimistic about exactly the projects you needed accurate information on. That's the actual trade.

Why it never gets counted

Three structural reasons the cost stays invisible.

It's distributed. No single person spends a lot. Fifteen people spending an hour is invisible in a way that one person spending fifteen hours would not be.

It's nobody's budget. The reporting process has no owner with a cost line. It's absorbed into everyone's week as overhead.

It accretes gradually. Nobody approves a one-hour status process. They approve a two-line update, and then a field gets added each time an executive asks a question the format didn't answer:

"It used to be a two-line update every two weeks — then it got super complicated." — group project manager

The comparison that matters

The alternative isn't zero. Some cost is unavoidable — the information genuinely needs to move. The right question is what the cheapest sufficient mechanism costs.

A two-second check-in, weekly, from every person in that 150-person organisation is five minutes of total organisational time per week. Even allowing generously for interruption and for the people who add a comment, call it under an hour.

Against 35. And the output is arguably better, because it comes from everyone rather than from fifteen summarisers — see why status reports don't reflect what's actually happening.

A senior leader in our research framed the test correctly:

"The tax on me is nothing. But on my group? I'm going to make 500 people spend five minutes doing this. So it needs to work."

Exactly right — and it's why the cost per person is the whole design constraint. Five minutes per person across 500 people is 40 hours a week, which would be no improvement at all. Two seconds is roughly twenty minutes.