A long time ago, in a galaxy far, far away…
I was visiting a client over the course of a 12-18-month period for some agile coaching when I discovered an interesting pattern. It seemed as if every quarter (3-4 months) or so they would reorganize their organization. Sometimes it was an overhaul reorg, with a massive shift for most folks. And other times, it was just a fine-tuning reorg, affecting only a small percentage. But on aggregate, it seemed as if everyone would get a “new boss” at least once a year.
Of course, there were different reasons for each reorg. Here are some of the drivers that were mentioned in passing—
We need to shift from a Project-based organization to more of a Product-based one.
We lack accountability and ownership within our teams. We’re going to shift management around and declare a “Team Lead” for each team.
We’re adopting LeSS (or Spotify, or fill in your agile scaling framework), which recommends flattening management layers within the organization.
We just merged with/we acquired by (Company x) and we need to aggregate our two groups into one unified team.
We’re simply not getting enough done. We wonder if a reorg will help? Shaking things up a bit if you will.
Now that we’ve “gone Agile” we have far too many of this “role” and need to flatten things out a bit.
We’re not happy with the results from the last reorg. Things are still not getting done and we want to further streamline the organization.
Change happens. Shift happens. So, get over it.
All of which gives you a flavor for the very typical rationale for reorgs that I’ve seen across my 20 years of coaching experience.
Sidebar
And my reorg experience hasn’t always been from an outside perspective. I’ve been part of several organizations that fell into this pattern. And yes, I myself have been the Reorg-inator on a few occasions.
As a leader, I found it enticing to think that I could solve all of my organizational ills (and world hunger while I was at it) by simply changing the structure of the organization, the roles, and the responsibilities.
But the sad truth was/is, that it never really optimized the organization.
What I’ve found that does that is—hiring great people, providing a clear and compelling vision & mission, then getting out of their way while providing support.
In other words, culture seems to eat org structure for breakfast…
Now I want to explore three common challenges that reorgs create.
Creating More Roles
One major problem with reorgs is that they often lead to creating additional roles, which usually adds complexity.
Most organizations that are going through an agile transformation are suffering from an illness I’ll refer to as role confusion by default. So, getting into a continuous reorganization pattern really exacerbates the confusion.
SAFe is one of the largest instigators of additional roles in agile contexts, so I pick on them a bit in this post on role confusion. I encourage you to read it as it adds to this discussion. But SAFe isn’t the only culprit, rolling out scaling frameworks and, scaling in general, often generates many roles.
My point in bringing it up here is to avoid it whenever possible. And to consider, if you do reorg, your responsibility in providing role clarity throughout the new organization. Not by PowerPoint, but by individually helping folks reframe from their old-role to their new-roles.
And realizing that this takes time and patience!
“Rolling Out” the Reorg
Often the reorg is in the eyes of senior management. That is, there is very little involvement by the teams that are being reorged.
The leadership team finds (exposes, creates, initiates, imagines, etc.) a set of drivers (problems, challenges, dysfunctions, etc.) leading to the reorganization. Then they usually spend an inordinate amount of time problem-solving and creating the new organization. The conversations are often people and capability based. That is, by moving things around, it will change the system dynamics enough to potentially solve the problem.
Once they have a “workable” reorg, then there is planning to “roll it out” across the organization to achieve some sort of “buy-in”. This usually involves PowerPoint slides and meetings wrapped around communicating the change.
I think of this language, that of “rolling something out” as inherently problematic. If the leadership team had been inclusive of the organization and would have co-created any changes with the teams, then there would be little/no need to “roll it out”.
And certainly, the teams would have more clarity and ownership as a result.
Change Fatigue
As an agile coach, even though I’m not a direct recipient of the reorg, I experience the impact of each. Essentially, if you are aware of the Satir Change Model, the organization was nearly always in resistance and chaos in the valley of the change curve. What folks sometimes call the danger zone of the model.
And what is even more concerning, I found that just when they might be moving to integrate the reorg, guess what happened?
You guessed it. Another reorg!
So, the organizations never actually integrate the change towards a new status quo state. Instead, they’re stuck in the valley in a near continuous state of change. This leads to enormous change fatigue that extends the resistance and chaos phases.
Sounds horrible, right? Well, it is.
Breaking the Cycle
How do we break this cycle? I can think of a couple of ideas to start with—
Engage your teams in the process—This starts with asking them if THEY see the need to reorg? And if they see it as solving the problem(s) you see. Be prepared that they won’t see it and that they might even identify you (leadership) as part of the “problem. But if you must reorg, engage them in the envisioning and solutioning.
Do it less frequently—This embraces the Satir Change Model and the realization that, in order to effectively change, you need to navigate to a New Status Quo before introducing yet another change. Today’s effective leaders need to be aware of the “tempo of change” that can effectively be navigated by themselves and their organizations.
Realize that going Agile is, in itself, another change—We need to realize that all of our other changes meld with reorg change. So, amplifying #2, we need to be super-cognizant of our rate of introducing change into our organizational systems.
Change the culture instead—Instead of focusing so much on structurally solving problems, I wish leaders spent the majority of their time establishing and reinforcing a healthy culture for their teams. I call this activity Culture-Shaping, and to me, it’s a much more effective way to create system improvement and change. Not by structural problem-solving, but by establishing an ecosystem that empowers all members to be successful. Including your clients/stakeholders.
Get organizational coaching help—One of the things I observed is that leadership teams often go through a reorg phase on their own. Using their instincts, experience, and whatever tools they’ve historically used. But in today’s complex organizational cultures, that may not be enough. I’d encourage you to find “another set of eyes” and “a partner” to assist you in your reorgs. And that starts from the very beginning, which is determining the actual need for it.
And these ideas aren’t intended to be exhaustive. In fact, I’d encourage you to self-reflect and retrospect on your own organization and its patterns of historical change. Then, if you find some mistakes (and you will) perhaps learn from them and adjust.
Sidebar
But there is certainly another take on it.
I asked a trusted colleague to review this article. And he is in the midst of fine-tuning a rather large-scale organization as it makes its way to agile-focused execution.
He has encountered an org structure that is not conducive to where they need to be and is considering some very austere org changes to optimize things. He made the case that there are times when you have to “clean house”.
And I understand and somewhat agree with him. I am NOT saying that organizational change is inherently bad. In fact, it’s probably a part of organic growth and natural evolution. But what I am saying is that:
FREQUENT organizational change doesn’t allow for stabilization;
Be inclusive when you do reorg;
Remain thoughtful throughout the process.
And be patient, trusting that your teams will deliver results.
Wrapping Up
This article was somewhat inspired by this Steve Denning article. Now Steve takes the path from reorg’s to networked (flattened) organizations. I, on the other hand, focused mostly on the dysfunctional nature and suggesting some ways to avoid the Groundhog Day trap.
If you’re not sure whether you’ve fallen into the reorg abyss, I’d challenge you to count the number of reorgs you’ve had over the past 18 months in your organization. If you’ve had—
None: then I applaud you;
1-2: then perhaps you’re effectively managing organic change;
3-4: then you’re in for a rough ride on the Space Mountain coaster;
5+: then you’ve fallen into the abyss of continuous change fatigue.
Sure, change happens and agile is supposed to be good at engaging change. But that being said, how tired is your organization of reorg change?
Stay agile my friends,
Bob.