The method
One position, three families of pattern, and a rule that every single one has to pass before it ships.
The position
Nothing gets built in open conditions. There is always a policy, an approval chain, a system chosen before you arrived, a budget cycle, a team already at capacity. Those are not the exceptions to the work — they are the shape of it.
Almost all professional advice is written as though they aren’t there. It assumes you can pick the tool, change the process, get the sign-off, start clean. Read from inside a real institution it is not merely unhelpful; it quietly implies that the reason it didn’t work is you.
The constraint is the design input, not the obstacle.
This is not consolation. A workflow designed around a real limitation is more durable than one designed without it, because the limitation was always going to arrive and the unconstrained version never planned for it. Working from what you cannot do also forces a question the open version never asks — what was actually essential here? — and the answer is usually smaller and far more portable than assumed.
Why AI, for now
Most of what is published here at the moment is about AI. That is a choice about timing, not a definition of the subject.
AI is where the constraints are newest, where the advice is worst, and where the distance between what people are told to do and what they are permitted to do is widest. It is a very good stress test for the method, because the gap is so visible.
But the three families below are older than any of it. They apply to process design, documentation, handovers, approvals and decisions with no software involved at all. Read them that way — the tool is the example, not the point. Lead with the pattern and name the tool second, if at all, because tools change every six months and the pattern doesn’t.
Family one — connective knowledge
The strongest material, and the least covered anywhere else. None of it is about software. Senior work is not task work. It is knowing that a change here lands on that system two steps out, so this other thing has to move first.
- Externalise the edges, not the nodes. You have been trying to give AI everything you know, which is infinite. Your value is the connections, and those fit on a page.
- It reads as either obvious or paranoid. On paper, institutional knowledge looks trivial or unhinged. The context that made it judgment is the part that won’t transfer — which is why documentation projects fail with real effort behind them.
- Your head is the safest and least backed-up place for it. Both are true at once, and the tension is the whole problem.
- The org chart is not the decision map. Knowing who actually decides is most of senior effectiveness and the hardest thing to hand to anyone.
- Nobody senior writes it down — not because it is hard, but because the undocumented version is what makes them indispensable. Document to be portable, not to be replaceable.
Family two — constraint workarounds
How anything actually ships in a place with rules. Practical, universal, and almost always available once you stop waiting for the version that requires permission.
- The export hatch. When live integration is blocked, static export usually isn’t. An unglamorous manual step defeats the integration problem most of the time, and people wait quarters instead.
- Low elegance, high reliability, zero approval. The workaround that survives is never the sophisticated one. Elegance needs sign-off, and sign-off is the scarce resource — not cleverness.
- Read access and write access are different fights. Read-only is a real architecture, not a degraded one. Design for it from the start and you ship something.
- Your environment has a quirk nobody else’s has. Stop hunting for the tutorial that assumes your defaults. Build the adapter once.
- Manual is a feature when it is the audit boundary. The step everyone wants to automate away is often what makes the workflow defensible. Automate up to it, never through it.
Family three — judgment
The decisions that come before any tool is chosen, and that survive it being replaced.
- Derived identifiability is the real line. Everyone redacts the obvious field. Almost nobody checks whether the protected value can be reconstructed from what is left. If three harmless fields let someone deduce the sensitive one, nothing was redacted.
- Sensitivity is not uniform. Treating every input as maximally sensitive produces paralysis or quiet corner-cutting. A three-tier scheme decided in advance beats adjudicating under time pressure.
- Right goal, wrong tool. Most failed initiatives had a sound objective and a mismatch between the problem type and the data type. Interrogate the shape of the problem before selecting anything.
- The work that lasts never touches the protected record. Drafting, research, documentation, analysis. That is not the consolation prize; it is most of the value.
- Move up the abstraction ladder, not along it. The useful move is rarely doing your job faster; it is changing the altitude of the artefact — procedure into playbook, or back down again.
The rule every pattern has to pass
Before anything ships, it has to be equally true for a hospital administrator, a compliance officer at an insurer, a legal ops manager and a school district director — all at once.
If it only makes sense in one sector, it is not a pattern. It is an anecdote wearing a disguise, and it will be less useful to you and more identifying to whoever told it.
This is why you will not find war stories here. Not coyness — the test genuinely removes them, and what survives the test is the part that transfers.
Start here
The Dependency Map is family one, made operational. A 20-minute interview that draws the structure out of you through questions. It never asks you to paste anything confidential, because anything that did would be useless to the people this is for.