Blog

Reorganize Less, Reorganize Better

Org design is a big moment for a team or an entire organization, no matter how large or small the magnitude. It should be a lever that is pulled by a leader less frequently than it often is.
Once it’s pulled, it should be done with more rigor, more creativity, and more speed than it often is. This paper describes how to improve the success of your organizational design
transformation.

Download the PDF “Reorganize Less, Reorganize Better” White Paper Here Reorganize Less, Reorganize Better or view the content below

Reorganize Less, Reorganize Better

Org Design Enables, It Takes More to Deliver

The words “org design” or “org change” are enough to evoke sympathy and fear. That’s unnecessary. Organizational design can be a powerful lever, albeit a hard one, to produce new results. How did we get into this quandary where the intent and the experience are so far apart?

Performance is slipping and the leadership is under pressure. We have to do something. Let’s change the organizational design.

While these aren’t the words said out loud, it is often the level of critical thinking that gets ideas of organizational design (or simply org design) moving. Once we start looking, of course we can see opportunities to organize better, and now the momentum toward a reorg has begun. This train starts rolling down the tracks and is hard to stop. But should it have ever left the station, and is it even on the right set of tracks?

Those are some of the questions to be answered in this whitepaper. The goals are to make org design a less frequent occurrence, but when done, to be done more thoughtfully and effectively. This examination will cover when org design is the right answer, key variables to consider, pitfalls to avoid, and how to manage the change itself.

PART I   Deciding

When is organizational design the right lever to pull?

Org design should be less frequent than it is, primarily because it is highly disruptive and carries plenty of risk, ranging from loss of talent to the surprisingly high rate of making things worse rather than better. The rest of this paper will try to reduce that risk, but the disruption itself is like moving your home. Things get lost and broken, and while the move is going on, it feels like chaos. You might look forward to the new home, but never to the process of moving.

The broader climate argues for restraint too. Gartner research reported in Harvard Business Review found that the average employee experienced 10 planned enterprise changes in 2022, up from 2 in 2016¹, while employees’ willingness to support change fell from 74 percent to just 43 percent in that same time span.

Because org design should be low frequency, and because it affects many variables, you will likely engage when you have multiple variables that need improvement rather than a single one. I have put those reasons into a framework with four categories: Focus, Scale, Execution, and Alignment. Even if one of these is your primary reason, be very aware of the other categories, because you will be affecting them whether you intend to or not.

Focus may be one of the most important, at least because it’s one of the hardest to develop alternative solutions for. Here’s my simple test: if something is important, is someone waking up and thinking about that important thing? It could be anything from an initiative to a market to a product line. If it’s not the first thing on someone’s mind but the second or third, then it is not getting the focus it likely deserves and needs.

Scale is the next driver of purposeful org design. If you are expanding, you likely need more people, but that alone is not a reason to change the structure. The structure changes because new areas need attention. Purchasing may have just been a task, but now it’s called sourcing and is a strategic capability requiring different capabilities and processes. You might argue that this is just another side of Focus, and you would have a valid point, but it differs in how you arrive at the need and the conclusion that it is time for an organizational change. Imagine your current org design, then mentally quadruple the size of the organization, and you can imagine the things that go wrong.

On the flip side, contraction is an equally important reason. Whether contraction is a slow loss of revenue or brought about dramatically in a split-up similar to what GE did, the structure needed is quite different.

Acquisitions become a scale-related forcing function for considering org design changes. Do you tack the acquisition on as a complete division, fully integrate it, or something in between? Often this will depend on the decision to retain the CEO and how important they are, which are considerations that come up later in this paper.

Execution gaps are the third trigger driving the need for org design. A good example of this exploration is whether engineering teams are centralized or decentralized. If they are centralized, they can share best practices and standards, solve problems more collectively, cultivate talent, and have enough concentration of resources to justify investments in tools. If decentralized, those engineering resources are more closely coupled with the product management, sales, and operations resources related to their product, improving collaboration and often speed. Which of those gaps gets too big often dictates which way the pendulum swings, too frequently going back and forth every few years.

There are several popularized solutions meant to chip away at one gap or another, such as the Center of Excellence model or the Shared Services model. These are “out-of-the-box” org design solutions that include many variables at once, but when you know what you’re trying to solve, they may be a good place to start.

