Most organizations don’t ask this question until it’s too late, and when they finally do, they ask it the wrong way. They treat succession as an HR event — a resignation, a search, an announcement, a handover memo. That’s the paperwork of leadership change. It is not the substance of it.

The substance is this: did the leader build a system that survives them, or did they build something that was, in practice, just them? Culture and operational discipline don’t transfer on an announcement date. They transfer — or fail to transfer — through hundreds of small, repeated behaviors that were either written down and taught or lived entirely inside one person’s head and disappeared the day that person walked out the door.

This is a design problem, not an HR problem. And it deserves to be treated like one.

The Test That Reveals Whether You Have a Legacy or a Dependency

Here’s a question worth sitting with, uncomfortable as it is: if you disappeared tomorrow, could someone else run your Monday morning review exactly the way you run it? Would they know how to land the tension between “hit the number” and “do it the right way” where you’d land it? Would they be able to spot, six months from now, that a decision quietly violated a standard nobody ever bothered to write down?

If the honest answer is no, you don’t currently have a leadership legacy. You have a dependency — a set of outcomes that only happen because you, specifically, are in the building. That’s not a moral failing. It’s the default state of leadership because judgment is hard to write down and easy to... do. But it means that everything good about how your team operates has an expiration date, and that date is your last day.

Designing for succession means treating your own leadership behaviors as a system to document, teach, and pressure-test — not as a personality to be admired or a mystique to be preserved. For many senior leaders, that’s a genuine mindset shift. It can feel like you’re arguing yourself into being replaceable. You are. That’s the job. The alternative is to build something that only exists while you’re standing in the room.

Two Transitions, Same Starting Point, Opposite Outcomes

Consider two composite examples — patterns that show up, in one form or another, across most industries and org charts.

The break. A plant leader spends eight years building a culture of relentless root-cause problem solving. Every shift, every issue, he’s asking “why” five times before anyone is allowed to move on. It becomes the plant’s identity. Defect rates fall steadily. People are visibly proud of the standard.

He gets promoted — a well-earned outcome, and exactly the kind of thing that’s supposed to happen. His replacement is smart, capable, and well-liked by the team. But nobody ever documented how the root-cause habit actually worked in practice: the specific questions to ask, the cadence it ran on, the visual boards that tracked it, the follow-up rhythm that made it stick. It lived in his head and in his physical presence on the floor. Within four months, the daily habit has quietly slipped to a weekly one. Within a year, it’s a line item on a report nobody reads closely. Eighteen months later, defect rates are back where they started before any of this began.

Nothing dramatic happened here. No single bad decision, no scandal, no obvious failure point you could point to in a post-mortem. The discipline evaporated, one skipped rhythm at a time, because it was never anything other than one person’s habit. This is legacy drift, and it’s the default outcome of an undesigned transition — not the exception.

The hold. A different leader, facing the same kind of handoff, produces a completely different outcome. Before she moves on, she does three specific things. She writes down her leader standard work — literally, the checks she runs, when she runs them, and why, in enough detail that someone else could follow the same rhythm without her narrating it. She runs a formal transfer-of-accountability conversation with her successor — a structured conversation, not a logistics memo. And she sets up a governance check: a standing review, on a fixed cadence, where someone outside the direct reporting line assesses whether the old standards are still being run, for the first full year after the transition.

Her successor faces the same pressure to relax standards that the plant leader’s successor faced. The team is under the same kind of workload, the same short-term temptations to skip a step when things get busy. But the standard holds because it was never dependent on one person’s memory being successfully installed in someone else’s head. It was dependent on a system that three separate people could see, check, and be accountable to.

That’s the entire difference between hoping a legacy survives and designing for it to. There is no difference in the quality of the two leaders’ judgment. It’s a difference in whether that judgment was ever converted into something that could exist independently of them.

The Framework: Leader Standard Work

The mechanism that makes the second story possible has a name: leader standard work. It’s the practice of codifying the specific, repeatable habits that create your standard — so that standard can be taught, rather than absorbed by osmosis over years of working alongside you.

There are three components worth building deliberately, not just nodding along to.

Name the habits specifically, not as values. “I care about quality” transfers nothing to a successor — it’s a sentiment, not an instruction. “Every Tuesday, I walk the floor and ask three people what almost went wrong this week” is a behavior someone else can actually learn and repeat. Vague values don’t survive a transition. Specific, repeatable behaviors do, because they can be observed, copied, and eventually owned by someone else.

