Adoption of New Tools and Processes
Management
Have you ever felt frustrated that a process or tool you rolled out didn’t get adopted? I surely have. I’d ask myself why the heck the team wasn’t doing that thing I asked them to do and made so much work for.
I’m fortunate to have had many examples to learn from, like trying to increase adherence to defect SLOs, usage of APM tools, delegation in on-call rotations, and meeting participation. As a first-line manager, I’ve rolled out numerous tools and policies. Some of them were badly received and poorly adopted. Later, as manager of managers and part of Product Engineering Leadership at Splash, I’ve needed to understand the Engineering organization as a whole, observing, measuring, and iterating continuously. Similarly, some of the changes I led didn’t land well. What was I doing wrong?
Some times it was lack of understanding the root cause. Other times it was not looping the right stakeholders from the beginning. Regardless of the reason, what helped me learn and do better next time was my mindset.
The mindset
The attitude of blaming others for lack of adoption is unproductive. It’s like communication: one has to feel responsible for 100% of it in order to be successful. That mindset makes us think more critically. What could I do differently to achieve better results? What am I not aware of that’s causing friction to adopt this change?
For example, it’s ineffective to just write down instructions and send an email, assuming people will comply. That’s just a great way to become a leader that asks for seemingly random things. The team will get used to receiving those orders, complying with them for a bit, if at all, and dropping them later. They’ll think, probably they weren’t that important in the first place.
My tips
With the mindset of being fully responsible for the (lack of) adoption of a change, these are the tips that help me:
Ask myself if what I’m trying to do is worth it, and if this is the right time.
If it needs an explanation, I write a change rollout document.
I try to explain clearly the Why. What’s the ultimate goal we’re trying to achieve? What problem are we solving? It isn’t straightforward to identify and articulate the actual reason for a change to a new tool or process. In that process of writing it down, I sometimes realize there’s a better approach to solve the problem.
Getting buy-in from the relevant stakeholders, listen to their feedback and incorporate it early on.
Check individually with a few for their thoughts early, particularly those that want to be listened to.
Informing of the change in multiple channels (email, meetings, chats, etc.).
Creating ways to easily measure adoption, like dashboards, and being transparent about the fact that I’ll be using them.
Evaluating adoption later, by setting myself reminders to check it.
When I see lower adoption than expected, or lower success to fulfill the goal, I ask many questions to understand what I’m not seeing.
My advice to fellow managers is, when adoption isn’t as good as expected, to avoid blaming others for being irresponsible or bad listeners. Take ownership of the lack of adoption! What’s not working out? Was the Why not clear? Are people in your organization not used to reading written communications? Was this just the wrong time due to other factors? Has your change not hooked up to their pre-existing routines?
Culture
Iterating is easier when it’s part of the company culture. Rolling out new processes and tools easier when it’s frequent and adhering to them is the norm. The more individuals expect adherence from each other, the stronger it will be. A culture that embraces asynchronous collaboration, via RFCs or change rollout documents, has a huge advantage to make iterations coming from management feel less chaotic.
To foster this culture, I’m very transparent with my team about how I roll out changes, and encourage them to be with their team. I continually ask them for feedback. And after having experiences some pitfalls with adoption, I try to listen more than act, so the things I roll out are helpful to the organization from the point of view of others, not just mine.
Conclusion
Own the adoption results fully. Make others accountable, but you’re responsible for the results.
Shout outs
During this year, I’ve seen great adoption to so. Some of them I list here
To Charlie Irwin, QA Engineering Manager at Splash, for owning and rolling out processes, tools, and metrics to understand and improve quality at Splash.
To Paul Schooss, Infrastructure Engineering Manager at Splash, for coordinating the creation of documentation, runbooks and live workshops to educate Splash Engineering on our new Kubernetes infrastructure.