Spans and layers is often a cost-related version of this trigger, more likely initiated by a CFO than a functional leader, or sometimes simply by a consultant hired to poke around for cost savings.

Alignment is our final trigger. The evidence of alignment problems overlaps with execution, but it is experienced as persistent cross-functional friction, misalignment of priorities, or decision bottlenecks. Of the four reasons, it may also be the most feasible to overcome through solutions other than org design, but that doesn’t mean org design isn’t a consideration.

The half-hearted version of this is a leader not getting what they want from a supporting function and declaring that if the resources reported to them, then priorities would be solved. That might be true, and it represents a narrow version of an alignment problem, but it is likely to cause other problems.

I watched one organization realign their org structure from product focus to market focus to geography focus, and then back through the entire cycle again, all in about 12 years. This highlights the problem with this trigger: if org design is the only mechanism you use to drive alignment, you will forever be chasing that objective.

In problem solving, we prefer crisp and well-defined gaps to solve. This should ideally apply to org design as well, although the majority of the time you are actually trying to solve more than one problem at once. Despite the increased level of difficulty for these types of problems, the more clearly you define the problem or problems you are solving, the more likely you are to land on an effective solution.

 The four triggers of organizational design

Can you get the benefits of a reorg without reorganizing?

A central thesis of this paper is that you cannot simply change the org design and get a different result. There’s a lot more work you have to do around decision rights, information flows, and other variables to get the outcomes desired. It’s actually that work that produces the outcomes, not the org design itself. If that’s true, maybe we shouldn’t even bother with a reorg.

This will be a bold claim, and while I doubt many organizations will take this particular advice, I think just considering it will make your design work stronger and more robust. Here’s the option: if org change is incomplete without all the supporting changes, just focus on all the supporting changes, and you don’t need to actually change the org design itself.

This is not to suggest that there is no value in org design. There is. It can often be a vital and transformational change. Organizational strategy models that include org design, or org structure, as only one element have been around a long time. That means it’s hard to leverage org design all by itself, but it also means there are other levers to affect change. One of the more famous versions is organizational design scholar Jay Galbraith’s Star Model: strategy, structure, processes, rewards, and people.

PART II   Designing

Should you design around process or talent?

What criteria do you use for designing your organization? Too frequently, this exercise overloads the design effort with too many criteria. There is a single spectrum on which you should base the bulk of your design work: will you be designing around process or around talent? Many other variables will help you select and adjust the design, but these are the inputs.

A process-centered org design considers primarily how work flows, or how it should flow if you’re trying to transform, and designs the resources around that flow. Accountability, collaboration, handoffs, and alignment are the primary factors in this decision. Team names will generally reflect the role they play in that process. This doesn’t automatically mean that you are designed around function, which is the dominant form of this intent, but even a value stream design is often focused on process first.

Designing around talent appears on the surface to be just a one-off exception, but when done right it’s not done on the margin. A broad and consistent filter of putting your organization together based on getting the most out of your talent may appear confusing to an outsider, but the teams themselves know what needs to happen and get it done. You’ll know this is the factor when you ask “why does this team report to that person?” and the answer is “because they were the best person to lead the work.”

As my clients can attest, I can often find an analogy in soccer (although I do my best not to force them on non-soccer fans). There are coaches who have a system. That system is expected to work a certain way, the players must adapt, and those who cannot are replaced by those who fit the system. There are also coaches who look at who they have on the roster and then figure out how to get the best out of them. They may change systems throughout the season, or even within a match, to get the best from those players. While there is debate about which approach is better, it will never be resolved, because the fact is that both can work well, as long as you understand how you are trying to play.

The same is true for organizations; there is no right answer. There are pros and cons, good fits and bad ones. Perhaps the only two wrong answers are (1) bouncing back and forth between both frequently and (2) not designing with intention.

Before I get into each model, I want to make clear that the application, and in fact this entire whitepaper, is not only about top-level org design for an entire entity. The same thought process, pros and cons, and approach can apply at any level of the organization. So if you’re simply deciding how to put your own team together, everything here is still relevant. The only difference is that you have fewer moving parts and degrees of freedom. You do have to be aware of how the organization around you is designed, but you do not have to be confined by those choices.

