Coach Tony

May 13, 2016

In organizational design, you’re often faced with the challenge of getting a group of people who think they’re good at their jobs to change how they work. This is always hard. That’s why people study it.

The fundamental mistake is that you ask people to change and then don’t take any further action. That’s wish-based management. That doesn’t work.

The fundamental solution is a concept called “Change Elements.”

(All credit to Jonathan Rosenfeld, my executive coach for many years and one of the elites in the coaching field. He introduced this concept to me and it’s been a staple in my practice ever since.)

Here’s how it works.

What’s going on when you ask your team or company to change? Your team has a status quo that they will always return to unless something blocks them. This is human nature.

Let me explain it with a graph and a big word: homeostasis.

In human biology, there’s a concept of homeostasis that means:

A system in which variables are regulated so that internal conditions remain stable and relatively constant.

Companies have a similar concept that pushes toward stability. When you make a request for your team to change, you are introducing an instability. The organization will resist your change in order to return to the previously stable status quo. We call this organizational homeostasis.

If you’re a manager, you’ve had this happen and it’s frustrated you.

Here’s how you can visualize this pattern. On a day-to-day basis, your team performs a little above or a little below the status quo. Maybe they are tired, maybe they are inspired. But generally they do close to the same work every day.

Then one day you have an idea that’s going to improve performance for your entire group. You prepare your best PowerPoint presentation and demand that everyone on the team make the change. The dotted line below is your new performance goal.

The problem is organizational homeostasis. There’s nothing keeping your team up at the new level. If you have authority, you can get your team to try anything. But you can’t get them to keep doing it.

Most often, your team is going to fail and plummet below the old status quo. Think about all the re-orgs and crazy management ideas you’ve been subjected to. It’s demoralizing. Not only does the change fail to improve the team, it also produces a temporary crash.

So, here’s where change elements come in. If you want your team to stay at the new dotted line, you need to hold them up there. Think of change elements as pillars supporting the new level.

Now, you’re probably thinking that this seems obvious. That’s the power of the Change Element concept. Of course, you have to build support for any change you want to make.

When I work with a company to make a change, I always introduce this model. That’s because every person and every company suffers from the delusion of wish-based management. You can’t just wish for a change and then have that change magically happen.

In all fairness, I’ve inflicted many rounds of wish-based management on my teams. Management is hard — and remembering to design change elements is the most powerful concept in my arsenal.

Let me end with a simple and true example.

This story has some software engineering terms, but you don’t need to understand them to get the gist.

We were working with a manager who wanted his software developers to work faster. He didn’t think they were bad developers. But he did feel like working faster would allow the company to get faster feedback from customers.

If you’ve ever read The Lean Startup, this is the essential tension of product development. A high quality product development team will often optimize for craftsmanship over learning. But most often, the only way to learn what customers want is to rapidly build and adjust.

That’s all just to say that this manager wanted to be much more aggressive about putting changes in front of customers.

So, as a step one, he asked the developers to make changes faster by making smaller changes. And the developers tried. But all of their habits were around working in big multi-month iterations. So they weren’t very successful.

That’s where change elements come in.

We worked with this manager and his team to introduce two change elements.

The first change element put in place a continuous deployment system. In this system, every time a developer made code changes those code changes were immediately and automatically pushed to customers.

Since software developers make code changes nearly every day, this sounds like it could be very dangerous. In reality, with a few habit changes studies say this counterintuitively results in faster development with fewer bugs.

Of course, there’s no guarantee that developers will respond with the right habit changes. They might respond by simply making fewer changes.

So we introduced a second change element which was to make work increments very visible. The team already hung out in a Slack chat room. In this change element, every time someone completed a task, the whole team would see an automatic notification in their chat room. This ended up being a cultural change element: not completing tasks looks like you didn’t show up to work.

Now, here it’s very, very important to make one point about sharing the concept of change elements with the whole team.

These developers were not moronic black boxes that can be manipulated through process changes. They were brought into and bought into the entire change process. They learned the Change Element concept before making these changes. Then they helped design and implement the change elements.

Bad managers will miss this last point — and I don’t want you to be a bad manager.