Make the habit visible, not personal. If the only evidence that a standard exists is that you, personally, showed up and performed it, the standard dies the moment you stop showing up. The fix is almost mundane: put it on a board, write it in a shared document, attach an actual agenda to the recurring calendar invite. The goal is for the habit to exist as an artifact independent of your physical presence — something a new leader can pick up and run, not something they have to reverse-engineer by watching you for two years.

Build in a check that isn’t you. Someone else needs to be able to look at the system and determine whether the standard is being upheld, without relying on your personal judgment to decide whether it counts. This is the step most transitions skip entirely, and it’s the one that turns a personal habit into an actual system. Without it, “leader standard work” is just a nicer name for “things I happen to do.”

The blunt version of this framework: if your leadership legacy currently lives entirely in your calendar and your instincts, it isn’t a legacy yet — it’s just your current job description. Leader standard work is the discipline of converting your judgment into something that outlives your presence in the building.

The Conversation Most Handoffs Skip

Most leadership transitions get a logistics conversation: passwords, org charts, a list of open items, and pending decisions. What they rarely get is an accountability conversation — a direct exchange about which judgments matter and why.

Here is a simple, four-question template worth running in any transition, whether you’re the leader stepping out or the one stepping in.

“What am I doing today that you’ll need to keep doing — even if you’d never have started it yourself?” This surfaces the habits that exist because of accumulated judgment rather than obvious necessity, the ones a new leader might otherwise quietly drop simply because they don’t yet understand why they matter.

“What decision, if you saw it come across your desk in six months, should make you stop and say ‘that’s not how we do things here’?” This is the closest thing to transferring institutional instinct in a single sentence — naming, in advance, the kind of decision that should trigger a gut check.

“Where have I been compensating for a broken process with personal effort — and what breaks if that effort disappears?” Every experienced leader is quietly patching some gap in the system through sheer will. Naming those gaps explicitly prevents a successor from being blindsided when the patch can no longer hold.

“Who, besides you, needs to know these standards exist — and who’s going to check that they’re still being followed a year from now?” This question builds the governance layer directly into the handoff, rather than leaving it as an afterthought.

Notice what this conversation is actually doing. It isn’t transferring information — an org chart or a password vault can do that. It’s transferring judgment: the specific, hard-won sense of what matters and what doesn’t, which normally evaporates the moment someone walks out the door for the last time. Have this conversation deliberately, write down the answers, and revisit them together at the ninety-day mark.

Governance Patterns That Prevent Legacy Drift

Even a well-documented standard and a thoughtful handoff conversation will decay under day-to-day pressure unless something outside the new leader’s judgment actively checks on it. That’s governance — and it doesn’t need to be heavy machinery. Three patterns are worth building into any serious succession plan.

A standards audit on a fixed calendar, not an “as needed” basis. Someone outside the direct reporting line reviews whether the documented leader standard work is actually being run — quarterly for the first year after a transition, then twice a year after that. The fixed cadence matters more than the specific frequency; people inside the system rarely notice drift in real time.

A named legacy sponsor — not the successor, not the predecessor, but a third party, often the successor’s own boss or a peer leader, whose specific responsibility is to ask, “Are the standards still holding?” at each review. Diffuse responsibility for noticing drift means that, in practice, nobody notices it until the outcomes have already changed.

A defined drift trigger — deciding in advance what an early warning actually looks like: a specific metric, a skipped rhythm, a rising pattern of exceptions to the standard. By the time the headline numbers move, the underlying drift has usually been happening quietly for months. Naming the leading indicator in advance allows anyone to catch it early, rather than after the fact.

None of this requires new bureaucracy or a heavier reporting structure. It requires one decision made before the transition happens: that someone other than the new leader is explicitly responsible for noticing when the standard quietly stops being the standard.

One Practice to Test in the Next 30 Days

All of the above can sound like a program — and it’s tempting to either commit to it all at once or shelve the whole idea as “something for next quarter’s planning cycle.” Resist both instincts. Start with exactly one practice.

Identify your single most important recurring leadership habit — the one thing that, if it stopped happening, would most hurt your team or your standards. This week, write it down in enough detail that someone with no prior context could actually run it without you standing beside them. Then hand it to one person and have them run it once, while you watch, without stepping in to correct or narrate.

If they can run it close to how you’d run it, you’ve found something on its way to becoming a real system — something that will likely survive your eventual departure. If they can’t — if it only works because it’s specifically you doing it — you’ve just identified the single biggest hole in your legacy plan, while you still have time to close it. Either outcome leaves you with information you don’t currently have.

The Only Question That Was Ever Going to Matter

Leadership transitions are inevitable. That part was never actually in question, for you or for anyone in a stewardship role. What is in question — what remains genuinely open right up until the day you leave — is whether what you built required you personally to keep showing up forever, or whether it was designed from the start to outlast you.