Process-centric design

How should the work flow? Who must collaborate with whom at a high cadence and high alignment? These are core questions that shape the design of a process-centric org chart.

At a high level, a very function-centered design (product engineering, product marketing, supply chain) meets this, at least on the surface. However, in many of these designs, the org design shapes the process instead of the other way around. That’s why you must be clear on what you’re trying to accomplish. A functional org design often has the benefit of depth of expertise and talent. If all your electrical engineers are on one team, the answer to the question is somewhere in that team. A junior engineer is surrounded by senior engineers and can both develop and leverage the experience that surrounds them. Like all of these factors, not choosing a functional design doesn’t mean that you have to lose that benefit, but you must be aware that it won’t happen organically within a team.

Value stream teams are perhaps the second most popular concept for a process-centered org design. This is where teams are organized around delivering a product or service to a group of customers. Often the result is getting more people closer to the customer and the customer’s needs, and refining how different tasks may be done to be optimal for that value proposition.

Just to demonstrate that you can make different choices at each level of the organization: a company organized into divisions is essentially a set of value stream designs, but right below that level are often functions. At the same time, a functionally organized company might have product-specific or customer-group-specific teams within a function. These are all process designs, and they can be applied thoughtfully by each leader at each level.

The foundational benefit of a process-centric design is that you can balance scope across different teams by where you put their work boundaries. You have more inherent focus (although not automatic) on the development of resources. And because each person and team knows where they fit within the process, you have focus.

Often, design changes that result in a process-centered design are driven by a shift in strategy, specifically to provide more focus and accountability around accomplishing the new strategic priorities. Where your new strategy is meant to build out a new technology platform or penetrate a new market, ensuring that a team wakes up every day thinking about that priority with focus and energy can improve your chances of success.

The biggest downside of the process-centric design is that people may not have what the role requires, or you may be leaving unutilized talent on the table. If the role of a Product Manager includes capabilities X, Y, and Z but all the available candidates have only two of those, you may put someone in the role who can’t immediately succeed. Of course they can, and must, develop the missing capabilities, but you carry risk until that happens.

Unutilized talent can mean you’re both missing out on potential benefits and frustrating the individual who can’t be their best self. That person may not feel fully valued when they aren’t allowed to bring their best to their work because it isn’t in their scope, and they shouldn’t be stepping on other people’s toes.

The talent-centric design

How do we get the most out of the people we have? Why are we asking someone to do something they’re not good at?

It’s worth noting that most startups begin this way. You have three founders, for example, and they have 101 things to accomplish, and they divide it all up based on the best way to accomplish it with the talents and experience that each brings to the table.

A lot of the decisions in this approach are not primarily about ensuring person A is focused on task X. They are also about removing the burden of task Y from that person and putting it somewhere else (sometimes anywhere else). Why burden your star product engineer with people management tasks when they could put more energy into their design work? Or your best salesperson? Or your best anything?

Continuing with the lessons from startups, this will often be the factor when a founder brings in a CEO from the outside. The outside assumption is that the founder doesn’t think they can be CEO, but more often it is really so they can focus more on what they’re best at, such as product design.

Another way to think about talent-centric design is “how do we let people cook?” In other words, how do we let people be their best, and produce their best, without distraction or burden?

There’s a reason I can’t share sub-types of this concept: it’s not designed around a theme but around individuals, who are unique. As a result, these org designs have fuzzier boundaries around responsibilities. That could be bad in a low-trust, low-collaboration culture, but it can be great where those elements thrive. This is important to recognize because even in a small portion of a talent-driven design, you need to pay attention to the trust and collaboration around the boundaries.

The worst version of this is designing around the ego and limitations of one very important person, albeit it is sometimes necessary. I call this out partly because it happens quite often, isn’t always bad for the organization, and has cascading effects, because other roles must be designed around that change. When you have a very talented individual who either refuses to do some of their important responsibilities, or just does them very poorly, it benefits everyone to remove those responsibilities and put them somewhere else.

An example of this might be the designated hitter in baseball. A player is really good at hitting, but in the field, they’re a defensive liability. Well, let them just focus on hitting. But you only get one designated hitter, which brings us to the consequences. If you take the talent-centric model too far, you end up with too many individual contributors all doing what they love while a whole bunch of important work isn’t getting done.

