How to Turn Your Judgement Into Systems Other People Can Use
You are the person everyone asks. The email that starts "quick question" always lands on your desk, and it is never quick. A junior colleague wants to know whether a clause is risky enough to escalate. A coordinator wants to know whether a delay on one project should trigger a conversation about three others. Someone new to the team wants to know if this is one of the cases where the usual rule does not apply. Each question takes you two minutes. There are a great many two-minute questions in a working week.
The natural response to being needed this much is to treat it as proof of value, and for a while it is. But at some point the maths stops working in your favour. Your judgement is in demand precisely because it is good, and because it is good, more of it gets requested than you can personally supply. The bottleneck is not a sign that you have failed. It is a sign that your expertise has outgrown the format it currently lives in, which is you, answering questions one at a time.
Most people who reach this point assume there are only two options. Either they keep answering the questions personally, which caps how far their contribution can reach, or they try to write it all down as rules, which usually produces a document nobody trusts because real situations rarely fit clean categories. The second option feels like a betrayal of the judgement itself. Reducing years of contextual pattern recognition into a flowchart seems to strip out exactly the thing that made the judgement worth having.
That framing sets up a false choice. Codifying expert judgement does not mean pretending every decision has a mechanical answer. It means separating the part of your thinking that recurs from the part that genuinely depends on context, and giving the recurring part a form other people can use without you in the room.
What actually gets encoded
The distinction that matters is between a template that specifies where information goes and one that specifies how to evaluate a situation. The first kind is just formatting. The second kind carries your decision logic, and it is the one worth building.
A legal coordinator facing this problem had built her reputation on reviewing every non-standard contract clause for risk. When contract volume rose sharply during an acquisition, reviews began queuing for the better part of a week and deal velocity suffered. Rather than working faster, she mapped the actual variables behind her own assessments: how enforceable a clause was likely to be given jurisdiction and contract type, how much financial exposure it created if invoked, and how sensitive the relationship with the counterparty was. Combinations of those variables told her whether a clause needed negotiation, needed documenting but could proceed, or needed no action at all. Once two colleagues had worked through a handful of examples with her, they could sort the routine cases themselves and send her only the ones that genuinely required her eye. Review volume dropped by more than half, and the contracts that still reached her were the ones where her judgement actually mattered.
That is a template built at the level of a single decision. Playbooks do the same thing at the level of a whole process, which matters more when the work involves sequencing rather than a single judgement call. A programme coordinator who had spent years resolving dependency conflicts between teams wrote down not just what to do but the reasoning she used to decide it: which conflicts could wait, which needed immediate escalation, and why. She tested it against real cases her colleagues had already hit, refined the parts that confused them, and kept going until their judgement matched hers on the great majority of cases. When a sixteen-team initiative later hit weekly dependency conflicts, the playbook handled what would previously have needed her involvement in every one of them.
The third layer sits above both: domain guidance for situations where the pattern itself is hard to name. A compliance officer knew, in a way that was difficult to write down, how enforcement priorities shifted, which violations actually drew regulatory attention and which were technically real but practically ignored. Junior analysts using the technical rules alone kept flagging the wrong things. She documented the context explicitly, using three years of enforcement data to show what regulators actually pursued and what mitigations reduced real risk even when compliance was imperfect. Once two analysts had trained on it, their assessments matched hers in the vast majority of cases, and when she took a month of leave, risk assessment continued without a gap.
None of these three professionals proceduralised everything. Each kept a category of cases that stayed with them: novel terms, high-stakes contracts, situations the guidance did not anticipate. That reserved category is not a weakness in the system. It is what keeps the system honest, and it is usually what tells you the encoding has been done well rather than carelessly.
Building the capability, not just the document
A document alone rarely transfers judgement reliably. The organisations that manage this well pair the asset with a structured handover, moving people through three stages of independence rather than expecting the written guidance to do all the work.
- Observation with narration. The person learning watches the real workflow while you explain your reasoning at each decision point, without executing anything themselves yet.
- Supervised execution with detailed feedback. They run the process under review, and the feedback addresses judgement quality, not just accuracy, explaining why a change improves alignment with your standard rather than simply flagging that something was wrong.
- Independent execution with periodic spot checks. They operate without pre-approval, and you check in occasionally to confirm the standard is holding rather than drifting.
Moving someone to the third stage before their judgement has actually calibrated is the most common way this goes wrong. It produces work that is technically accurate but subtly worse, missing the contextual clarity that made your version useful, and stakeholders notice before you do. The fix, when that happens, is not to abandon the approach but to extend supervision until judgement genuinely aligns, then release the boundary again as capability catches up with it.
The practical starting point is narrower than it sounds. Pick one judgement you make repeatedly, the kind that generates a steady trickle of "quick questions." Write down the criteria you are actually weighing, the thresholds that change your answer, the exceptions you always make, and two or three real examples that show how the logic applies. Test it on one colleague before assuming it is finished. What they get wrong will tell you more about what was actually in your head than the document itself did.
Do this well and the questions do not stop coming, but fewer of them need you specifically. Your standard starts showing up in decisions you were never consulted on, made by people applying logic you gave them a form for. That is a different kind of presence than being personally needed, and it is the one that survives your being away, promoted, or simply busy with something else.
David Taylor
Interested in going further?
The AI-Ready Career develops this shift in full, showing how encoded judgement and trained capability become the architecture that protects a role during restructuring rather than just a way of freeing up your afternoon.
Ad · Amazon affiliate link.
