A lot of the reasons that change fails, inside & outside technical organizations, come down to one broad statement: the people who have to make the changes are humans, and the people who want them to make the changes have not successfully taken this into account.
Before we proceed: Changing a software development process is kind of a sideshow to me right now. Changing the world out on the streets is the real story.
Black lives matter. Please go make real change, and stay safe, stay strong, stay angry, and stay kind.
People ask me why the change they’re trying to make doesn’t happen. The questions come from all levels of an org, from the very top to the very bottom. "Why won’t they change?" It’s often accompanied by an implicit theory. It’s often aimed at me because I have had some success.
I should say: being a successful change-enabler doesn’t mean batting 1.000 anymore than being a successful batter does. .300 is damned good. It means one fails 70% of the time. Making sticky change looks a lot easier than it is, especially when the looker ignores humanness.
Here’s the thing: whatever brilliant new arrangement I have in mind, I am very rarely the one who’s going to have to make it. (Sometimes, I’m one of the ones who’ll have to make it, but that’s not quite the same thing.)
Who makes it? The humans do.
Because the humans have to make any actual change — and for it to be sticky, to hold the actual change over time — the first thing a would-be change-enabler like me has to take into account: who will be making the change?
I center my approach around this question, "who’s got to change to make this change happen?" The answers for me are usually a mixture of very general ideas about humans and very specific ideas about these particular humans or even this particular human.
In what follows, I’ll speak mostly of the generic human, but ya gotta be careful with this idea: there is no such thing as an average human. It’s an abstraction that we can use, but like most things we find in Plato-town, we need to always press the ideal against the real.
Humans like change when it is taken from inside their lived experience, not given from outside that lived experience. This manifests in several different ways, and when we ignore it, we put our change at immediate risk.
The classic violation of "inside lived experience": a change is given to you by your great-grand-boss, who doesn’t know you or your workgroup, and certainly doesn’t know what your lived work experience is like.
A second violation of "inside lived experience": a change is given to you that fixes a problem that neither you nor those in your relationship horizon feel you have.
Humans like changes that improve their own lives or the lives of people they know and love. If your proposed change doesn’t do this, or — see below — if they don’t feel it will do this, they won’t get acted on.
Humans like changes when they have experienced those changes, much more so than when they’ve only heard the reasoning behind them. Failed change often begins with two features: 1) a verbal description of the change, 2) a verbal description of the reasoning behind it.
This surprises a lot of would-be change-makers. They think the verbal description is enough and the reasoning is enough. But most grown-ups get to be grown-ups by knowing the difference between theory and practice, and how many great-sounding theories are lousy practice.
My slogan here is "Create experiences, not arguments". It’s an attempt to get at the enormous persuasive power of doing something instead of talking about it.
Can I do a lab? Can I run an experiment? Can I set a timebox? Can I do it with them? Can I do something like the change that isn’t really the change but shows off how the change might feel? These are the kinds of questions I use to focus my proposals.
Humans like small changes more than big ones. Every change creates uncertainty and discomfort. If we change too much at one time, that uncertainty and discomfort can overwhelm us.
When a change is a "tweak" or an "adjustment", the main body of my behavior and attitude, which stays mostly the same, serves as a kind of critical comfort mass.
So this list of generic human attributes around change, well, let me tell you, it makes change a very hard problem, and it applies brutal constraints to the would-be change-enabler’s approach.
That’s why so many folks struggle at initiating successful sticky change: it means balancing so many factors at once.
The problem is the difficulty of finding a route to your vision that proceeds in steps, where each step is either same-or-better, where each step pays back the changer or her coterie quickly, where each step is richly informed by that coterie’s lived experience.
I have a very unusual definition for what I do as a coach. I’ve been offering it around for years, and I’ve never had anyone else endorse it. But I trot it out at times like these.
“As a coach, what I do is create or exploit openings through which individuals, including sometimes myself, can take steps that move them closer to who or how they wish to be or do.”
It is, literally, the only definition I’ve ever found that seems to live entirely inside the human features I’ve described above.
Notice two things about it: 1) It doesn’t mention any of the usual targets one hears from a coach. No "Agile". No "process". No system. 2) It’s a very modest target, promising seemingly very little.
In spite of both of those odd aspects, I’m a surprisingly successful coach. I don’t really know my batting average. whether I really "bat .300", but I bat well enough that I’ve been chosen and paid to do this for two decades.
Supporting The PawCast
If you love the GeePaw Podcast, consider a monthly donation to help keep the content flowing. Support GeePaw Here.