Another benefit of the talent-centric design is that you can design roles to help develop the talent you need in the future. You can expand someone’s role just a bit to give them some aspect of the organization they need to learn before they take on too much. This can sometimes result in dual roles, awkward boundaries, and even multiple bosses (more on that later), but the person can grow into the new scope and be more valuable and more ready to take on a bigger role later.

The biggest downside of the talent-centric design is that people can get pigeonholed. If you’re really good at something and that’s all anyone lets you do, you are valuable but can also stagnate. When I was a soccer coach, there were certain players who were dramatically better at one role than any other, and if I just wanted to win, that’s where I should play them. But then they wouldn’t grow, so I made it a point to have at least one alternative role that helped expand their abilities and their versatility as a player.

Another downside to a talent-centered design is that it can be harder to do succession planning and to recruit replacements. How do I run a job search for a job that we made up to get the best out of Joe? “Joe’s replacement” is the best definition of what you’re looking for, but no one will know what that means. In these moments, when you lose someone you’ve designed a role around, you may have to revert to a base process-centered design, which means other people’s roles will again change as well.

Either / or?

You are not just choosing between the binary options of process-centric or talent-centric. In fact, on that spectrum, either extreme is likely a bad option. You are likely leaning in one direction or the other, and then making a few exceptions to that primary design.

That means it can get complicated, and messy, and hard. This is part of why you shouldn’t change your organizational design too frequently. It is also why you don’t want to be in transition mode for too long (more on that later as well).

The fact is that every org design you choose will create new problems that can’t be solved with more org design. There is no perfect design. Management scholar Peter Drucker put it this way in Management: Tasks, Responsibilities, Practices (1973)²: “The best structure will not guarantee results and performance. But the wrong structure is a guarantee of nonperformance.” I don’t mean to say that your design doesn’t matter or that you shouldn’t put rigorous thought into getting it right. I am saying you can’t make it perfect. There are consequences that must be addressed no matter what you select, often with process changes, cultural changes, or capability development.

One last note, on org size. As a generalization, larger organizations will default toward process-centered designs and smaller organizations will default toward talent-centric designs. There are path-of-least-resistance reasons for these defaults, but I think there is risk in not embracing the resistance. I don’t have to think as carefully about the individual talents of 2,000 people if I have a process-centric design, but that’s where the failure is. I should be thinking about the talents of 2,000 people. Each one of them matters, and we’re a better organization when we think about those individuals with rigor and purpose. So ignore the defaults, and apply thoughtful rigor.

The “how to” of organizational design

The most important step, and probably the most often skipped, is clearly defining what problem you are trying to solve. You’re about to disrupt the organization, and the real people that work in it. It better be for a good reason.

In my experience, when leaders know things aren’t going well but aren’t sure why, they tend to turn to org design to shake things up. This will buy time, and it may even fix some things that were broken, but only by accident. Without clearly understanding, and defining, what gap you are trying to close, you are unlikely to solve the right problem effectively.

In most problem solving, the ideal approach is a single clearly defined gap and a single solution to close that gap. With org design, that ideal goes a bit out the window, but not entirely. I believe a single core problem statement should be defined before you venture into the great beyond. However, there may be other, secondary problem statements that you’d like to solve at the same time. These could just be considered criteria upon which you evaluate solutions, but I propose that using problem statements keeps you closer to the current reality of the situation as opposed to imagined benefits. At the risk of repeating myself: start with a single, core, observed, well-defined problem statement. This is a core capability of all problem solving, as I write about in People Solve Problems³.

As you consider the core problem statement, ask: is it a chronic, lasting problem? Developing and implementing the solution, which is the new org, will take some time. Will the problem still be painful enough for long enough that it was worth going through the change? This is what every leader must ask themselves, and having clearly defined problem statements makes the pathway more clear.

Designing your first options

The vast majority of the time, leaders will concoct an idea in their head of what move to make without considering many options or evaluating the consequences. Because the consequences can take some time to unfold, and some of them are irreversible, added rigor up front is worthwhile. “Let’s try it” is just undisciplined experimentation. A McKinsey survey of 1,534 executives who had been through a redesign⁴ found that just 21 percent called it a success, and leader alignment was the swing factor: redesigns whose leaders were fully aligned succeeded 49 percent of the time, against 1 percent when leaders were not.

