How do I see the status of the teams my work depends on?

The thing developers asked for that nobody builds

We interviewed 29 people while designing Genchi, including nine developers and team leads. We expected them to view status reporting as pure overhead, and for their own status they did.

What we didn't expect was that nearly every one of them independently raised the same unmet need, unprompted:

"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

"Getting visibility into people from other teams' work — for example, being a consumer of a platform team." — team lead

A principal developer described the underlying problem in general terms:

"When you have to coordinate with other teams, their goal was not always shared. You need to work closer with other teams."

Why the information doesn't travel sideways

Every reporting mechanism in a normal organisation is oriented vertically. Status reports go up. Escalations go up. Portfolio dashboards aggregate upward. Even standups, which are horizontal within a team, stop at the team boundary — and stop harder once a large standup gets split, which several people described doing.

So the route from Team A to Team B runs up to a shared manager and back down. Three consequences:

It's slow. Two hops through people with other priorities.

It's exception-triggered. Nothing travels down that path until something has already gone wrong. By definition you find out after the fact.

It's lossy. Each hop is a summarisation, and summarisation removes uncertainty first — see why bad news gets softer as it travels up. The doubt that would have been useful to a dependent team is exactly what gets cut.

Why the usual workarounds don't work

Asking them

The obvious move, and it fails for a reason that isn't anyone's fault. "Are you still on track for the fifteenth?" is a question with a social cost attached to the honest answer. The person answering doesn't want to alarm you, isn't certain yet, and knows that "probably" invites a longer conversation. So you get "should be fine."

It also depends entirely on the relationship. You ask the team you know. The dependency that hurts is usually the one where you don't know anyone.

Reading their tracker

Better, and still insufficient. An issue tracker shows what's been done and what's open. It doesn't show whether the people doing it believe the date holds — and a team can be moving briskly through tickets while privately convinced the deadline is gone. A team lead in our research noted the related problem that trackers drift out of date anyway:

"People forget to update the status of their Jira issues from review to shipped."

Attending their standup

It works, and it doesn't scale. Two dependencies is four standups a week. It also changes the standup: an outsider in the room shifts what people say, particularly if they're a customer of the work being discussed.

The platform team problem

Worth naming separately, because it's the sharpest version. A platform team has many dependents, and each of them is invisible to the others. If the platform migration is slipping, five feature teams are each independently making commitments that assume it won't — and none of them can see the others making the same mistake.

A developer in our research pointed out that platform teams also have the weaker connection to company goals: feature teams map to strategic initiatives fairly directly, while platform work is one step removed. That makes the platform team's own confidence signal harder to interpret, and more valuable, since the failure propagates across everyone downstream.

What horizontal visibility requires

Three properties, and they're mostly the inverse of what vertical reporting provides.

• Visible by default, not on request. If seeing another team's status requires asking, you've reintroduced the social cost and the relationship dependency. It has to be readable without anyone being asked.
• The same measure for every team. Comparable readings mean you can interpret a team you've never worked with. Free-text updates aren't comparable across teams — a paragraph from a team you don't know is nearly unreadable.
• Forward-looking. "What have they done?" is the wrong question. "Do they believe they'll hit the date?" is what your own planning depends on.

There's a fourth, cultural one: the upstream team has to be comfortable with their signal being visible to dependents. That's easier when the signal is aggregated and no individual is exposed, and easier still in organisations that treat a declining number as a request for help.

How Genchi does this

Every initiative carries the same confidence signal, and initiatives are visible across the organisation rather than only up a reporting line. Anyone can see how the teams they depend on are tracking without asking, sitting in a standup, or waiting for something to escalate.

Initiatives can be linked in parent-child structures, so a platform migration and the feature work depending on it can sit in a visible relationship rather than as unconnected cards.

And because the signal is comparable across teams, a reading from a team you've never worked with is interpretable — which a paragraph of their prose would not be.