There’s an old joke about a visitor stopping somewhere rural and asking for directions. “Ach”, says the local, “if I was going there, I wouldn’t start from here!”.
So much of the time, we have a vision for where we’d like our technology to be, but it sure would be nice to not start from where we are. Whether we’re adding support for IPv6, deprecating Sensu, introducing a DevOps culture or moving to microservices, we’ve got the same problem ahead of us: how can we make enough people care?
We’re all busy. Every team has work they’ve already planned to do this year, pressure from their customers to deliver new features. For all that they’d like to help with your big change, they’ve got their own problems, and those are higher priority. What can we do?
Start out by measuring the thing you need to change. What are your metrics here? If you’re deprecating something, maybe it’s the number of call sites to the thing, or the number of services still using it. If you’re adding something, maybe you care about the number of teams who have moved to using it. Decide in advance how you’ll measure the success of this project.
You need a narrative. Tell the story of your change. Before you go out to convince people who may be hostile to the idea, hone your elevator pitch on people who are on your side. Try framing it in different ways. “Did you care a bit more that time?”. Appeal to a noble vision, to how it is good for everyone. This is also a good time to make sure you know exactly why you’re making the change. If it boils down to “this technology is cool” or “this is good for my career”, it’s time to admit that to yourself and stop.
Make it really easy to do the change. The more time you put into this, the less time every other team will need to. Document it carefully and beautifully. If it’s a code change, provide some clear worked examples for each of the major use cases. If it’s a cultural change, try to make it so people don’t need to memorize anything. If it’s some configs to set up, can you give them a script to do the work? Make it really easy for them to see whether they’ve been successful.
Get some early adopters who already like you. Have them try out your super-easy process for making the change. You want them to be happy at the end; they’ll tell other people it wasn’t difficult, and that’s the kind of good press you’ll need.
Stop the problem from getting worse. Search for any documentation, processes or code that would encourage people to start doing things the old way. If you’re deprecating something, first discourage new uses of it, then block it. If you’re pushing for adoption of something new, get it into checklists, launch readiness reviews, onboarding documetns, wherever it makes sense. You want anyone working in this area to make this change without you having to ask them to do it.
Communicate the change! Have a document or website with a catchy name that’s very easy to find. Have a deadline. Get on every stage you can and say the catchy name. If you have lots of offices, do a world tour! Get on posters. Get in MOTDs. Ask for shout outs from people who have a platform. “Hey, I see you’re speaking at the all hands about upcoming changes; do you think you could mention that this big change is coming? Communication will continue for a long time; you can start mentioning this even before you have early adopters, but you’ll want to keep repeating it throughout this whole process.
Now on to converting all of those existing users! Can you give people something for free? Carrots are better than sticks. If you solve a real problem (and it’s easy), people will voluntarily make the change. Say thank you to the early adopters. Get testimonials from them and put them on your website with the catchy name.
Now it’s getting tricky. Do you have a high-level sponsor who can be convinced to put this on yearly objectives? The people who aren’t excited early adopters are looking to their leadership to see if they really need to care about your thing. If you have the opportunity to appeal to authority, use it!
Don’t lose focus! Don’t get bored! Send gentle reminders at intervals. Get it into people’s brains. A lot of migrations fizzle out half way through. Make it clear that you still care about this.
As you’re getting near the end, less gentle reminders. Make the thing you’re replacing harder to use. Can you start introducing artificial slowness? Can you turn it off at intervals? If there are new features, can you only add them to the new thing and not the old thing? People will now start hating you, so ideally there aren’t many people left when you get to here. But you gotta do what you gotta do or the migration will never. ever. end.
There will be holdouts. They’re too busy, they love the old thing, whatever. Can you make the change for them? If they’re really unwilling, can you tell them they’re now the sole supporters and owners of the old way, and you wish them godspeed
It’s done. Ice cream party! Don’t go quiet now. Mark the end of the project and make sure people see that the work they did was worthwhile. Celebrate it as an organisation-wide or company-wide achievement. Getting everyone to do the same thing isn’t easy. Make everyone feel like they were part of this great success.
Final note: a change like this is a project. There’s a ton of work involved in making people change their minds. I think a lot of migrations fail because we assume that it’s “free”, or that it’s done when the engineering work is done to make the change available. “We made this technology! Everyone will come get it now, right?”.
They probably won’t! It takes a lot of time and dedicated effort to make everyone behave in a different way. Expect to spend a lot of engineer time on marketing and you are less likely to be another story of a migration that only got half way through. You can get there from here, but only if you keep moving :-)