This means developing options through ideation, or if you prefer, brainstorming. I won’t open an entire treatise on ideation (you can read more in People Solve Problems³), but volume of ideas, written out, is fundamentally your best approach. You will find that the first third of ideas are obvious, the second third are desirable but not feasible, and the final third is where you get creative. And there are not many shortcuts to getting to the creative ideas.

You may not ever choose the creative ones, but there are often aspects of those ideas that are worth packing into your final design. Here’s one of the shortcuts, or at least accelerators, to creativity: design to the extreme. Most people won’t see the point because you won’t likely use it, but you uncover design elements that can absolutely unlock greater performance.

I defined the two starting extremes in the last section: fully talent-centric, or fully process-centric. In reality you wouldn’t end up at either extreme, but you know what each looks like now. Other extremes simply answer big questions. What would it look like if you designed your org for where you want to be in 5 years? What would it look like designed for maximum learning? For maximum flexibility? Optimized for customer focus? Optimized for cost? If each one gives you a single idea that you can incorporate into your final approach, the relatively small amount of time you spent on this was absolutely worth it.

Who do you include in this exercise?

There are a lot of problems to solve where more brains are better than one. This is not one of those exercises. In general, involve as few people as possible, but no fewer. What does that mean?

For starters, consider that very few people carry org design around as an experience-based skill. That’s because you don’t get, and shouldn’t get, that many repetitions at it. Some leaders do have a lot of repetitions at it, but that likely results from (a) pulling the trigger on this solution too frequently and (b) not sticking around the outcomes long enough to really understand the consequences. I belabor this point because you’re likely not missing out on a strong set of skills by keeping your circle of involvement small.

The other challenge is that many people who are close enough to the situation to have a strong opinion also have a vested interest. It’s impossible to shut out how a change may affect you personally. People can suppress that, but it’s there.

So, involve as few as possible. But don’t exclude those who need to be involved, either for their capabilities or their vital need for buy-in. Their involvement could be anything from sitting down for a whiteboard ideation session to vetting a specific design option to stress-testing a single element of a design.

There are some people who are both critical to the organization and capable of being disruptive. Their influence does not come from the org chart but could come from popularity, force-of-nature stubbornness, or most often, deep respect for and deference to their judgment. If your general direction might be seen by them as either disrespectful or dysfunctional, it’s useful to include them along the way. This is in part early change management, which we’ll cover later, but they also may have specific solutions to consider that both make them happy and produce a better-functioning design.

Others you may include are those you trust for their capabilities, their discretion, and their intentions. These could be an advisor, a mentor, a team member with whom you have really partnered to run the organization, perhaps your successor. A couple of good brains can accomplish a lot, so choose who you involve carefully.

Now, shouldn’t you include more people to better understand the current state? Isn’t that a core part of effective problem solving? Well, yes, but that doesn’t mean they have to be part of the design. In fact, that work likely began before you reached the point of deciding to do org change. If you are doing robust talent management in your organization, as well as cultural or engagement surveys of any kind, you likely have a great start on the current-state knowledge that you need. Anything else you can go get through observation, data, or other means without widening the circle of who is involved in the design choices. It’s important to consider these elements as input but also reference them as factors when you communicate the design. This essentially gives you credit for involving people indirectly whether people see it that way or not, and also helps frame that the changes you made weren’t just a sudden inspiration while you were taking a jog.

What about small changes?

Some org changes, in fact many, don’t look like entirely new orgs. It might be a single change, like moving who the IT leader reports to, or blending two teams into one. All of the factors covered so far still apply, because all the risks of getting it wrong remain.

You must balance input effort relative to potential impact (both positive and negative). That’s true of all problem solving. You don’t collect a ream of data to improve a meeting agenda, and you don’t put a new food or drug product into the market without comprehensive study. Adjust your efforts according to the risk. This is a judgment call. I will emphasize that (a) all the factors mentioned apply no matter how small the change, and (b) most people under-invest the time needed relative to the potential impact they are about to make.

PART III   The Mechanisms That Make Any Design Work

How do you make roles clear after a reorg?