Don’t leave that answer to chance. Design it.

For 25 years, I’ve started my work with leadership teams by asking them a question. I usually ask it right at the beginning, even before we’ve settled in. In all that time, almost no one has answered it with confidence.

The question is this: What is your organization designed to produce?

Not what you want it to produce. Not what your strategy says it should produce. What is it actually, functionally, and structurally designed to produce right now, today, with the routines, systems, and behaviors you already have?

Most leaders pause. Some reach for their strategy document. A few give me the answer that’s on the wall in the reception area.

Almost nobody gives me an honest answer about the system.

And that gap, between the results leaders want and the results their system is built to deliver, is where most transformation programs fail.

The Seduction of the Program

I want to tell you about two organizations I’ve worked with. I won’t name them, but their stories will probably sound familiar, because I’ve seen these patterns many times.

The first organization launched what they called a “Lean Transformation Program.” Eighteen months, significant investment, external consultants (including us, at one point), a dedicated transformation office, and a steering committee that met monthly. They ran kaizen events. They did 5S. They mapped value streams and identified waste. At the end of 18 months, they had metrics showing meaningful improvement. The CEO presented them to the board with genuine pride.

Eighteen months later, most of the gains had faded. Not all of them—some tools remained, and some processes improved. But the core way the organization worked had gone back to old habits. The problems that were “solved” returned. Improvement efforts shifted to the CI team, who only ran events or wrote reports when asked. Line managers, who were briefly involved, went back to putting out fires. The transformation office was quietly closed.

The second organization didn’t launch a program. They redesigned the way they worked.

Suir Engineering, a mechanical and electrical contractor in Ireland, had only 25% plan attainment when we began working together. Three out of four planned jobs weren’t finished on time. This wasn’t just a problem with tools or processes. It was a system problem—a gap between what the organization was set up to deliver and what its leaders actually needed.

We didn’t deploy Lean. We redesigned the organization.

Leadership routines changed: how leaders spent their time, the questions they asked, and what they focused on. Management systems changed too: how work was planned, tracked, and reviewed. The link between strategy and daily activity became clear instead of assumed. Improvement became something the frontline owned, not just something managed by the CI team.

By 2018, plan attainment was at 85%. Revenue had grown from €80 million to €450 million. Operational efficiency was up 30%. Rework was down 50%. Zero safety incidents throughout.

The improvement didn’t end when the program finished. It kept growing because of the organization’s redesign.

That’s the difference I want to talk about today.

Continuous Improvement vs. a Self-Improving Organization

These two things sound similar. They are not.

Continuous improvement is something you do. It lives in a project plan, has a sponsor, a budget, and a team assigned to run it. It produces events, reports, metrics, and completion certificates. When the organization is under pressure, it gets deprioritized. When the sponsor moves on, momentum fades. When the consultants leave, it slows down. When the next strategic priority arrives, it gets absorbed or replaced.

None of this means continuous improvement is useless. The tools are often excellent, and the discipline can be valuable. But it’s fragile, because it sits on top of the organization instead of being built into it.

A self-improving organization is something you become. It doesn’t need a separate team or an outside trigger. It isn’t just a project. Improvement is simply part of how the organization works, because that’s what it was built to do.

The distinction matters enormously in practice. One produces results during the program. The other produces results permanently.

What a Self-Improving Organization Actually Looks Like

I’ve worked inside enough organizations now to know that self-improving ones share certain characteristics. These aren’t cultural values or aspiration statements. They’re observable, structural features.

Problems are visible, not managed.

In most organizations, problems are absorbed. A supervisor spots an issue and works around it. A team discovers a defect and fixes it quietly. A process breaks down, and someone improvises a solution. The problem gets managed — but it doesn’t surface. Leadership never sees it. It never gets properly resolved. It keeps happening.

In a self-improving organization, the system is built to reveal problems. Visual management isn’t just about keeping things tidy; it’s about making the system’s state clear so issues are easy to spot. Escalation isn’t seen as failure; it’s expected and valued. Problems are treated as useful information, not as something to hide.

This cultural shift is important. In most organizations, bringing up a problem can make you look bad. In a self-improving organization, hiding a problem is what makes you look bad.

Improvement capability lives with the work.

Most improvement programs make the same structural error: they put improvement capability in a specialist team. The CI team runs the events. The Lean experts do the analysis. The transformation office manages the program.

This is well-intentioned and completely backward.

The people who understand the work are the people who do it. The team leader who runs the line every day knows things about that line that no analyst ever will. The nurse who manages the ward knows where the system breaks down in ways that don’t appear in the data. The engineer who operates the equipment knows why it fails before any diagnostic catches it.

