Here's a pattern you'll recognise. Two smart people in a meeting, each certain about how something works — the legacy system, the customer, the other team's roadmap. The argument goes in circles because neither of them actually knows. They're both reasoning from a model in their head, and the models disagree. Half an hour of confident debate, and the thing they're arguing about is sitting right there, knowable, one conversation away.
The manifesto's answer is blunt: go find out. Engage early, and enough — even if only to make friends. Get out of the chair.
Assumption is cheaper than a conversation, and costs more
We default to assuming because assuming is fast and free in the moment. Walking over to the support team, reading the actual logs, ringing the customer, opening the file — all of that has a small upfront cost. So we skip it, and we pay later, when the assumption turns out wrong and the work built on it has to be unwound.
It's the cheap-wrong principle again, applied to knowledge. A two-minute "go find out" turns an expensive, deferred error into a cheap, immediate fact. The asymmetry is enormous and we ignore it constantly.
Engage. Engage early, and enough — even if to make friends. Get out of the chair and go find out.
Make friends before you need them
The "even if to make friends" clause is the part people skip, and it's the most strategic. The time to build a relationship with the team that owns the database, the ops person who knows where the bodies are buried, the stakeholder who can quietly kill your project — is before you need anything from them.
Engagement isn't only about extracting facts. It's about being a known, trusted quantity when the awkward moment arrives. The person who's shown up, asked good questions, and listened gets a very different answer at 5pm on a Friday than the stranger who appears only when they're blocked.
Primary sources
There's a quiet snobbery worth borrowing from historians: prefer primary sources. Don't ask someone what the customer thinks — talk to the customer. Don't infer what the system does from the documentation — read the code, watch the trace. Every hop away from the source is a chance for the signal to degrade into someone else's interpretation.
This is uncomfortable because primary sources are messier than summaries. The customer says something contradictory. The logs don't match the diagram. The code does something nobody remembers writing. Good. That mess is the truth, and the truth is what you came for.
The smallest expedition
You don't need a research programme. You need to get out of the chair. Send the message. Open the file. Ask the dumb question — the dumb question is almost always the one everyone else was also afraid to ask. The smallest expedition into reality beats the largest debate about it.
When a project stalls on a disagreement, the question is rarely "who's right?" It's "what haven't we actually checked?" Go find out. Then come back and have a much shorter meeting.
