_001 Fidelity of Comprehension
I wanted to talk about the idea of fidelity — or resolution — in how we think and communicate. When we see something far off in the distance, it appears abstract and blurry. As we get closer, the details sharpen; we understand more. The same principle applies to ideas, projects, and systems. The closer we examine them, the more fidelity we gain — and the more information we have to work with.
Throughout my career, I’ve seen a recurring pattern: businesses delegating thinking to engineers by throwing low-resolution requests over the engineering fence wrapped up as “technical challenges”, when in reality, they are logically incomplete.
In all complex software systems, even the smallest change can create contradictions or paradoxes downstream. A tiny shift at the top of the stream can break something fundamental further down. So the first lesson is appreciating the potential impact of seemingly minor changes.
The second lesson is about the handshake between minds.
Imagine a product owner with a new feature in mind. To them, it’s obvious and simple. To the engineer, it’s a riddle full of hidden traps and contradictions. The product owner says, “I need it by the end of the month.” The engineer, wanting to be helpful, asks a few questions, shrugs, and agrees. But as the resolution increases — as fidelity rises — issues emerge.
This is where so many projects go off track.
Waterfall vs Agile: A False Dichotomy
People love to argue about Waterfall versus Agile. But they’re not fundamentally different processes — they’re just different levels of resolution.
Waterfall says, “I can see the sequence clearly enough to plan it end-to-end.”
Agile says, “I can’t see far enough ahead yet — I’ll need to explore, iterate, and adjust.”
Both are causal and sequential. And if we actually re-read the Agile Manifesto, we’ll see that nothing in it contradicts the so-called “Waterfall” methodology. What we’ve seen instead is the rise of a cottage industry of Agile evangelism — overcomplicating a set of clear principles into bureaucracy and credentialism for their own sake (and of course, fees).
So instead of arguing Waterfall vs Agile, maybe we should think in terms of scale, resolution, and fidelity.
Practical Fidelity
When someone says, “I want this new feature,” the right question isn’t “Waterfall or Agile?”
It’s:
What’s the fidelity of your comprehension?
How clearly do you see it?
Do you understand the implications of it?
All we’re really doing is refining comprehension — improving fidelity.
For me, a key principle is establishing external checkpoints between handshakes. In other words: document comprehension as it passes from one mind to another. From product manager → to scrum master → to lead engineer → to developer.
That documentation doesn’t have to be long — only as detailed as it needs to be to clearly convey understanding.
The Fidelity Gut Check
If your team is obsessing over velocity, architecture diagrams, or the latest feedback from a design governance forum — stop.
Find the lead responsible. Check their comprehension.
Do they actually understand what’s being asked?
If not — who does?
Every time you hit confusion, write it down. Because if your senior people can’t clearly document either what the thing is supposed to do, or how it’s supposed to be implemented, then it has no chance of being successfully delivered.
Your gut check is always fidelity:
How deeply does the person explaining it understand the issue?
Do the next people in the chain have a single, concise document to reference?
Coming back to the Agile Manifesto: people over processes.
If you can’t get comprehension right at the level of one — one unit, one person, one handshake — then no amount of process will save you.