The Speed of Understanding
Photo from the “Build a Duck” activity where everyone is given the same 6 LEGO® bricks and asked to build a duck. An illustration of how we all think differently, even when faced with the same simple challenge.
The Discovery Gap
AI and automation are shifting the economics of software development. Generating code, tests, and documentation is significantly faster, which makes our collective thinking more urgent. The challenge we face today is building shared understanding quickly enough to deliver the right thing with confidence.
When we increase delivery speed without a corresponding increase in understanding, we risk moving very fast in the wrong direction. We might be highly optimised for delivery mechanics, but if our assumptions are left underexplored, we are essentially automating the creation of waste.
Losing the Plot
Part of the problem lies in where we choose to keep our information. Most teams rely heavily on tracking tools like Jira to capture their requirements. While these tools move tickets through a workflow, they were never designed to be knowledge bases.
When we treat a tracking tool as our primary source of truth, valuable context becomes scattered and fragmented. Strategic intent evaporates into ticket comments and Slack threads, leaving the real reason behind a feature nearly impossible to follow. This leads to a graveyard of untended ideas: a monolithic backlog that the team no longer believes in.
The Persistence of Handovers
We also face a structural challenge. Most practitioners know that handovers are bad; we have seen how they distort information like a "telephone game". Yet, even in teams that appear agile, these handovers are remarkably difficult to eradicate.
Often, this is because we haven't found a better way to connect our disciplines. We see "Water-Scrum-Fall" patterns where analysis still happens in a silo, and testers are left waiting at the tail end of an iteration. Without a clear structure for how and when to collaborate, we default back to sequential work, even when we have the best intentions of working together.
Making Thinking Visible
To break these patterns, we need to make our internal thinking visible to the rest of the team. I often use a simple "How many squares?" exercise to illustrate this point: a grid of interlocking squares where people see wildly different numbers.
“How Many Squares” shows how we interpret things differently and how easily we come to a shared understanding when we make our thinking visible.
The moment someone makes their thinking explicit (perhaps by tracing the larger squares with their finger or drawing around the ones they see) the whole room agrees in seconds. It is the act of externalising the intent that makes these different interpretations apparent. Without that, everyone sits in the room nodding and assuming they are seeing the same thing while actually picturing something completely different.
The same thing happens with LEGO® bricks. If you give thirty people the same six bricks and ask them to build a duck, you will get thirty different ducks. Complexity and different perspectives exist even in the simplest tasks. In software, if we don't make our thinking tangible early on, those different perspectives only surface much later, when they are significantly more difficult to resolve.
Concrete Examples
Shared understanding is most effective when it is grounded in reality rather than abstraction. Real progress happens when we bring ideas back to something specific and explore how they play out in practice.
Involving a cross-functional team in these detailed conversations early can feel expensive, but misunderstanding costs much more. Someone has to do the thinking and deal with the complexity eventually. If we avoid that thinking now, we simply defer it until implementation or testing, where we risk being burnt by the details we didn't spot.
By using concrete examples with specific data early on, we "hunt the dragons": the hidden business rules and technical gaps that abstract requirements always miss. This approach allows us to use these examples as both the specification and the test, bringing the verification forward to the start of development. These examples become a universal bridge between business and technical roles, ensuring that everyone is working from the same understanding.
Scaling Understanding
Finally, shared understanding is a vital risk-management strategy, particularly as an organisation grows. In an OOPSI case study from the book, the fintech FundApps discovered this during their journey from a small startup to a global scale-up. They hit a hard truth: you can no longer rely on everyone knowing everything as a domain becomes more complex.
In high-stakes domains like financial regulatory compliance, a misunderstanding is not just a bug; it is a potential for severe penalties and reputational damage. Shared context is what allows an autonomous team to make good decisions when the stakes are high.
Shared understanding is the continuous thread that runs through every stage of delivery, from the broad business outcomes and tangible system outputs, through to the processes, the scenarios and the concrete data inputs. As AI continues to accelerate implementation, our ability to build shared understanding becomes even more important. The challenge is no longer simply delivering software faster, but building enough understanding to ensure we're delivering the right thing in the first place.
Curious About OOPSI?
This article explores one of the ideas that sits at the heart of OOPSI, a collaboration framework that helps cross-functional teams build shared understanding, cut through complexity and deliver value with confidence.
