The agenda is the call graph, not the seating chart

Watch how your standup actually decides who talks next. It's rarely a decision at all — it's whoever's sitting closest to the door, or whoever the tool alphabetizes first, or the reporting chain on the org chart, going down by title. None of these orderings have anything to do with which pieces of work depend on which other pieces of work. And that mismatch is not a scheduling inconvenience. It's a structural reason your standup keeps failing to catch the thing it exists to catch.

The 1968 essay everyone's heard of and almost nobody has actually applied here

Melvin Conway's 1968 essay "How Do Committees Invent?" is famous for one line, quoted so often it's practically wallpaper in engineering circles: organizations that design systems will produce designs that mirror their own communication structure. Everyone nods at Conway's Law when it's about microservice boundaries matching team boundaries. Almost nobody applies the same insight to the fifteen minutes where the team talks about the system out loud every single day.

Here's the version of Conway's argument that actually matters for a standup: if your meeting's structure — who talks, in what order, about what — mirrors your org chart instead of your system's actual dependency structure, you have built a meeting shaped like your company instead of a meeting shaped like your codebase. And the codebase, per this entire series, is the thing that's going to grade every claim anyone makes. A meeting shaped like the org chart is optimized for a completely different object than the one it's supposed to be coordinating.

What "shaped like the codebase" would actually mean

Picture the alternative. Function A calls function B calls function C. If someone's about to report on a change to A, and someone else worked on B this week, and B feeds directly into what A does — that's not a coincidence worth ignoring, it's the single most useful adjacency the meeting could surface, and an org-chart-ordered agenda will almost never put those two updates next to each other, because A and B's owners might sit in entirely different reporting lines. The information the meeting needs to catch — "wait, did your change to B break something A depends on?" — sits exactly where the technical dependency is, and almost never where the seating chart or the manager hierarchy happens to put it.

The research that measured this, not just argued it

Marcelo Cataldo, James Herbsleb and Kathleen Carley gave this intuition an actual name and a measurement: socio-technical congruence — the degree to which a team's actual coordination patterns (who talks to whom) match the technical dependency structure of the system they're building (what actually depends on what). Their empirical result, from real software projects, is the number worth remembering here: when developers' coordination matched the technical dependencies — people talking to the people whose code their code actually touched — the average resolution time for modification requests dropped by roughly 32%. Not because anyone worked harder. Because the conversations that needed to happen were happening between the people who actually needed to have them, instead of between whoever happened to be adjacent on an org chart.

Notice what socio-technical congruence is not: it isn't a claim that reporting lines are bad, or that managers shouldn't run standups. It's a much narrower and more useful claim — that the specific ordering and grouping of a coordination conversation should track the technical dependency graph, because that's the graph where the actual coordination failures live. A team can have a perfectly sensible org chart and a badly incongruent standup at the same time; the two structures were never guaranteed to line up, and nobody designed them to.

What this looks like applied

You don't need a full dependency-graph visualization to get most of this benefit — you need the discipline to ask one question before the meeting: which of today's updates touch functions that other today's updates also touch, directly or one hop away? Group those together, whatever the org chart says, and put them early, while the room still has attention to spend. The person whose change quietly calls into your change is a more useful neighbor in the agenda than the person who happens to share your manager.

Conway's Law says your system will end up shaped like your org chart if you're not careful. Socio-technical congruence says the reverse fix is available too — shape your coordination, on purpose, like your system, and watch resolution times move.

This is precisely the ranking principle behind a good pre-scrum brief's "what actually changed" section: ordered by the Reach of what a commit touched, not by who committed it or what team they're on, so the people whose work is genuinely adjacent in the call graph end up adjacent in the meeting too — even when they've never once been on the same reporting line.

The test

Here's a cheap way to check your own team's socio-technical congruence without any tooling at all. Take your last five standups. For each one, ask: did any two updates in the same meeting touch functions that call each other? If yes, were those two updates discussed back to back, or separated by four unrelated reports because that's just the order people happened to speak in? If the honest answer is "separated," you've found real, free coordination time being wasted on an ordering that has nothing to do with what your codebase actually looks like underneath the org chart.