One of the most important outcomes of the change is not who reports to whom but what their roles are. Clear roles are a vital part of any team and process function, and role clarity is what is most disrupted during the change. Even a simple change, like a new boss, can disrupt who is responsible for what, which, left unattended, can lead to failure modes.

The most commonly used framework for establishing clear roles is RACI (which stands for Responsible, Accountable, Consult, and Inform), so I could call this section “to RACI or not to RACI?” To be honest, I have a love / hate relationship with RACI. On one hand, it is a clear framework that helps establish roles. On the other hand, it is often deployed statically, bureaucratically, and without the rigor and curiosity needed to make it useful. So, if you’re going to do it, then do it right, with meaningful engagement. But if you don’t go through a formal exercise with templates, you can use the intention of the framework for conversations and decisions, so we’ll call this a “RACI mindset.”

I won’t turn this into a RACI teach, as there is plenty of information available. But I want to highlight some key ideas for using either the RACI mindset or RACI templates to drive success.

First, I will distort the term RACI to RACIC, which I wrote about here⁵, adding Customer to the equation. One of the most clarifying mental models is everyone understanding who their internal customer is, and in turn, what needs those internal customers have and what value they provide to those customers. If you get these conversations going, they can lead to a great deal of clarity in decision making, workflow, and even metrics.

Second, limit the Consult roles as much as possible. There is already a natural entropy where more people get added to a decision, but each added Consult role means another meeting, or another person added to a meeting, or another handoff, which introduces delays and errors. Where possible, replace every urge to add a “C” with clear criteria, metrics, or process standards that produce the same end effect on the decision as including someone else would.

Third, focus on the hard decisions, not the obvious ones. A great deal of role clarity is built into the work and even the job title. Don’t waste your time on the obvious. Focus on the places where there is overlap, indecision, messiness, or strong debate. Over and over, I see teams punt on these items in an effort to complete the RACI task (which is why I often don’t recommend it as a required exercise) instead of diving into the hard stuff. Put your time and effort here.

Do dotted-line reporting relationships actually work?

One of the most frequently used mechanisms that can create more problems than it solves is the “dotted line” reporting mechanism. We’ll leave aside the challenge it introduces of making tidy PowerPoint org charts. The real problem is that we believe the dotted line accomplishes more than it really does.

What does the solid line mean? It primarily implies decision rights around direction, standards, and priorities. The structural elements are both overt (performance reviews, hire and fire rights, and so on) and contextual (sitting in staff meetings). So where does the dotted line fit in?

It implies input and influence over those same elements (direction, standards, and priorities) but without any structural elements to back it up. Therefore, you are entirely dependent on the behavior of all participants (employee, dotted-line manager, and solid-line manager) or on adding enough structural elements to have an impact. Those overt mechanisms are generally not available, as they are owned by the solid-line manager. So you are dependent on contextual structural elements like meetings. But every element you add to improve alignment to a dotted-line manager adds time and cost to your overall structure, and the management oversight can end up top-heavy and bloated.

This is not a niche problem. Gallup found that 72 percent of U.S. employees worked on matrixed teams⁶ to some extent, and about a third of highly matrixed workers report spending most of their day in internal meetings, compared with 2 percent of non-matrixed workers.

So rather than use a dotted line to confer decision rights, just skip the line and focus on the mechanisms that actually generate alignment. Build specific decision rights around processes, initiatives, or functional standards. Build shared and visible goals and metrics that align across org chart boundaries. Put the right people into the right meetings to influence and affect outcomes.

And beyond that, would-be dotted-line managers need to also focus on relational currency: with the solid-line manager of those they hope to influence, and of course with those they hope to generate alignment with. This does require a little courage of leadership, because you are leading without overt power or standing. That dotted line was meant to confer standing, but as I’ve outlined above, it rarely does.

Here’s your final test. Ask any manager to name the three decisions that the dotted-line manager actually controls. If they can’t answer the question quickly, then the dotted line is just decoration. If they can answer it, then perhaps the dotted line is redundant, because if you can write those decisions down, you don’t actually need the line itself. To a large degree, that dotted line is an admission of unfinished work.

What are the decision tiers of a completed org design?

