Why Borrowed Leader Standard Work Stops Producing
A management routine copied from another organization can work. What does not copy is the judgment that made it worth doing there — and when that judgment is missing, the routine still runs. It runs cleanly. It produces nothing anyone can name.
Can you use another organization's leader standard work?
Yes. Routines transfer. What comes with them is a bill for translation, and the size of that bill depends on how close the source operation is to yours.
Fitness sits on a gradient rather than a switch. Two things put a borrowed routine high on it. Breadth — the routine was written generically, for a class of operations rather than one. Or similarity — it came from an operation genuinely like yours. The common bad case is the opposite of both: a highly specific routine lifted from an operation that does not resemble the one adopting it.
Almost nobody assumes copying is free. Plenty assume it is a ninety percent discount — take the method, add some training and a few documents, done. Sometimes that is exactly right. Enough factors vary between operations that a genuine ten-percent-to-fit is entirely conceivable, and treating every borrowed routine as suspect wastes a legitimate shortcut.
The problem is not the discount. It is that the discount gets guessed at rather than estimated. Converting the guess into an estimate takes somebody who understands how the business would actually use the routine and what matters to it — subject-matter depth or a high enough vantage point. Without that person you are adopting a method you do not understand and could not validate, on the strength of a larger organization doing it that way. That is where the unknown unknowns live.
Two things never transfer at any level of fitness: what the routine prioritizes, and the mechanism by which it does anything. Both have to be aligned to the operation adopting them. High fitness reduces that work. It never removes it.
What gets missed when you adopt another organization's management routine?
Two bodies of work, and adopting a routine removes neither of them.
The first is design. Deciding what a leader should be looking at, in what priority, given this operation's risks, obligations, and strategy. The second is implementation — standing the routine up so that it is defined, trained, communicated, and standardized in how people actually work. Both are ordinary system-building work — the same work that goes into any structure that organizes how work gets done — and neither of them arrives inside a borrowed template.
That produces four states worth telling apart. Design absent. Design present but unsupported. Implementation absent. Implementation present but unsupported. A routine can be well designed and well implemented and still degrade, which is why the last two matter as much as the first two.
The translation cost is paid in one of two places. Up front, in considered design and assessment that shapes the implementation and keeps it delivering. Or on the back end, in running a routine that is ineffective to some degree — ten percent of the work delivering nothing, or ninety percent of it. The back-end payment comes out in wasted time, wasted attention, and tooling aimed at the wrong target.
Why do management routines stop working after they are installed?
Because unsupported means unresourced. A routine that degrades is usually not a discipline problem. It is a resourcing decision nobody made.
The resources a routine consumes are time, competence, documentation, and tooling. All four scale with the complexity of what the routine is doing. Borrowing from a larger or more complex operation imports a resource bill that was never costed, because the source organization was already paying it and the artifact does not show the invoice. Organizations carrying several sets of obligations at once often handle this by consolidating the load into one governance structure rather than resourcing each routine separately — which is the bill being paid deliberately instead of by attrition.
This is why degradation is so often misread. The routine was fine at install and is thin six months later, so it looks like people stopped caring. More often the routine was always going to need an hour a week of somebody's attention that nobody allocated, and it decayed to the level the available resources could sustain.
How can you tell if a management routine is producing anything?
Ask to see the decisions and the changes that resulted from it. That single question does most of the diagnostic work.
It is asked in ordinary conversation rather than in an audit — the answer is more honest when nothing is riding on it. And the changes do not have to sit at the manager's own level. If the output of a routine rolls up into planning or strategy, that counts as producing something.
The tell that a routine is not producing is volume offered as proof. Look how much information we are passing back and forth. Reports move, meetings happen, and nobody has asked whether the activity was supposed to generate a result or whether it aligns with the organization's objectives. That question is the validation of the standard work, and a borrowed routine makes it easy to skip, because an artifact that arrives looking finished looks like somebody already answered it.
Routines in this state are not sloppy. They run consistently and they hit exactly what they aim at. They are precise and inaccurate.
When the answer to the question is thin, a follow-up sorts it into one of two findings.
Finding one: a legitimate reason exists, and the manager does not have it
This is a communication failure, not a design failure. The task still gets done — but done with less care, and with corners cut where the person cannot see what the care was protecting. An activity performed without its reason is a weaker version of itself, and the completion record shows none of that. The record confirms the activity happened. It says nothing about whether the person doing it understood why.
The fix is communication. Removing the item would be the wrong response to this finding.
Finding two: there is no legitimate reason
Then the question becomes what the activity is actually for. Usually the answer is compliance-shaped — it exists because something required it, and it has been decorative ever since.
Compliance is a poor defense here. Requirements of this kind exist to instill common risk controls and process frameworks that are meant to be adapted to context so they produce something tangible. A requirement is a floor. Treating it as a ceiling is the error, and it is the organization's error rather than the requirement's.
One honest exception. Some items are genuinely administrative — regulatory submission paperwork, filings, the rules of the game. They do not need to inform a decision and it is not a failure when they do not. The error is letting that category expand to cover things that should have been producing something.
What happens when leadership mandates an activity without defining how to do it?
You get the appearance of the activity, none of its output, and a loss of confidence that outlasts both.
The pattern looks like this. Senior leadership mandates a recurring risk assessment. The requirement is handed down with a due date and a template, and without a process, criteria, scope, or objectives — often to a team with no competence in running one, which is the part that goes unnoticed because the team does not know what it does not know. A risk assessment has a defined method behind it, and the method is precisely what did not come down with the mandate.
The meeting itself is mostly quiet. One or two people talk in circles because somebody has to fill the silence. Everyone is searching for something in a dark room and nobody was handed a light. The hour ends, the form is filled in, and nothing decidable has been decided.
The wasted hour is not the real cost. The cost is confidence. The team reads the request as unserious, concludes that leadership had not thought it through, and brings that conclusion to whatever gets mandated next. That is expensive in a way no one records.
This is the first finding at scale, with a different piece missing. There the manager lacked the reason. Here the team lacks the method — scope, criteria, competence, a defensible way to proceed. A mandate without means is not delegation, and accountability does not travel downward with the task. The activity can be assigned. Responsibility for whether it was possible stays where it started.
Should every part of a management routine feel the same?
No. A functioning routine runs in two modes, and which mode an item belongs to is a fixed property of that item rather than a stage it passes through.
Low-attention items are built in and unremarkable. They should become nearly invisible with repetition, and they should survive a bad quarter without anyone defending them. The daily check that has stopped feeling like an event is working correctly.
High-attention items are the assessments and evaluations. They carry genuine cognitive load, they require planning, and they are supposed to stay expensive. This is the part that gets designed out by accident, because effort reads as friction. An assessment that became easy is a rubber stamp, and the moment it stops costing anything it has stopped finding anything.
The design consequence is that every item should be classified before the routine goes live. Misclassification fails in both directions. A high-attention item treated as routine turns into a signature with no finding behind it. A low-attention item loaded with high-attention weight gets complied with for about six weeks and then quietly stops.
The mandated risk assessment is exactly this error. A high-attention item issued as though it were a low-attention one — due date, template, no method.
How do you fix a management routine that is not working?
Item by item. Do not rebuild it and do not scrap it.
Take each item and evaluate it from both angles at once: what it traces to, and what it has produced. Neither question alone is sufficient, and asking them in sequence lets an item pass on the strength of a good-sounding rationale that never generated anything.
Three outcomes come out of that.
It delivers value. It stays as it is.
It is legitimate but the manager did not know why. The fix is communication. Do not remove it.
It traces to nothing. Cut it.
The reason to work at item level rather than starting over is that the existing routine is evidence. It is a record of what this operation will actually sustain, which is information you do not have about a routine you have not run yet. Most routines are a mix rather than a write-off, and working item by item keeps the repair proportionate to the damage. It is the same logic as examining a system against how it actually operates instead of rebuilding it from a description of how it should.
One thing to check on the way out: the items that survived should have their mode confirmed. An item that delivers value today but was classified wrong will fail later, and it will look like a new problem.
The signal worth watching
A manager operating on a routine that works is ahead of the work rather than behind it — literally, in the sense of encountering what is coming before it lands rather than reacting after it has.
That state has a shape. Focused and prioritized. Urgent and important handled. And important-but-not-urgent reasonably managed rather than perpetually deferred, which is the part worth watching, because it is the only category nothing else in an operation protects. It survives when a routine is protecting it and not otherwise.
Treat that as a starting observation rather than proof. It is describable as it stands, and testable if it is made comprehensive enough. But a manager who feels ahead of the work and cannot name a decision the routine produced has an impression. A manager with both has evidence.
The diagnostic is cheap to run. Take the three items your managers perform most often, and for each one ask what it traces to and what it produced in the last quarter. If most of them come back empty, the routine was never derived for this operation — which makes it a design problem rather than a discipline problem, and a different piece of work than tightening up compliance with what is already there.
Frequently asked questions
Can leader standard work be copied from another company?
Yes, and it often should be — reinventing a workable routine is waste. What does not copy is the derivation: the reasoning about what this operation should be looking at and in what priority. Copying works when somebody who understands the business validates the borrowed routine against it before it goes live.
What is the difference between a routine that is badly designed and one that is unsupported?
A badly designed routine points at the wrong things. An unsupported routine points at the right things and is not given the time, competence, documentation, or tooling to do it. They look identical after six months — both produce thin output — but the repairs are unrelated, so the distinction is worth making before acting.
Does every item in a management routine need to produce a decision?
No. Some items are genuinely administrative — filings and submissions that exist because the rules require them and are not supposed to inform anything. The failure mode is letting that category expand until it covers items that were meant to produce something and quietly stopped.
How do you know when to remove an item rather than fix it?
Ask what it traces to and what it has produced. If it traces to nothing, remove it. If it traces to something real and the person performing it did not know that, the problem is communication and removing the item would be the wrong repair.
