WHY YOUR IMPROVEMENT TEAM STARTS AT THE ORG CHART

If you run an operation of any size and you’ve ever assembled an internal team to improve it, I can tell you with near certainty where they started. They started with the org chart.

Maybe they called it something else. A restructuring initiative. A realignment. A span-of-control review. A leadership assessment. But the core action was the same: before they looked at a single process, before they understood who the customer really was, before they examined how the work actually flowed through the operation, they began moving boxes on the org chart. Changing reporting lines. Consolidating departments. Replacing people.

I have watched this happen in mining operations, in insurance companies, in banks, in food production plants, in manufacturing facilities, and in financial services firms. Across more than eighty engagements on three continents over twenty-seven years. And the outcome is always the same. They restructure, the disruption ripples through the operation for months, some things improve, many don’t, and eventually they’re left wondering why the investment in new leadership and new structure didn’t produce the operational performance they expected. Then they either restructure again or they call someone like me.

The reason it doesn’t work isn’t that the people they brought in were wrong. It’s that the org chart is the third thing you should change, not the first. And when you start there, you guarantee that you’ll have to redo the first two things later, at greater cost, with a more fatigued and more skeptical organization.

WHY THE ORG CHART FEELS LIKE THE RIGHT PLACE TO START

Before I explain why starting with the org chart is structurally wrong, I want to be honest about why it feels so right. Because it’s not a stupid instinct. It’s a very rational instinct applied to the wrong problem.

When an operation is underperforming, leadership looks around and sees people. They see the department head who can’t seem to hit targets. They see the supervisor whose team has the highest error rate on the floor. They see the VP who’s been promising improvements for two years and hasn’t delivered. And the conclusion writes itself: the performance problem is a people problem. Fix the people, fix the performance.

This conclusion is reinforced by everything that executives have been taught about leadership. You’re accountable for your team. If the team isn’t performing, it’s your job to put the right people in the right seats. The entire language of management literature supports this framing: right people on the bus, A players in A positions, upgrade your talent. It’s a compelling framework. And it’s not entirely wrong. People do matter. But it skips two questions that matter more.

The first question: do we actually understand, in specific and measurable terms, what our customer requires from this operation? Not what we think they require. Not what we’ve always assumed. What does the customer, internal or external, actually need this process to deliver, at what speed, at what quality level, at what cost?

The second question: is the process itself designed to deliver that? Not the people running the process. The process. The workflow, the handoffs, the decision points, the measurement systems, the feedback loops. Is the machine designed to produce the outcome we need?

Until those two questions are answered, changing the people who run the machine is rearranging deck chairs. You might get a temporary bump from new energy and new eyes, but you’ve put new operators inside the same broken system. And within six to twelve months, the new operators will produce results that look suspiciously like the results the old operators produced. Because the constraint was never the operators. It was the machine.

THE WAY COMPANIES ARE ACTUALLY BUILT: VERTICAL BY DEFAULT

To understand why the org chart move fails so reliably, you have to understand how most organizations are structured in the first place. And the answer, across virtually every industry I’ve worked in, is the same: they are built vertically.

Departments are organized around common skill sets. In an insurance company, you have an underwriting department, a claims department, a policy servicing department, a billing department, a compliance department. In a bank, you have lending, servicing, collections, operations, risk. In a manufacturer, you have production, quality, maintenance, planning, shipping. Each department has its own leadership, its own metrics, its own priorities, and its own view of what success looks like.

There is a logic to this that runs deeper than tradition. Grouping people by common skill set creates scale efficiencies. If you have thirty underwriters, it’s cheaper and more manageable to put them in one department with one manager and one set of standards than to scatter them across multiple process teams. Training is centralized. Career paths are clear. Expertise concentrates. From a cost-per-unit-of-skill perspective, the vertical model is efficient. And that efficiency is real, which is why virtually every organization of any size eventually organizes this way.

