Key Takeaways
- Conway’s Law says a system’s structure mirrors the communication structure of the organisation that built it. Read forward, it predicts where your dependencies will be before anyone writes a ticket.
- Every team boundary an epic crosses is a queue the committing team does not control — which is why dependencies are the killer a confidence vote is least equipped to price.
- The vote is expert engineering judgment and it is sound. The problem is information asymmetry: half the relevant data lives on somebody else’s board.
- A program board or dependency map is accurate the day it is drawn. The org chart that produced it keeps generating new dependencies all quarter.
- Release Management, Roadmaps, Portfolio PPM & Timeline reads blocking links from live Jira and re-forecasts the committed date at 50/85/95% confidence, so an unresolved dependency reads as days against the date.
Week three of the increment. A developer opens the story everyone agreed was straightforward and finds it needs a change to the identity service. The identity service belongs to the platform team. The platform team is two boxes over on the org chart, mid-sprint, carrying commitments of its own.
Nobody hid this. It simply was not anybody’s job to notice it in the room where the date was agreed. That is not a planning failure. That is Conway’s Law, arriving on schedule.
Conway’s Law is a forecasting statement
In 1968 Melvin Conway observed that any organisation which designs a system will produce a design whose structure is a copy of that organisation’s communication structure. It is usually quoted in architecture arguments — microservices shaped like the teams that own them, monoliths shaped like the department that built them.
For release planning it says something more useful and rather less comfortable: your org chart drew your dependency map before anyone wrote a ticket. Every boundary between teams is a candidate handoff. Every handoff is a queue you do not control. If you know where the boundaries are, you already know where the delays will cluster. What you do not know is which of them will bite this particular release.
Why the confidence vote cannot see them
When a room raises a fist of five at the end of PI planning, it is applying expert engineering judgment to a real question. The team knows its own throughput, its own scope and its own people, and it prices all three honestly. People who have shipped this system before are the best instrument available for that question.
What that judgment cannot price is the queue depth on the other side of a boundary the team does not own. That is not optimism and it is not a skills gap. It is information asymmetry — the vote is sound, and half the data it depends on sits in another team’s backlog, changing weekly without anyone sending a note.
This is the second of the three things that erode a release date: dependencies surfaced too late, alongside scope creep and capacity change. All three behave the same way. They move a committed date quietly, after the room has emptied.
Where Conway’s Law shows up in days
Handoff count. The more team boundaries an epic crosses, the more independent queues stand between started and done. Two boundaries is not twice the exposure of one; the waits compound, because each queue reorders on its own schedule.
Queue position, not queue existence. Everyone already knows the platform team is a dependency — it is on the board, in the RAID log, in the plan. What matters to your date is where your request sits in their sprint this week. That is the number nobody publishes, and when the other team is a vendor rather than a colleague the visibility is worse still.
Reorganisation. The inverse Conway manoeuvre — reshaping teams to get the architecture you want — is a legitimate move and often the right one. It is also a capacity event and a dependency event at the same instant, and it re-prices a committed date on both counts. Mid-increment, that cost is rarely counted.
The map is a snapshot. The org chart keeps running.
Most teams already draw the dependency picture. SAFe calls it the program board; PMOs keep it in the D column of a RAID register. Both are accurate on the day they are drawn and decay from there, because the structure is fine and the refresh rate is not. Meanwhile the communication structure that produced those dependencies is still operating, still generating new ones, all increment long.
A confidence vote is a snapshot too. The difference between a snapshot and a live reading is not accuracy — it is when you find out.
What it looks like in Jira
This is the gap Release Management, Roadmaps, Portfolio PPM & Timeline is built to close. It does not model your org chart, resolve a dependency for you, or re-run the vote with better arithmetic. The team still owns the assumptions: which throughput window is representative, whose capacity is genuinely in, what is really in scope.
What the app does is read the blocking links on in-scope work as they stand today — including the one added three weeks after commitment — re-run a Monte Carlo forecast over your team’s actual Jira throughput, and report the committed date carried with its confidence band at 50, 85 and 95%. When a dependency stays unresolved, the movement appears as a gap in days, attributed to dependencies rather than lumped in with scope and capacity.
Four days in week three is a sequencing conversation with a team two boxes over. Twelve days in week nine is an apology to a customer. Same dependency, different week, and the train departs on the same date either way — what changes is whether you chose what was on it.
Renegotiate before you slip
Conway’s Law is not a problem to solve. You cannot restructure your way out of every boundary, and you certainly should not try mid-increment. What you can do is stop treating the dependency map as a planning artefact and start treating it as a live number attached to a date.
Your org chart already told you where to look. See what your dependencies cost your next Fix Version, free for 30 days. It Runs on Atlassian, so your Jira data never leaves Atlassian.
Frequently asked questions
What is Conway’s Law?
Conway’s Law is Melvin Conway’s 1968 observation that any organisation designing a system will produce a design whose structure copies that organisation’s communication structure. It is most often cited in software architecture — service boundaries tending to mirror team boundaries — but it applies equally to delivery schedules, because the same team boundaries determine where work has to be handed off, queued and waited on. In release planning terms, the org chart is a reasonable first draft of the dependency map.
How do you keep cross-team dependencies from moving a release date?
Record them where they change on their own rather than in a document that changes when someone remembers. In Jira that means blocking issue links on in-scope work, so dependency state is live data rather than a status a meeting assigned. Release Management, Roadmaps & Portfolio reads those links continuously and re-forecasts the committed date at 50/85/95% confidence, reporting dependency-driven movement in days and separately from scope and capacity. The mechanics of what is read and what is not are documented in cross-team dependencies and the committed release date.
1 Comment
Leave your reply.