What 29 engineering leaders told us about project status

Who we spoke to

The group spanned three perspectives on the same problem.

• Twelve senior leaders — VPs of engineering, heads of engineering, group project managers and general managers, responsible for between 30 and 200 engineers across as many as 20 teams.
• Eight project and product managers — the people who actually assemble the status reports everyone else reads.
• Nine developers and team leads — including principal engineers and people who had recently moved from writing code to leading a team.

They worked at large SaaS companies, a container platform company, a collaboration software vendor, and enterprise IT organisations. We have kept everyone anonymous and removed company names. Quotes are verbatim.

Finding 1: leaders get blindsided by teams that already knew

This was the pattern that prompted the research, and it recurred throughout it. The clearest example came from a head of engineering responsible for 100 engineers across nine or ten teams, describing a major delivery:

"I trusted what I was told by the dev manager. Two weeks before the summit, I was told they weren't going to deliver everything that was promised."

The information existed. The team knew. The dev manager likely knew before he said it. What failed was the channel between them, and it failed in a specific, structural way that a group project manager for a collaboration product named exactly:

"Human summation at every level."

Between the engineer who first notices the integration isn't behaving and the executive who needs to know the date is at risk, there are typically two or three people. Each summarises. Each has a reasonable motive to present a considered picture rather than raw doubt. None of them is lying. The signal degrades anyway.

Finding 2: everyone wants to be green

This was the most consistent finding in the study, and it came from every level — leaders, project managers and developers all described it, each from their own vantage point.

"Everyone wants to be green. Executive sponsor wants to look good." — developer, large SaaS company

"Ninety per cent of the time it's a direct update. Ten per cent embellished if the team is almost shipping the thing — leading to sugar coating." — project manager

A project manager explained the mechanism precisely, and it isn't dishonesty — it's the reporting format itself:

"Switching a ticket from green to yellow is such a big step change that it sets off all the alerts. There is a cost to calling out problems."

Traffic-light status forces a continuous worry into a discrete alarm. A team leader who is 70% confident has no way to say so; they must choose green, which is a lie of omission, or amber, which triggers escalation, meetings and attention. The format makes the honest answer expensive.

Culture magnifies it. A group project manager described a previous employer:

"A culture where everything was green. You'd get raked over the coals for saying something was red."

Finding 3: the leaders didn't want detail — they wanted a verdict

Asked what they actually needed, senior leaders were consistent and blunt.

"Don't care about the words. I want to know if I'm in trouble or not. Does he need my help or not?" — VP of engineering, 120 engineers

"How do I get a lay of the land? An honest appraisal of the state of the project?" — group project manager

"We do weekly deliveries, but even at that, on Wednesday I want to know if we're on track." — engineering leader

The gap between what leaders said they needed — a current, honest, low-resolution verdict — and what their systems produced — a detailed, stale, filtered narrative — was the widest gap in the study.

Finding 4: the reporting tax is larger than anyone budgets for

We didn't ask how long status reporting took. People volunteered it, usually with irritation.

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

"Eight hours a week." — product lead describing a weekly status process, container platform company

"Usually takes about an hour or two to stay current. You can spend as much time as you want on it. Don't get that much interaction on the page — a few comments here and there." — team lead, 7 engineers

A principal project manager responsible for 150 engineers summarised the whole activity in one line:

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

The cost compounds quietly. An hour a week from each of thirty team leads is more than a full-time role, spent producing documents that a developer in the same study described this way:

"Doubt anyone read it." — developer, large SaaS company

Finding 5: reporting systems get heavier over time, never lighter

Several people described the same trajectory: a lightweight process that worked, then accreted.

"It started out good, but any single source of truth gets a lot of extra data added to it. It used to be a two-line update every two weeks — then it got super complicated." — group project manager, 180–200 engineers

Nobody decides to make status reporting expensive. Each addition is individually reasonable — an executive asks a question, a field is added so the question is answered next time. The result is a form that costs an hour and answers questions nobody is asking any more.

A group project manager responsible for 160 engineers across 14 teams described the version her organisation used:

"Weather reports are highly manual. Inconsistent. Another thing for someone to update."

Finding 6: the reports need enforcing, which is the tell

Two separate leaders, at different companies, independently used the word "ruthless" about compliance.

"You need something — someone — to enforce compliance." — group project manager, who did that enforcing himself

"It would be completely ineffective unless ruthless responsibility is enforced." — head of engineering for a server product line, 130–250 engineers

A VP of engineering responsible for 120 engineers put the same problem from the other side:

"Can't get my guys to fill in their status reports. Or if they do, to get the right level of detail."

A process that requires enforcement is one where the people filling it in have concluded the effort exceeds the value. Enforcement treats the symptom.

Finding 7: developers wanted something nobody was building

We expected developers to see status reporting as pure overhead. Most did, for their own status. But nearly every developer we spoke to independently raised the same unmet need: visibility into other teams.

"Would be beneficial to see the status of other teams who I'm dependent on." — developer

"I'm impacted by other teams sometimes — seeing how their things are going would be helpful." — developer

"When working on a cross-functional team this would have made their life a lot easier." — senior developer

Status reporting is built to move information upward. Developers are blocked by things moving sideways, and almost nothing in the standard toolkit serves that.

What people worried about

We also asked what would stop this working. The objections were sharper than the enthusiasm, and they shaped what we built.

"Does this become a hammer in the hands of management?" — group project manager

"No matter how innocuous it is — if this is being used by my boss, it will colour my feedback." — developer

"I have a lot of signals. Will this one be more useful?" — head of engineering

"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." — senior engineering leader

"The biggest challenge is getting the individual contributor to click that button." — engineering leader

Those five objections are, in our view, the real test of any tool in this space. We have written separately about whether anonymous feedback becomes a weapon for management and why anyone should add another signal to an organisation that already has several.

What we concluded

Three things, which became the design of Genchi.

The information already exists. In almost every account of a missed deadline, somebody knew. The problem is transmission, not detection.

The format determines the honesty. A free-text status field asks someone to compose a defensible narrative. A traffic light asks them to trigger an alarm or not. Neither makes it cheap to say "I'm somewhat less confident than last week", which is the most useful thing a person can say.

Effort has to be near zero for the people at the bottom. Every system in the study that required real effort from individual contributors either required enforcement or decayed. The tax has to be paid by the tool, not the team.