But here is what that efficiency is actually optimizing for: it is optimizing for the cost of deploying skills. It is not optimizing for the delivery of customer outcomes. And the reason organizations default to skill-based structure rather than demand-based structure is, in my experience, almost always the same. They don’t truly understand their customer demand. Not the volume of transactions. They usually know that. I mean the actual nature of the demand: what the customer needs the end-to-end process to deliver, at what speed, at what quality, and with what variation. They don’t understand how that demand translates into specific skill requirements at each stage of the horizontal process. And because they don’t understand the demand well enough to staff and structure against it, they default to the next best thing, which is grouping by skill and letting scale effects cover the gap.

Organizing by skill set is what you do when you don’t understand your customer demand well enough to organize by process. It’s a reasonable default. But it’s still a default, and it carries a cost that most organizations never quantify.

The cost is this: the customer’s experience doesn’t travel vertically. It travels horizontally.

A policyholder who files a claim doesn’t interact with a department. They interact with a process that crosses five or six departments before it produces an outcome. And none of those departments own that end-to-end process. Each one owns a piece. The claim starts in intake, moves to assignment, travels through investigation, hits adjudication, passes to payment or denial, triggers correspondence, and potentially loops back through appeals or litigation. Every one of those steps lives in a different vertical. Every one of those verticals has its own manager, its own backlog, its own definition of “on time,” and its own set of priorities that may or may not align with what the customer actually needs the end-to-end process to deliver.

This is not an insurance-specific problem. This is an organizational architecture problem. In the bank, a loan application crosses origination, underwriting, processing, closing, and servicing. In the manufacturer, a customer order crosses sales, planning, production, quality, and shipping. In every case, the customer experiences one process. The company manages five or six departments. And the gaps, the delays, the errors, the rework, almost always live in the handoffs between those departments, in the white space between the vertical boxes on the org chart.

Now consider what happens when the organization decides to improve things by restructuring. They shuffle the vertical leadership. They move the claims director to a new role and bring in someone from the outside. They merge two departments, or split one into two. They change who reports to whom within and across the verticals. But the fundamental architecture doesn’t change. The work still flows horizontally through departments that are still organized vertically. The handoffs that were broken before the restructuring are still broken after it, because nobody examined the handoffs. They examined the boxes.

I’ve seen companies restructure the same operation three times in five years, each time bringing in new vertical leaders, each time expecting that the right person at the top of the department would somehow fix the cross-departmental process failures that no single department owns. It never works. It can’t work. Because the problem isn’t who runs the verticals. The problem is that nobody owns the horizontal.

Every time you move a leader from one vertical to another, or bring in a new one, you are asking that person to optimize their piece of a process they cannot see the whole of. They can make their department faster, or cheaper, or more accurate. But if the upstream department is sending them defective inputs, or the downstream department is bottlenecking what they produce, their improvements will be absorbed by the system. They will work harder inside their box and the customer will notice no difference, because the customer’s experience is shaped by the entire horizontal chain, not by any single vertical within it.

This is why the first pillar in our methodology is Customer Profile, not Organizational Strategy. Before you touch the org chart, you need to see the operation the way the customer sees it: as one end-to-end process that either delivers or doesn’t. The verticals are an internal convenience. The horizontal is the reality. And until you design for the horizontal, no amount of vertical rearrangement will move the needle.

THE SEQUENCE THAT ACTUALLY MATTERS

There is a reason why, when we built The Bismark Method, we locked the five pillars into a strict sequence and made the first pillar the only valid entry point. It wasn’t a philosophical choice. It was the hard lesson of watching what happens when you don’t.

The first pillar is Customer Profile. You start by defining, in measurable terms, who the process serves and what they need. This sounds obvious. It is not. In the majority of operations I’ve walked into, there is no shared, documented, operationally specific understanding of what the customer actually requires. There are assumptions. There are legacy standards that nobody remembers the origin of. There are targets that were set years ago by someone who is no longer with the company. But there is rarely a current, validated, measurable customer requirement that the entire operation is aligned around.

