by Jason Little

I saw a notification popup in my twitter feed a couple of weeks ago:

Naturally, I wanted to see what it was that I was supposed to say something about!

 So what do I think about that? Read on!

Yesterday I chatted with someone at a large bank that employs ~30K people and she was interested in my Lean Change Workshop, along with help getting a large digital and agile transformation off the ground, on the right foot.

She asked me about my background, and to give her the reader’s digest version of Lean Change Management. I described how today’s organizations don’t have the luxury of spending six months creating the perfect change plan anymore. The difference with Lean Change Management, in the context of these massive transformations, is to rely on emergence first. That is, start doing with minimal planning because early-on you have no idea how the change is going to be received. Odds are you’re not even sure where you want to go until you try something.

I went on to describe how it’s difficult for traditional change methods/frameworks/models to be used in times of extreme uncertainty, but before I could finish the thought, she interrupted me:

“Jason….they just don’t work!! You’re being sooooo polite! I’ve been in the change industry for 20 years…these old approaches just don’t work!”

She’s right.

On both counts. 😎

Change Management is dead.

At least it’s true for the old, tried and true, plan-driven approaches that focus on executing change activities, over facilitating meaningful change.

In the traditional sense, managing change is more about managing the budget that’s been handed out to run the change program, and managing the checking of boxes on the status report. It’s not the sole fault of the change agent, after all, who’s paying their salary? Change management has to be accounted for on someone’s balance sheet, and that’s where change managers get stuck. They get stuck project managing activities. In fact, I don’t know how many times I read tweets, articles and discussions online about “why it’s time change management and project management merge!!” like it’s some type of epiphany.

If Change Management is Dead, How Do We Help Organizations Change?

Well, the Agile answer is to get all cutesy and say things like: “we need to get people to develop the agile mindset! We need to be agile, not do agile! We need to embrace uncertainty! Cynefin says complex systems…blah blah blah”. Am I cynical? Yes. Try walking into the CFO’s office of an 80,000 person bank, and tell him/her that they need to just be more agile with their balance sheet. See how long it takes before you get tossed out.

First of all, organizations don’t change. People in organizations try something differently and then a movement is either created, or it isn’t. When that movement happens, it tends to evolve the way that it evolves. In the 1930s American sociologist Herbert Blumer described how social change happens and over the coming decades, his work inspired a number of people who shaped his ideas into these stages:

Emergence: Someone is unhappy with the status quo and does something. There is little to no organization, and a pockets of “doers” emerge who disrupt the status quo.

Coalescence: Small successes happen, and in the context of Agile transformation, “unofficial Agile people” emerge. Some internal “unofficial” meetups may happen and a little more structure emerges in the organizational network. A shared purpose, or goals start to develop.

Bureaucratization: The Eye of Sauron is upon thee! At this point, someone high enough in the organization notices people are colouring outside the lines and they either support it, put a stop to it, or formalize it into the hierarchy. This may be the point when a VP of Agile/Innovation is hired.

I’ve seen this pattern numerous times. Once I was fired as a coach when a new VP started and saw our Scrum Master meetup signs in the building. She put a stop to that because there were no Scrum Masters in the org chart and we were fired shortly after that.

That leads to decline. Decline is trickier and the movement can tumble down a few different paths:

Repression: The movement is killed by authority. This can happen when a new leader is brought on, or when your Agile movement pisses off someone high enough in the organization who should have known about it, but didn’t.

Failure: I’d argue outright failure of the movement happens when the innovators quit and move on to another organization.

Co-Optation: Agile becomes institutionalized according to the old values of the organization. That is, it becomes just another department with another set of ‘best practices’ that are forced through the organization. If your organization has a VP of Agile, or something similar, you’ve gone down this path.

Success: It worked! Well, it may not have been a successful transformation, but something worked. It could be as simple as helping an organization adopt 10 practices and only two stuck. That’s a win in my books, but probably one of those 70% failures that receive so much attention in the change world.

Obviously there’s much more to it, but in larger organizations, the problem becomes that many Agile movements are happening at the same time…and each one of them are at different stages.

I worked with a large organization where one group had been experimenting with agile for a year before the rest of the organization woke up. The challenge was managing the friction between this group and another group.

While the group that started early was already in coalescence, the other group was in emergence. To someone outside of these groups, it looks like chaos. That chaos is what leads to the feeling that these Agile people have gone rogue. If the organization prides itself on hierarchy and structure, this is where repression or co-optation happens. The movement is killed, or the organization hires a VP of Agile and applies the same organizational design, and thinking, to making Agile work.

Our work as change agents happens in the cracks and crevices where groups intersect.

You cannot manage this type of change. If you’re moving a printer, sure, you can plan that using a traditional framework:

• Make people aware that the printer is moving
• Make sure they still have the desire to print
• Make sure they know where the new printer is
• Make sure the new printer driver is installed
• Put a sign up where the old printer was that reinforces where the new printer is

If you know what that framework is, I hope you get a chuckle out of it!

Agile transformation, or any digital transformation, re-organization and more, is social change and that cannot be managed.

Now that I’ve proven why change management is dead, how can we help people in organizations navigate the gigantic hairball that is organizational change? Here are nine change management isms that are more well-suited for today’s world of disruption and rapid change:

Co-Creation of Change over Getting Buy-in: If you need to get buy-in, you’re in decline already. Even if you’ve been asked to create a new Agile risk process that affects 400 people, go talk to those 400 people. No, I’m not joking.

Cause and Purpose over Urgency: Answer the “what’s in it for me” question for everyone who’s affected. If your organization is already the gorilla in your space, sustainable business isn’t the point…a higher purpose must be.

Informal Networks over Comms Plans: Ignite the rumour mill, use signs in high-traffic areas, go where people communicate already. It’s quite likely that no one is reading your SharePoint site, or your newsletters.

Big Visible Walls over Status Reporting: Visualize your change work on a wall, invite stakeholders to meet in front of it for 15-minutes each week to discuss risks.

Diagnostics over Change ROI/Metrics: ROI for transformational change does not exist. If you spend $1M on an Agile transformation program, there is more effort spent trying to correlate outcomes to the change program. Instead, create short feedback loops at staff, management and executive level to see if you’re headed in the right direction.

Delegation Poker over Explicit Roles and Responsibilities: During emergence, find the movers. That is, find the people who are passionate about the change and enlist them into the change agent network. Use Delegation Poker to establish boundaries.

Avoiding Resistance over Overcoming Resistance: People don’t resist change. When there’s a need, people change. It’s unskilled change agents that create resistance by forcing rules and process on people that have to live with the consequence of those rules and processes.

Run Experiments over Managing Change Activities:  We know we need to answer the ‘why’ question, we know we need communication, and leadership support. Stop peddling easy answers, create hypotheses, make them visible and bring the outcome of the experiments to the decision makers.

Department Tax over Change Project Budgeting: Two things kill your transformation. A budget and a schedule. Create a 1% tax that each of your departments pay that will pay for your change agents.

Change Management might be dead, but the work of change agents is very much alive.

Image credit: Logo Dead by Deehellvetia