Who Actually Understands Why the Work Exists?

Early in any engagement, before I’ve formed opinions about strategy or process, I ask a simple question: who should I be talking to? Not who’s on the org chart, not who has the longest tenure — who actually understands why the work exists?

That question does more diagnostic work than almost anything else I ask. The answers reveal who in the organization thinks about the work at the level of purpose and outcome, and who thinks about it at the level of current procedure. In a stable environment, the difference is manageable. In a major transformation, it’s everything.

The instinct in most organizations is to put the most experienced people on the transformation team. That seems right. You want institutional knowledge in the room, especially when the stakes are high and the timeline is compressed. But experience is not a monolithic thing, and when you’re designing significant change you need to be precise about what kind of experience actually serves the work ahead.

The ERP Story I’ve Never Forgotten

Early in my career I watched this play out on an ERP implementation in a way that has stayed with me ever since. One team member knew the existing project accounting process cold — every step, every exception, every shortcut. The problem was that the existing process was essentially a series of workarounds built on top of a system that was never designed for the work it was being asked to do. The expertise was real, but it was expertise in the dysfunction. When it came time to design something better, that team member couldn’t get there. The workarounds had become the mental model, and the mental model couldn’t be set aside.

We brought in someone else — less senior, less steeped in how things had always been done, but grounded in what sound project accounting actually required. The quality of thinking changed immediately. The new team member reasoned from the underlying discipline rather than from the inherited process, and the work reflected it.

Both people would have called themselves experts. From the outside, their credentials looked similar. But one was an expert in the current broken system, and the other was an expert in the work itself. In a transformation, only one of those is an asset.

Two Kinds of Expertise

It’s worth naming the distinction clearly, because the conflation of these two things is the source of a lot of preventable difficulty in transformation programs.

Process expertise is deep familiarity with how something currently gets done — the steps, the exceptions, the informal workarounds, the institutional history of why things are the way they are. Process experts are invaluable for operational continuity. They keep complex systems running in the face of ambiguity because they’ve internalized the system well enough to navigate its gaps. That’s a real skill, and it shouldn’t be dismissed.

Discipline expertise is grounded understanding of what the work is actually supposed to accomplish — the underlying logic that should drive how it’s designed. A discipline expert doesn’t just know how your current system works. They know what the output of a well-designed function should enable the business to do. They can evaluate a process against first principles, not just against the current practice.

The crucial difference is where each kind of expert starts when they encounter a problem. The process expert asks: how does the current system handle this? The discipline expert asks: what should the answer actually be? In a stable operation, both questions lead to roughly the same place. In a transformation — where the current system is being replaced precisely because it isn’t working well enough — they lead in opposite directions.

This distinction has a name in organizational learning research. Chris Argyris, the late Harvard Business School professor, described something closely related in his work on single-loop and double-loop learning. Single-loop learning asks: how do we fix this within the existing framework? Double-loop learning asks a harder question: should this framework exist at all? The process expert, however skilled, is almost always operating in single-loop mode. The discipline expert has access to the double-loop question — and in a transformation, that’s often the only question worth asking.

Why Organizations Keep Making This Staffing Mistake

Understanding the distinction is one thing. Acting on it is another — and the organizational dynamics that make it hard deserve to be named directly.

The people with the deepest familiarity with the current process are almost always the first ones nominated for a transformation team. This happens for understandable reasons. They can answer every question about how things work today. They have credibility with the business. They know where the bodies are buried. In a high-stakes, compressed-timeline initiative, that institutional knowledge feels essential to have in the room.

And it is valuable. The mistake isn’t including process experts — it’s putting them at the center of the design work, where their attachment to the current state can constrain the thinking of the whole team. The person who has spent years mastering a system has a real stake — often unconscious — in that system’s logic persisting in whatever comes next. That’s not a character flaw. It’s human. But it matters enormously for how you structure the work.

Cognitive science gives this a name: the expert blind spot. Researchers at Carnegie Mellon found that as people develop deep expertise in a domain, they can paradoxically lose the ability to see that domain from a beginner’s perspective — or from the perspective of someone redesigning it from scratch. The knowledge that makes them effective operators can make them poor designers. They fill in gaps automatically, accept constraints unconsciously, and optimize within a system whose fundamental assumptions they’ve stopped questioning.

There’s also the political dimension. The people who have been around longest often have standing in the organization. Moving them out of the core team requires care and a clear frame for why you’re doing it. The frame I find most useful: the role of the process expert on a transformation isn’t to design the future state. It’s to validate that the future state will actually work in this organization, with these people, in this context. That’s a genuinely important role — and making that distinction explicit tends to land better than treating it as a demotion.

