Miscommunication: The Rework Cause Nobody Measures
Updated 17 April 2026
"Organizations which design systems... are constrained to produce designs which are copies of the communication structures of these organizations."
Melvin Conway, "How Do Committees Invent?", Datamation, April 1968.
Conway's Law is usually discussed as an architectural principle: your system will mirror your org chart. Its rework implication is less often stated: communication gaps between teams become defects in the interface between their systems. Those defects are discovered at integration time -- a late and expensive discovery stage in the IBM 1-10-100 framework.
Miscommunication-driven rework is the hardest category to measure because it does not surface as a distinct ticket type. It shows up disguised as requirements defects (the requirement was communicated but misunderstood), integration failures (two teams built to different assumptions about the interface), and incident response (a deployment decision was made without the team that knew the risk). The Atlassian State of Teams 2024 identified unclear ownership and undocumented decisions as two of the top five drivers of team inefficiency.
Four Specific Failure Modes
Async-Sync Mismatches
A decision is made in a synchronous meeting (or a Slack thread that moves fast). The engineers not in the meeting receive the decision via ticket update, which lacks context. They implement based on their interpretation of the decision. The interpretation differs from what was decided. Rework.
How to measure it: Track tickets with more than 3 comment exchanges before status change as a proxy for async communication failure. High-comment tickets often indicate unclear handoff.
Ticket Handoff Without Context
A ticket is created by product, accepted by an engineer, and implemented without a conversation. The ticket contains the what but not the why. The engineer makes a reasonable choice for an assumed why that turns out to be the wrong why. The feature is functionally correct but contextually wrong. Rework.
How to measure it: Sprint retrospective question: 'Did you have all the context you needed when you started this ticket?' Track the percentage of tickets where the answer is no.
Siloed Domain Knowledge
An engineer who owns a service goes on holiday, changes teams, or leaves. Another engineer picks up a bug ticket in that service and does not know that a seemingly unrelated function has a side effect that the original engineer knew about. The fix introduces a regression. Rework. The root cause is knowledge that lived in one person's head rather than in the code, tests, or documentation.
How to measure it: Identify single points of knowledge: services or modules where one engineer is mentioned in more than 70% of PRs, commits, or incident responses. These are rework risk areas.
Undocumented Decisions
The architecture decision is made in a meeting. It is not documented. Six months later, a new engineer (or the same engineer who has forgotten) makes a change that contradicts the decision because they do not know about it. The change breaks something. Rework. The root cause is the absence of an architecture decision record (ADR).
How to measure it: Review the last 3 months of significant bugs in retrospective. For each one, ask: 'Was there a prior decision that, if documented and visible, would have prevented this?'
Remote and Hybrid Specifics
GitLab's Remote Work Report and the Atlassian State of Teams 2024 consistently identify remote and hybrid teams as having higher incidence of communication-driven rework than co-located teams. The mechanisms:
- Time zone handoffs. Work handed off across a 12-hour time zone gap cannot be clarified immediately. Ambiguities sit for 12 hours before they can be resolved -- often after the next engineer has already made an assumption and started implementing.
- Slack vs. Linear tradeoffs. Decisions made in Slack are invisible to anyone who joins the conversation late, is not in the channel, or searches for the decision later. Decisions that live in Slack are decisions that will be re-made -- generating rework when the re-made decision conflicts with what was already built.
- Missing ambient context. Co-located teams overhear conversations and absorb domain context informally. Remote teams do not. Domain knowledge concentrates in individuals who then become single points of failure.
- Meeting overload as a compensating mechanism. Remote teams sometimes add meetings to compensate for lost informal communication -- which is expensive and often does not solve the information distribution problem because meetings are synchronous and synchrony is the scarce resource in distributed teams.
Prevention Playbook
Architecture Decision Records (ADRs)
Every significant architectural decision gets a short document in the repository: what was decided, what alternatives were considered, why this choice, and what the expected consequences are. Format: Markdown file in /docs/decisions/. Searchable. Linkable. Versioned with the code. The standard format (Michael Nygard, 2011) works well: Status, Context, Decision, Consequences. ADRs prevent the 'why did we do this?' rework that comes from re-litigating settled decisions.
Design Reviews for Cross-Team Changes
Any change affecting two or more teams gets a 30-minute async review -- a written document with proposed change, rationale, impact on each affected team, and a comment window of 48 hours. No code is written until the review window closes and comments are resolved. This catches integration assumption mismatches before implementation begins. Not required for single-team changes.
Three-Amigos Sessions
Developer, tester, and product owner review every story above 3 points before sprint start. The explicit goal is to surface communication failures before they become implementation failures. The tester surfaces testing ambiguities. The developer surfaces implementation questions. The product owner resolves both. Stories that cannot be agreed on in 25 minutes are too large or too ambiguous for the sprint.
Service Runbooks
Every service has a runbook: what does this service do, who owns it, how do you deploy it, how do you roll it back, what are the dependencies, where are the dashboards, what are the known failure modes. Engineers should never have to ask another engineer how to operate a service. The absence of a runbook is a communication failure waiting to generate rework.
Async-First Communication Norms
Decisions go in Linear or Jira, not in Slack. Slack is for ephemeral, low-stakes communication. Any decision made in Slack gets a ticket within 24 hours. Meeting agendas are written and shared 24 hours in advance. Meeting notes with decisions are published within 4 hours. These norms create a searchable, auditable record of decisions that prevents re-litigation rework.
Shared Glossaries
Teams using different terms for the same concept -- 'account' vs. 'organisation' vs. 'workspace', 'user' vs. 'member' vs. 'customer' -- generate systematic miscommunication rework. A shared glossary in Notion or Confluence, linked from every service runbook, enforces a common vocabulary. Product, engineering, and QA use the same terms.
Sources
- Conway, M. How Do Committees Invent? Datamation, April 1968.
- GitLab. Remote Work Report. GitLab Inc., 2024.
- Atlassian. State of Teams 2024. Atlassian Corp., 2024.
- Nygard, M. Architecture Decision Records. thinkrelevance.com, 2011.
- Bass, L., Clements, P., Kazman, R. Software Architecture in Practice. 4th ed. Addison-Wesley, 2021.