If you’re going to make this change, you have to consider the different levels of impact of the surrounding design elements. In the first tier are the decisions themselves, so consider decision rights (who owns it?), decision process (standards, routines, and criteria), decision types (for example, the difference between issuing a refund and changing a refund policy), and escalation rules for when those systems hit abnormal conditions.

The second tier is mostly around information, including information flows, access to information, and the right meeting forums where people come together to share and connect information.

The third tier, less vital but still contributing, is much of the context around those decisions. This includes the metrics used to measure performance and create alignment (or misalignment), and the incentives tied to those metrics. It also includes the decision record, or decision history, and the corresponding organizational memory.

If you’ve taken a vital thread from this section, it’s the power of decision making. But this is more than just process standards and owners. If decision making is what makes all of this most effective, ask yourself: are we investing enough in our people to make them effective decision makers? Most organizations end up, by default, treating this as an innate capability of the people they hire or promote, but there is no question that improvement in decision-making capability can be achieved. If the lever is this powerful, don’t take it for granted.

PART IV   Deploying

How fast should you implement a reorg?

Having an org design and getting it successfully implemented are two different things. Getting through implementation can be risky, emotional, distracting, and tedious.

My strongest recommendation once you’re ready is: GO! Moving through this transition as quickly as possible, and even slightly faster than seems possible, is your best course of action. That feels laden with risk, but I’m here to tell you that dragging things out does not eliminate risk. It actually adds several levels of risk with each added week or month. And there are plenty of weeks to compress: McKinsey found that a typical reorganization takes ten months from plan to practice⁷.

Most consultants who come in to drive such a project are really paid for the preparation, not the success. The meetings, the PowerPoint, the reviews, the formal change management: all consume resources and time. And it keeps everyone in a state of limbo for longer. I’m not saying this work isn’t useful, and I’ve already advocated for rigor, but expediency is the most underweighted contributor to relative success, by a large margin.

Consider what added weeks mean to your org change. First, you were doing this for a reason, and you’re just delaying how soon you achieve those benefits. If there’s a problem to solve that’s big enough to be worth going through this, then don’t you want to achieve that result? Second, you have split focus between the old design and roles and the new design and roles, all while adding a third element of focus, which is the change itself.

But what if we drop balls in the process of transition? Guess what? You will, no matter how much preparation and planning you invest in. It’s impossible not to. How long you are in transition is a greater predictor of how many dropped balls you will have than how much preparation you do. Consider when you move where you live: how easy is it to live out of boxes? Where are things? What’s missing? What’s broken? What’s the best place to put it? How does your daily routine work? That’s the equivalent of being stuck in an org design transition.

How do you reduce the dropped balls through the transition? There are three strategies, and I already gave you the first one: transition quickly. The second strategy is keeping everyone on their toes. Reward “good catches” of things that were missed, keep simple metrics in performance reviews, and shape a mindset of “we’re all in this together.” The third strategy is to designate someone as the “ball catcher.” A ball catcher is a designated person whose job during a reorg transition is to surface and resolve dropped work. Their job is to look forward, surface, and resolve missed assignments, broken workflows, information flow cutoffs, and gaps in ownership. They should be someone generally process-minded, with relatively little at stake in the winners and losers of the change, trusted by those around them, and with access to leadership for ease of rapid escalation. If their job is not one of the ones affected, then that’s an added bonus because they can focus on this new task.

 Three strategies to reduce dropped balls through the transition

Messaging the change

No matter how big or small an org change is, you need to communicate the what, why, how, and who. Much of this communication is functional and informational. But there are two critical, underappreciated factors in messaging that I will highlight here.

The first is taking the care to fully communicate the why of the change, what outcomes you expect to get, and how it affects individual behaviors, decisions, and focus through the change. The reason this is so important is that the org change itself does not deliver the results. The org change only enables different actions and decisions that produce the desired results. This is a vital mentality to adopt because everyone has to be focused on what happens on the other side of the org change.

As an example, if the purpose of the change is to get team members closer to their customers, you may remove organizational layers or functions that buffer them from customers. But just because the buffering layer is removed doesn’t mean that team members naturally engage with more customers with more curiosity and purpose. This requires further change in terms of behavior and even time allocation, and the more clearly you articulate the vision in terms of actions, decisions, and behaviors, the more likely you are to get the desired effects.

