Here’s another technique card from my seminar, “Leading Technical Change”.
We first get into midwifing change precisely because we want it to be smoother, easier, and faster. But sometimes, a coach needs not to rush a decision through, but to slow it down.
It’s so exciting when our proposed change starts to catch fire, especially when major influencers in our team suddenly “get it”, and want the whole team doing it.
“Winning.”
And it is winning. But when you start to win like this, in parts, you can lose in the whole.
People who’ve taken your idea to heart want to close the deal. But if the deal is closed too early, by a premature decision, or a formal order, that’s very likely to create temporary surface change, not lasting deep change. And it can trigger very deep hidden resistance, too.
That means we might want to slow decision-making, especially command or rule decision-making, way way down.
The card mentions four techniques, and there are certainly others, for matching the pace of the decisions to the pace of the team.
When an experiment has gone very well for most of your team, but not for everyone, or for the boss, but not the team, instead of proposing that we go from experiment to decision, suggest we go from experiment to experiment.
This is particularly valuable in a situation where the experiment was a success, but we still have folks in the room who were unhappy with some of the details. We can tweak the details, and try it again. Sometimes, whether the tweak works or not, the tweaking itself converts!
Second, it’s important to resist almost any attempt to force people to adopt your change.
And to resist it openly and cheerfully. Tell the bosses explicitly what you think is best for the team. Tell them that in front of the team, even.
As soon as you position your change as “required”, you dramatically increase the likelihood that it will be chiefly honored in the breach.
(Any TDD-er who’s ever seen how quickly a coverage metric requirement can ruin a codebase knows exactly what I’m talking about here.)
Third, consider, instead, whether there’s a way to maintain side-by-side practices for a while.
If there’s a way to do it using practice A and practice B, and keeping both practices up, we give people a much better opportunity to see how they feel about both of them.
This can be hard at the process level, but is comparatively easy at the code level. The point isn’t that it can always be done, the point is that we have to ask ourselves if there’s a way to do it. Ask the team, for that matter!
Fourth, it’s okay to be explicit.
Look, if everyone on the team genuinely prefers your new practice, you don’t need a rule or a decision to make that happen. The deal doesn’t close when the rule happens, the deal closes when we’re all doing the new practice.
Not only will a team use a practice they all feel good about, but they’ll also onboard members to use that same practice. You don’t need a handbook of official practices, you need socialization.
When your team first gets excited about a practice, that’s just the most thrilling thing. It is, after all, exactly what we wanted.
But don’t let that excitement and enthusiasm ruin a perfectly good change by making it too concrete too soon.
Know when to slow down decisions.
Does the GeePaw Blogcast add value?
If so, consider a monthly donation to help keep the content flowing. You can also subscribe for free to get weekly posts sent straight to your inbox. And to get more involved in the conversation, jump into the Camerata and start talking to other like-minded Change-Harvesters today.