The second pillar is Process Design and Engineering. Once you know what the customer requires, you can design the process to deliver it. This is where the actual workflow gets examined, mapped, measured, and redesigned. Not the people. The process. How does the work flow? Where are the bottlenecks? Where are the handoff failures, particularly at the boundaries between the vertical departments? Where do exceptions accumulate? Where does rework happen? What gets measured, and does what gets measured actually drive the outcome the customer needs from the end-to-end chain?

The third pillar, and only the third, is Organizational Strategy. This is where the org chart lives. And the reason it’s third is brutally simple: you cannot design the right organization until you know what the process needs. The reporting lines, the spans of control, the team structures, the roles and responsibilities should all be derived from the process, not the other way around. The organization exists to serve the process. The process exists to serve the customer. When you flip that sequence and start with the organization, you’re designing a structure to run a process you haven’t examined, to serve a customer you haven’t defined.

The org chart is not a strategy. It is a consequence. It should be the structural expression of a process that has already been designed to deliver a customer requirement that has already been defined. When it comes first, it expresses nothing but assumption.

WHAT THE REWORK ACTUALLY LOOKS LIKE

Let me make this concrete, because the word “rework” sounds mild and it is anything but.

A company restructures its claims operation. They bring in a new VP. The new VP reorganizes the department, creates new team leads, changes reporting lines, adjusts spans of control. There is disruption, there is turnover, there is a settling-in period. After three or four months, the new structure starts to find its footing. Some things improve. Processing time gets a bit better. The VP is cautiously optimistic.

Then someone finally looks at the process. Not at the department. At the horizontal flow. And they discover that the workflow was designed fifteen years ago for a different product mix. The handoff between intake and adjudication has three redundant review steps that exist because of a compliance requirement that was retired in 2019. The quality checks are positioned at the end of the process rather than at the failure points, which means defects compound through six stages before anyone catches them. The metrics the team is measured against track activity within each vertical rather than outcome across the horizontal, so every department is optimizing for its own throughput while the customer waits for the end-to-end result.

None of this was visible from the org chart. And none of it was fixed by the restructuring. The new VP, who is a capable person in a newly designed role, is now running a well-organized team inside a badly designed process. The structure is clean. The work underneath it is not.

Now the process needs to be redesigned. But redesigning the process will change what the roles need to do, which will change what skills are needed, which may change who the right people are, which will change the structure. In other words, the restructuring that was done first now has to be reconsidered in light of the process that should have been designed first. That is the rework. It isn’t just doing the process work you skipped. It’s undoing, or at minimum revisiting, the organizational work you already did. You pay twice. And you burn credibility with the same people who are now being reorganized a second time.

I’ve watched organizations go through this cycle three times in five years. Different consultants each time, different internal leaders each time, same structural error each time. By the third round, the frontline employees don’t even pretend to believe in the initiative. They’ve learned from experience that this too shall pass.

WHY INTERNAL IMPROVEMENT TEAMS ALMOST ALWAYS DEFAULT TO THIS

External consultants from the major strategy firms rarely make this mistake, for a simple reason: they don’t get into operations deeply enough to restructure anything. They diagnose, they recommend, and they leave. The restructure-first error is almost exclusively an internal team problem, and there are specific reasons why.

Internal improvement teams, whether they’re called operational excellence, continuous improvement, transformation, or any of the other labels companies use, are staffed with people who live inside the organization. They know the players. They have opinions, developed over years of working with these people, about who is effective and who isn’t. When they’re given a mandate to improve the operation, their instinct is to start with what they know. And what they know is the people and the departments. They know the verticals. They don’t necessarily see the horizontal.

There’s also a capability gap that drives the pattern. End-to-end process design is a genuine engineering discipline. It requires a specific set of skills: the ability to map a process across multiple departments at the right level of detail, to identify the design flaws as distinct from the execution failures, to define measurable customer requirements for the full horizontal chain, to engineer handoffs between verticals so that what one department produces is exactly what the next department needs, and to build measurement systems that track the end-to-end outcome rather than the departmental activity. Most internal improvement teams don’t have these skills, not because they’re unqualified people, but because cross-functional process design isn’t what they were hired or trained to do. Many of them came up through Lean or Six Sigma programs, which are excellent at optimizing within a department but don’t typically address the question of whether the horizontal process itself is the right design.

