Picture this: A customer calls support with a problem. They explain it to a support rep, who logs a ticket. The ticket goes to a product manager, who adds it to the backlog. Months later, a business analyst writes requirements. A tech lead creates tasks. Finally, a developer—who has never spoken to the customer—writes the code.
By the time the solution ships, the customer's original problem has been translated, summarized, prioritized, specified, and decomposed so many times that the original intent is barely recognizable. Like the children's game of telephone, each handoff introduces distortion.
This is the broken telephone problem. And it's not just an inconvenience—it's the root cause of why so many software projects fail to deliver real value, despite technically meeting their specifications.
The Layers of Translation
In traditional software organizations, information passes through multiple layers before reaching developers:
- Customer to Support: The customer describes their problem in their own words, often focusing on symptoms rather than root causes.
- Support to Product: The support rep summarizes the issue, potentially losing context about why it matters to the customer.
- Product to Business Analysis: The PM prioritizes and frames the issue in terms of business value, translating customer language into product language.
- Business Analysis to Development: The BA writes requirements, translating product language into technical specifications.
- Tech Lead to Developer: The tech lead breaks down the work, often making architectural decisions that constrain the solution.
Each translation is well-intentioned. Each person is trying to do their job. But the cumulative effect is devastating.
"The greatest waste in software development is building the wrong thing."
The Cost of Distance
Studies consistently show that the further developers are from customers, the more likely they are to build features that miss the mark. A 2024 McKinsey report found that organizations with "customer-connected developers" shipped 40% fewer features that required significant rework.
But beyond the statistics, there's a human cost. Developers want to solve real problems. They want to see their work make a difference. When they're isolated from customers by layers of intermediaries, they lose the connection to meaning that makes great software possible.
This is just the beginning. The full chapter continues to explore the psychology of information loss, real-world examples from companies like Atlassian and Linear, and the first hints of a solution...