A self-improving organization puts improvement skills where the knowledge is: with the people doing the work. This means investing in frontline skills like problem-solving, standard work, and basic analysis. It also means giving people both the skills and the authority to improve their own work. In this setup, the CI team acts as coaches instead of just running activities.

Leadership behavior reinforces improvement daily.

This is the part most leaders underestimate. It’s not that they don’t understand it—most do—but it requires a real change in how leaders spend their time and what they focus on.

The organization always reflects how its leaders behave. If leaders spend their time in meetings reviewing output metrics, the organization focuses on those. If leaders spend time on the floor learning how work really happens, the organization starts to focus on understanding and improving the work itself.

Gemba, the idea that leaders should regularly spend time where value is created, isn’t just a management technique. It’s a signal about what matters. When a plant manager spends two hours a week walking the floor, asking questions, and listening instead of directing, the organization learns something important: the work matters, the people doing it matter, and improvement truly interests leadership.

Leaders who build self-improving organizations don’t manage improvement. They model it.

Strategy connects to daily work.

When the connection between the organization’s direction and daily work is clear, people focus on improving the right things. When it’s not clear, improvement becomes random—well-intentioned and energetic, sometimes impressive on its own, but not tied to what really matters.

Strategy deployment, which means turning organizational goals into meaningful targets and actions at every level, might sound administrative. But in practice, it’s one of the most powerful tools a leadership team has. When people understand not just what they’re supposed to do, but also why it matters and how it connects to the organization’s direction, improvement becomes purposeful rather than just reactive.

The organizations that sustain excellence aren’t the ones with the best tools, the most events, or the largest CI teams. They’re the ones where improvement is purposeful, visible, daily, and owned by the people doing the work.

The Question That Changes Everything

I said earlier that most transformation programs die in the gap between the results leaders want and the results their system is built to deliver.

The reason is almost always the same: leaders try to get better results from a system that isn’t designed to produce them.

They run better programs, bring in better consultants, set clearer targets, and apply more pressure. But the system, which is perfectly designed for its current results, absorbs all of this and keeps producing the same outcomes—maybe with a short-term improvement during the intense period, or maybe not even that.

The leaders who break the cycle ask a different question.

Instead of “How do we improve our results?” they ask: “What would our organization have to look like for these results to be impossible to avoid?”

It’s a subtle shift, but it moves the focus from activity to design—from what we do to what we build. In my experience, that shift is where sustainable change begins.

Where to Start

If you’re reading this and recognizing your organization in the first company rather than the second, the place to start isn’t another program.

Start by honestly assessing what your system is currently designed to produce—not what you want it to produce, but what it’s actually built for. Check where improvement activity happens (with specialists or on the line?), how problems are handled (brought up or managed quietly?), how leaders spend their time (on the floor or in meetings?), and whether people doing the work can connect their daily tasks to the organization’s direction.

The gap between where you are and where you want to be is a design gap. And design gaps need design solutions, not just more programs, more tools, or more pressure.

The goal was never continuous improvement.

The goal was always to improve the organization itself.

Those are very different things. And building the second one is the most important work a leadership team can do.

Lee Coppin is a leadership and operations consultant and speaker with 25 years of experience helping executive teams in regulated industries redesign their organizations for sustainable excellence.

If this resonated with you, reply to this email or connect on LinkedIn. This is the conversation I work in every day.

The goal of most improvement programs is to get better results. Makes sense, right? But here’s the problem — they’re designed to run, and then finish. And the moment they finish, the organization drifts back. Because nothing about the organization itself changed.

The goal shouldn’t be continuous improvement. The goal should be a self-improving organization. One that gets better automatically — because of how it’s built. Where problems get surfaced, not hidden. Where the people doing the work have the skills to fix it. Where leadership behavior reinforces improvement every single day — not just during the program.

That’s not a bigger initiative. That’s a different design. And I’ll tell you exactly what that looks like all week. Follow me, and you won’t miss it.

I’ve walked into hundreds of organizations over 25 years. And I can usually tell within the first hour which one I’m looking at.

Here’s the question I ask: Who owns improvement here? If the answer is the CI team, the Lean department, the transformation office, the organization is running a program. If the answer is the line — the plant manager, the team leader, the operator — the organization is building something sustainable. Because if improvement is owned by a team whose job is improvement, the moment that team leaves or gets restructured, improvement stops. But if improvement is owned by the people doing the work, it never stops. Because it’s just how they work.

That’s the shift. From improvement as a program to improvement as a behavior. It’s not complicated. But it is hard. And most organizations never make it. If you’re trying to make that shift, follow me — this is what I talk about every week.