So the team defaults to what it can execute: the org chart. It’s visible, it’s within their authority, and it produces immediate, observable change. It feels like progress. And in a corporate environment where internal teams are under pressure to show results quickly, the org chart is the fastest way to demonstrate that something is happening. The fact that it’s the wrong something only becomes apparent months later, and by then the initiative has already declared its early wins and moved on.

THE DEEPER PROBLEM: CONFUSING BEHAVIOR WITH DESIGN

Underneath the restructure-first instinct is a confusion that I believe is the single most expensive misunderstanding in operational management. It is the confusion between behavioral problems and design problems.

When a process is underperforming, there are only two possible explanations. Either the process is well designed and the people aren’t executing it properly, or the process is badly designed and the people are doing the best they can inside a system that doesn’t work. In my experience, across twenty-seven years and more than eighty clients, it is the second one the vast majority of the time. Not every time. But the vast majority.

Yet organizations almost always diagnose it as the first. They look at the underperformance and see a behavior problem: people aren’t following the process, people aren’t meeting the standard, people aren’t delivering what’s expected. And the natural response to a behavior problem is a people solution: coaching, accountability, replacement, restructuring.

What they rarely do is ask the more uncomfortable question: is the process itself set up to succeed? Because if the process is designed in a way that makes failure likely (unclear handoffs between departments, metrics that reward vertical activity rather than horizontal outcome, redundant steps, no feedback mechanism, specifications that don’t match what the customer actually needs from the end-to-end chain) then the best people in the world will still underperform. They’ll just underperform more politely.

I once walked into an operation where the frontline leadership had been turned over three times in two years. Three complete rounds of hiring, onboarding, and hope. Each time, the new leaders came in with energy and optimism. Each time, within six months, they were producing the same results as their predecessors. Leadership was convinced they had a talent pipeline problem. What they actually had was a process that was designed for a product mix that hadn’t existed for four years, metrics that measured departmental throughput instead of customer outcome, and a handoff structure between verticals that guaranteed rework at every transition point. No leader was going to succeed inside that system. They were set up to fail before they sat down at their desks.

If you’ve replaced the leadership twice and the results haven’t changed, the problem is almost certainly not the leadership. The problem is what the leadership is being asked to lead.

THE OBJECTIONS I KNOW ARE COMING

I’ve been making this argument to executives for a long time, and the pushback is predictable. It’s also fair. Let me address it directly.

“Functional expertise matters. You can’t just dissolve departments.”

You’re right, and I’m not suggesting you should. Functional verticals exist for good reasons. You need underwriting expertise concentrated in one place. You need maintenance skills managed as a discipline. I’m not arguing against departments. I’m arguing against the assumption that rearranging departments is the same thing as fixing the process that runs across them. The verticals can stay. What needs to change is that someone, somewhere in the organization, has to own and be accountable for the horizontal, the end-to-end process that the customer actually experiences. Right now, in most organizations, nobody does. Every department optimizes its piece, and the seams between them are where the failures live.

“We tried a process-based org structure once. It was chaos.”

I’ve heard this one many times, and when I dig into it, the story is almost always the same. Someone read about process-based organizations, decided to reorganize around processes instead of functions, and blew up the functional structure overnight. Of course it was chaos. You took a stable (if imperfect) organization and replaced it with a theoretical model that nobody understood, that had no transition plan, and that eliminated the functional expertise people had spent their careers building. That’s not a process-based design failing. That’s a Pillar 3 move being made before Pillars 1 and 2 were done. The answer isn’t to swing from pure vertical to pure horizontal. The answer is to design the end-to-end process first, then figure out how the existing functions need to be coordinated, connected, and measured differently to serve that process. The functions often stay. The way they interact changes.

“Some of our best turnarounds came from bringing in new leadership.”