The Diagnostic Question

The question I keep returning to is simple: does this person understand why the work exists, or do they understand how it currently gets done?

In practice, you can hear the difference in how people respond to hypotheticals. If you ask a process expert “what if we removed this step entirely?” the typical response is some version of “we can’t do that, because then X wouldn’t happen.” The constraint is the current design. If you ask the same question of a discipline expert, they’ll think about it differently: “well, what is that step actually accomplishing? If we could accomplish the same thing another way, or if it turns out we don’t need to accomplish it at all, then yes, removing it might make sense.”

The process expert treats the current design as a given. The discipline expert treats it as a hypothesis.

Another version of this diagnostic: ask someone to describe what a genuinely better version of the current process would look like — not tweaks to what exists, but a fundamentally better design. The process expert will often struggle here, because improving something requires being able to see it from outside, and the current design is the only frame they have. The discipline expert can engage with this question more freely, because their reference point is the underlying purpose, not the inherited procedure.

Researchers who study expertise make a parallel distinction between procedural knowledge — knowing how to execute a sequence of steps — and conceptual knowledge — understanding why those steps produce a particular outcome. Both matter in a stable operation. But in a transformation, only conceptual knowledge allows someone to reason about whether the steps should change, be combined, or be eliminated entirely. The person who only has procedural knowledge will defend the procedure even when the outcome it was designed to produce is no longer the right outcome.

The Combination That Works

What you actually need on a transformation core team is a specific combination, and it’s harder to find than it looks.

You need people who understand the underlying discipline well enough to recognize a better design when they see one — who can reason from purpose rather than from practice, and hold the current process lightly enough to question whether it should survive at all.

And you need people who are honest about the gap between what the current process does and what it should do — who can articulate why things are the way they are without defending that they should remain that way. That’s the harder find. Most people who’ve worked inside a system for years have developed some investment in its logic, even when they know it’s imperfect.

When I find that combination in a single person — someone with deep institutional knowledge who can simultaneously hold it lightly — it’s a significant asset. More often, you build it across the team: discipline experts who provide the anchoring logic, process experts in an advisory capacity who keep the design grounded in operational reality, and at least one person whose job it is to ask whether the whole thing is actually serving the purpose it claims to serve.

Holding Knowledge Lightly

There’s a disposition that sits underneath all of this that deserves its own attention: the ability to hold expertise lightly.

It’s different from not having expertise. It’s different from being uncertain. It’s the capacity to know something deeply and still treat it as provisional — to hold current practice as a data point rather than a constraint, to remain curious about whether what you know is actually the right answer for the problem in front of you.

Carol Dweck’s research on growth mindset touches on part of this, but the more specific concept is what researchers call epistemic humility — a willingness to acknowledge the limits of what you know, even when your expertise is genuine. Studies on high-performing teams consistently find that this quality is a stronger predictor of good collective decision-making than raw expertise alone. The most knowledgeable person in the room is not always the most useful one, especially when the room is trying to design something that doesn’t yet exist.

This disposition is relatively rare. Most of us, when we’ve invested years in understanding something, develop a natural attachment to the logic of what we’ve learned. That attachment is part of what makes expertise valuable — but in transformation work, that same quality can close off exactly the thinking the moment requires.

The leaders and team members who navigate this well tend to have a particular orientation: they’re interested in being right more than they’re interested in having been right. They’re willing to update. They can distinguish between their expertise — which is real and useful — and the specific practices that expertise has led them to, which may or may not be the best answer going forward.

That’s the orientation worth looking for when you’re building a team for significant change. Not the most knowledgeable people in the room. The most knowledgeable people who can still be surprised.

The Question Worth Asking First

This is the trap that catches a lot of ops leaders during a significant initiative. The people with the deepest familiarity with the current process are often the first ones nominated for the core team, because they can answer every question about how things work today. But that fluency can become a liability when the goal is to replace how things work today with something fundamentally better. The more invested someone is in the current system — even unconsciously — the harder it is for them to reason cleanly about what the system should become.

None of this is a character judgment. The team member who knew every workaround in that ERP process was not a bad operator — they were probably very good at keeping a flawed system running. That’s a real skill. It’s just not the skill you need when you’re building the replacement.

Before you finalize who’s on the team, ask the question: does this person understand why the work exists, or do they understand how it currently gets done? In a stable environment, those questions have the same answer. In a transformation, they don’t. And knowing which kind of expert you’re sitting across from is one of the most useful things you can understand early.

Bearing Check: Think about the last transformation initiative you staffed. Were the people at the center of the design work experts in the discipline — or experts in how things have always been done? What was the difference in how they showed up when the design required questioning an assumption the current process had always treated as fixed?