The second key to success is considering what to communicate and what not to communicate. The flawed assumption too many leaders make is that they are choosing between what to tell people and what not to tell people. That’s a false choice. The real choice is between what you tell people and what they make up on their own, and the latter is hyperactive during even the smallest of changes. Therefore, you have to turn up the volume of what you communicate, whether informal or formal. The same McKinsey redesign survey found that redesigns where senior leaders communicated the change formally were about four times more likely to succeed⁴. Don’t allow the void to go unserved for too long. Even if there is nothing to report in the middle of the change, tell people that there is nothing to report. Otherwise, they are left with no choice but to use their imagination, and that rarely helps during these transitions.

Many organizations will adopt a change management model to help the transition. There is no right model, so at some level I don’t care which one you use. You could call “leading with empathy” a change management model, and it might get you most of the way there alone.

What about competing change agendas?

You also have to recognize that others will be using their own change management (formal or informal) for their own purposes during these changes. These efforts might not be working directly against your aims, but they aren’t inherently aligned either.

Sometimes this is purely political and selfish, but often it isn’t. You might have a team that wants to ensure the long-term aims of their efforts aren’t diluted through the change, and so they engage deliberately to preserve their strategy and momentum. I’ve sometimes helped continuous improvement teams adopt this very strategy. Again, this isn’t bad, but it is change management effort that convolutes your own aims. Be aware of this, seek out the conflicts, and welcome those who are showing up to work with intentionality.

Conclusion

Fundamentally, org design enables improvement but does not create it. This is why Marcia Blenko, Michael Mankins, and Paul Rogers, partners at Bain & Company, found in “The Decision-Driven Organization”⁸ that while nearly half of CEOs launch a reorg in their first two years, a study of 57 reorgs between 2000 and 2006 found fewer than one-third produced any meaningful improvement in performance, and some even destroyed value. Gary Neilson, Karla Martin, and Elizabeth Powers, then of Booz & Company, found in “The Secrets to Successful Strategy Execution”⁹, from a study of more than 125,000 employees, that when execution fails, the instinct is to redraw the chart and change the incentives, but those levers are less effective than clarifying decision rights and improving information flow. So whether you reorganize or not, you must get these things right.

Organizational design change is hard, plain and simple. It should be less frequent than many organizations make it, especially on a large scale. But if you’re going to pursue it (and there are very good and valid reasons why it should be pursued at the right time), do it well, do it fast, and do it thoughtfully.

Endnotes

1. O Morain, C., & Aykens, P. (2023, May 9). Employees are losing patience with change initiatives. Harvard Business Review. https://hbr.org/2023/05/employees-are-losing-patience-with-change-initiatives

2. Drucker, P. F. (1973). Management: Tasks, responsibilities, practices. Harper & Row.

3. Flinchbaugh, J. (2021). People solve problems: The power of every person, every day, every problem. JFlinch. https://www.jflinch.com/people-solve-problems/

4. McKinsey & Company. (2014). The secrets of successful organizational redesigns: McKinsey Global Survey results. https://www.mckinsey.com/capabilities/people-and-organizational-performance/our-insights/the-secrets-of-successful-organizational-redesigns-mckinsey-global-survey-results

5. Flinchbaugh, J. (n.d.). Moving from RACI to RACIC. JFlinch. https://www.jflinch.com/moving-from-raci-to-racic/

6. Gallup. (2021). Too many teams, too many bosses: Overcoming matrix madness. Gallup Workplace. https://www.gallup.com/workplace/354935/teams-bosses-overcoming-matrix-madness.aspx

7. McKinsey & Company. (2018, February 20). Reorganizing to capture maximum value quickly. https://www.mckinsey.com/capabilities/people-and-organizational-performance/our-insights/reorganizing-to-capture-maximum-value-quickly

8. Blenko, M. W., Mankins, M. C., & Rogers, P. (2010, June). The decision-driven organization. Harvard Business Review. https://hbr.org/2010/06/the-decision-driven-organization

9. Neilson, G. L., Martin, K. L., & Powers, E. (2008, June). The secrets to successful strategy execution. Harvard Business Review. https://hbr.org/2008/06/the-secrets-to-successful-strategy-execution