I don’t doubt it. And when I look at the cases where a leadership change genuinely transformed an operation, what I almost always find is that the new leader didn’t just bring a new personality. They brought a new way of seeing the work. They came in and, whether they used this language or not, they asked the Pillar 1 and Pillar 2 questions. They asked what the customer needed. They asked how the process actually flowed. They redesigned the work before they restructured the team. The leadership change worked not because the old leader was the wrong person, but because the new leader happened to bring the skills and the instinct to address what was actually broken. That’s a happy accident, not a strategy. And it depends entirely on the new leader having those specific capabilities, which many excellent leaders don’t, because process design is a distinct skill set that has nothing to do with general leadership ability.

“This sounds like you’re describing matrix management. That’s been tried and it usually fails.”

Matrix management is an organizational structure. I’m talking about a sequence of work. The distinction matters, but since you’ve raised it, let me explain why I think matrix management fails and what would actually work better.

Matrix management tries to solve the vertical-horizontal tension by giving people two bosses: a functional boss and a process boss. In practice, this creates confusion about accountability, slows down decision-making, and frustrates everyone involved. But the deeper reason it fails is that matrix management is still an attempt to solve a demand problem with an organizational structure. The company doesn’t truly understand its customer demand, not just the volume but the nature of it: what the end-to-end process needs to deliver, what skills are required at each stage, how much capacity each stage actually needs, and what the variation in that demand looks like. Because they don’t understand the demand, they can’t staff or structure against it. So they default to organizing by skill set, which is cost-efficient because of scale effects, and then they bolt on a matrix overlay to try to get the horizontal coordination they’re missing. It’s an organizational band-aid on a demand comprehension problem.

I believe you can do better than that. If you understand the customer demand clearly enough, you can scale the operation to that demand directly. You can staff each stage of the horizontal process based on what the demand actually requires, with the right skills in the right quantities at the right points. And then, instead of carrying the ambiguity of a matrix, you build in measured excess capacity, a deliberate, quantified buffer specifically designed to handle exceptions and off-spec situations. Not slack that exists because nobody measured it. Not spare headcount that accumulated because the budget allowed it. Measured excess: a known quantity of capacity, staffed with specific skills, allocated specifically to handle the variation that every operation encounters.

That approach requires understanding your demand at a level of detail that most organizations have never attempted. Which is exactly why Pillar 1, Customer Profile, comes first. You cannot scale to demand you haven’t defined. You cannot build measured excess for exceptions you haven’t characterized. And you certainly cannot design an organization to serve a process you haven’t engineered. The matrix is what you get when you try to skip all of that and solve the problem with reporting lines. It doesn’t work because reporting lines were never the problem.

“Our industry has regulatory requirements that dictate how we organize.”

Regulation constrains your organizational options. It does not eliminate them. In insurance, in banking, in mining, in food production, I’ve worked in heavily regulated industries for my entire career. Every one of them has compliance requirements that affect who can do what and who has to report to whom. None of those requirements prevent you from understanding your customer’s needs before you restructure. None of them prevent you from redesigning the process that serves that customer. And none of them prevent you from building an organization that is shaped by the process rather than by habit. Regulation tells you what the boundaries are. It doesn’t tell you to start at Pillar 3. That choice is all yours.

“You’re making it sound like people never matter. Sometimes the problem really is a bad leader.”

Sometimes it is. I said that earlier and I mean it. There are leaders who lack the character, the work ethic, or the fundamental competence to lead, and no amount of process design will compensate for that. But here’s my challenge to you: how do you know? How do you distinguish the leader who is genuinely wrong for the role from the leader who is struggling inside a system that makes success structurally impossible? If the process that leader is responsible for was never designed to deliver the customer requirement, and the metrics that leader is measured against track departmental activity instead of end-to-end outcome, and the handoffs that leader depends on from upstream departments are broken, how would you tell the difference between a people problem and a design problem? The honest answer, in most organizations, is that you can’t. And when you can’t tell the difference, the responsible move is to fix the design first. If the leader still underperforms after the design is right, you have your answer. But at least it’s a real answer, not an assumption.

