One lesson we've learned from every engagement we've had: no single person has the map of an organization. Everyone holds a piece — their piece — and the whole exists nowhere. Not on paper, not in a wiki, not in anyone's head. The organization runs anyway, the way a city runs without anyone knowing every street. However, we believe that you cannot redesign what you cannot see.
This is why we refuse to write code first, even when the client knows exactly what they want built. Especially then! The request that opens an engagement — "automate this report," "connect these two systems" — is almost never wrong, but it's almost always downstream. It names a symptom at the point where someone finally felt it, but overlooks the root cause. At Tributary, we focus on streamlining organizational intelligence, which requires a more nuanced approach.
So we map with a three-layer process.
Infrastructure — what you run. Every system, subscription, spreadsheet, and shared drive. Not the official list; the real one, including the tools one person adopted three years ago that a critical process now depends on.
Information flows — how data actually moves. Where it enters, who touches it, where it's retyped from one system into another, where it forks into two copies that slowly disagree, where it dies. This layer is where the map stops being a diagram and starts being a diagnosis. Every manual re-entry is a tax. Every fork is a future argument about whose number is right.
Operating protocol — what people do, as opposed to what the process document says they do. Approvals, workarounds, workflows, and process beyond the docs. The judgment call one person makes so routinely that no one has noticed it's the actual decision point of the business.
Getting that third layer honest is why we embed instead of interviewing. Ask people to describe their process and you get the org chart's version — polished, sequential, and fictional. Sit in the meetings for two weeks and you get the truth: work moves through favors, Slack threads, and individuals. Automation built from the fiction fails in production; automation built from the truth ships.
There's a temptation, once the map exists, to automate everything it shows. Resist it. A mapped process is not yet a good process, and automating a bad one just makes the dysfunction faster; you pour concrete over the wrong road. The map's first use is subtraction: steps that exist because a tool demanded them, reports no one reads, approvals that approve nothing. Some of our most valuable recommendations have been things to stop doing. No software required.
Only then do we build — and the building goes fast, precisely because the map exists. Scope disputes disappear when both sides are pointing at the same drawing. Integration surprises disappear when every system was inventoried before the first line of code. The map converts "we think" into "we know," and software built on "we know" ships on time.
One more thing, and it's the reason the map is a deliverable rather than an internal artifact: it's yours. Whatever happens after — whether we build together for years or you take the map and walk — you'll hold something most organizations never have. Your whole operation, on one page, true.
Most organizations have never seen themselves. It changes how you run, before anything gets built at all.