All right, thank you all for sticking around until the very end. I also want to thank CA Technologies for my new Amazon Echo. I'm super excited about that—I never win anything, so this is great!
A little about me and my background. As Evan mentioned, I have one foot in the Agile world and one foot in the change management world. Sometimes, that can lead to some interesting conflicts.
The Problem with Reorgs
Last year, I was working with an organization going through an Agile transformation. The executives were all at a town hall, and one of them mentioned to me, “We need to reorg because of Agile.”
The Agile practitioner in me thought, Yes, check. That is technically correct. At some point, you must reorg; otherwise, how can you be Agile at a transformational level? However, the change management side of me needed a stiff drink—because that is a great way to make everyone afraid of Agile. That is the opposite of what we want.
In this case, many employees had no idea what Agile was, making the statement even more confusing. Additionally, the executive team itself wasn’t aligned on what they wanted from an Agile adoption in the first place. Overall, it was not an ideal situation—plenty of wine was needed!
This experience got me thinking: What is it about reorgs that instills fear in so many people? For me, this quote really captures it:
“The effects are confusion, inefficiency, and demoralization.”
There are many reasons why a reorg might happen, with Agile transformation being just one of them. The problem is that most of us have experienced a bad reorg at some point in our careers.
Why Avoiding a Reorg Won’t Work
Some leaders say, “Why don’t we just not reorg? Then we don’t have to deal with this problem.”
How has that worked for those of you who have tried it? Not very well, right?
If you have functional silos in your organization, Agile is a non-starter. You simply cannot be Agile while maintaining rigid structures. There’s a concept I call the “organizational mullet”—business hierarchy at the top, Scrum party at the bottom. It’s not effective, yet we see it often.
If you don’t reorg, here’s what happens:
- Your structure remains top-heavy.
- Your teams may not be cross-functional.
- Employees will notice that leadership isn’t truly embracing Agile, undermining trust.
Ultimately, avoiding a reorg is simply avoiding change—and you won’t be Agile.
The Cost of a Bad Reorg
From an executive’s perspective, there is a significant cost to reorging badly. Poorly executed reorgs:
- Make employees fearful of Agile.
- Can derail an entire Agile transformation.
- May lead to valuable employees leaving.
- Cause unnecessary rework, negating any intended benefits.
This is why reorgs are so scary. But there is a right way to do them.
The Network Effect of Organizational Change
Half of the presenters here have probably shown some variation of a network diagram—this one is mine. Roles, processes, and team sizes all work together. If you ignore one of these elements, like structure, it will limit your success.
Organizational changes create network effects. For example, processes often mirror organizational silos. So, if you change the structure, you must also change the processes. These elements are interconnected.
The People Side of Reorgs
We all love the Agile mindset—that’s why we’re here. But Agile transformations cause real pain and loss for some individuals.
I worked with a project manager who loved his job and was good at it. After the reorg, there was no place for him in the organization. That’s a tough reality. Another example: The number one reason employees leave is their manager. If, as part of a reorg, someone ends up with a poor manager, they may choose to leave.
It’s condescending to tell people that “Agile is great” when they’re facing job uncertainty. Instead, we should listen to them, show empathy, and support them through the transition.
Understanding Change and Loss
Many of you have seen the Kübler-Ross model of change. While useful, it’s flawed because it’s linear. It suggests that the goal is to reach acceptance as quickly as possible. But in Agile, who is ever done changing?
A better perspective comes from Pauline Boss’s Ambiguous Loss concept. She argues that closure is an illusion. People must learn to live with uncertainty. This applies to work as well—continuous change means employees must develop resilience.
Techniques for Managing Reorg Transitions
Here are three techniques I’ve used to help people manage reorgs:
1. Set the Right Expectations
Executives need to communicate a clear vision for Agile transformation. Agile is not the goal—it’s the means to achieve business goals, such as:
- Faster release cycles
- Empowered teams
- Improved customer value
If you try to do everything at once, you will cause change fatigue.
2. Involve Employees in the Reorg
A reorg should be treated like an Agile approach—employees are your customers. Three effective techniques:
- Large-Group Design Charrette: A 50-60 person workshop to define organizational functional models.
- Change Network: Creating a group of influential employees to gather feedback and build trust.
- Dispute Resolution: Providing structured spaces (e.g., weekly coffee chats) for resolving conflicts.
3. Build Resilience Through Storytelling
There are two effective storytelling methods:
- Leadership Storytelling: Leaders share what they’ve learned from the reorg process.
- Employee Storytelling: Employees reflect on their transition experience, fostering empathy.
Final Thoughts
We spend a third of our lives at work. Our workplaces are communities, and during tough transitions, we need to rely on each other.
Agile transformations and reorgs don’t have to be scary. With clear communication, meaningful involvement, and a focus on resilience, organizations can navigate change effectively—without fear.
Thank you.