WHAT THE RIGHT SEQUENCE PRODUCES

When you do this in order, something remarkable happens. And it’s the thing that surprises clients the most.

You start with the customer. You define, in specific terms, what the end-to-end process needs to deliver. You validate those requirements with the people who actually receive the output. You document them in a way that the entire operation can align around. This alone, this first step, often changes the conversation completely, because it frequently reveals that individual departments have been optimizing for things the customer doesn’t actually value while the end-to-end outcome the customer cares about falls through the cracks between the verticals.

Then you design the process. You map how the work actually flows across departments, not how the procedure manual says it should flow within each one. You identify the design flaws, especially at the handoffs. You redesign the workflow, the decision points, the measurement systems, and the feedback loops so that the horizontal chain is structurally capable of delivering the customer requirement. And because you now understand the demand, you can size each stage of the process to match it, with deliberate, measured capacity built in for the exceptions and variation that the operation will inevitably face. No more guessing. No more overstaffing one vertical because the upstream vertical is unpredictable. The demand is known. The process is designed against it. The excess is intentional and quantified.

And that is the surprise. When you get to the org chart, the restructuring question often answers itself. The process design reveals what roles are needed, what skills those roles require, what the reporting relationships should be, where cross-departmental coordination needs a specific mechanism rather than goodwill, and where the spans of control should sit. You’re no longer guessing about the right structure based on personality assessments and leadership philosophy. You’re building a structure that serves a specific, validated process that delivers a specific, validated customer requirement.

And here’s the part that keeps surprising people: many of the leaders who were identified as “wrong for the role” under the old structure turn out to be perfectly capable under the new one. Because the new structure gives them clear processes to lead, clear metrics that track the end-to-end outcome they can actually influence, and clear customer requirements to point their teams toward. The problem was never that they couldn’t lead. The problem was that they were leading inside a system that made success impossible regardless of who sat in the chair.

THE REAL COST OF GETTING IT BACKWARDS

I want to be specific about what the restructure-first approach actually costs, because the expense goes well beyond the consulting fees and the severance packages.

There is the direct cost: hiring, onboarding, severance, recruiter fees, temporary coverage, lost productivity during transitions. For a mid-sized operation, a single round of leadership restructuring can easily run into the hundreds of thousands before a single process has been improved.

There is the time cost. A restructuring takes three to six months to settle. During that period, the operation is in transition. People are learning new roles, new reporting lines, new expectations. The operation doesn’t stop during this time. It just runs less effectively while everyone adjusts. Multiply that by two or three restructurings (which is not unusual for organizations caught in this cycle) and you’re looking at a year or more of degraded operational performance before anyone even starts working on the actual processes.

And then there is the credibility cost, which is the most expensive of all and the hardest to recover. Every restructuring sends a message to the frontline: we think the problem is you. Whether that’s the intent or not, that is what the organization hears. And after the second or third round, the people who are still standing have learned a very specific lesson. They’ve learned that improvement initiatives come and go, that leaders come and go, and that the safest strategy is to keep your head down, comply with whatever the new regime requires, and wait for the cycle to reset. This is the organizational scar tissue that makes every subsequent improvement effort harder. Not because the people are resistant to change. Because they’ve been taught by experience that change doesn’t last, and that cooperating fully with it is a risk with no long-term reward.

The org chart is not your enemy. It’s an important tool, and getting the organizational structure right matters enormously. But it is the third conversation, not the first. And every time you start there, you are building a house by choosing the furniture before you’ve drawn the floor plan, to serve a family whose needs you haven’t asked about.

If your internal improvement team is planning a restructuring, or if you’re about to hire a firm to help you “optimize your organizational design,” I’d ask you to stop and answer two questions first. Do you have a documented, validated, measurable understanding of what your customer requires from the end-to-end process? And is that process, the horizontal chain that crosses every vertical on your org chart, designed to deliver it?

If the answer to either question is no, you’re not ready for the org chart. You’re ready for Pillar 1.