How can my dev team increase adoption for platform migrations?

This is The Lossless Leader, an advice column written by engineering manager Leemay Nassery.

Why call it The Lossless Leader? An engineering leader is someone who inspires their team, communicates well, grows their people to become leaders themselves, removes blockers or painful aspects of their team’s day-to-day, delivers on product requests and so much more. In tech, lossless compression is a technique that does not lose any data in the compression process; it reduces the size of files without losing any information in the file so quality is maintained.

Combining the two: Leaders aren’t perfect. Sometimes they manage to not lose any data while leading their org, and other times it may seem like they’re losing it altogether. This column is called The Lossless Leader because we all admire those leaders who strive to stay true to who they are and the people they serve (their team). They admit fault when necessary, learn from their mistakes, sometimes flourish in difficult situations — all while not losing themself along the way.

The question:

“Is there a way we could make migrations suck a little less? I work on a platform engineering team that’s building new infrastructure. The existing infrastructure is outdated, and has existed basically since the company was founded. We’re finding it hard to get on our product engineering team’s roadmap to actually migrate to the new infrastructure. It’s so hard getting commitment from teams to partake in the migration effort.”

The answer:

Uh, yeah, you said it well — most migrations really do suck. There’s always a cost to every migration, including time, energy, risk of touching old code created by someone who left the company five years ago. Unless it’s wickedly clear the value of the migration (which it usually is not), then it just feels like work we’d rather not lend our precious time toward.

To make it less painful, the way you start migration is key.

It’s like writing. If you start writing a book and your first page is just OK, it’s less likely you’ll get published. Your first page is your chance with the editor to get their attention, to get them to keep reading. If you write the first page and leave the best details in the second or third page, the editor may not get to the second page. It’s the cruel truth. The same can be applied to software migrations.

If we pretend the migration is similar to a novel, your first page should detail to your users why this is necessary. It’s like getting buy-in for any brilliant idea of yours: Start with the why. Why should they invest their time to migrate to the new infrastructure? If the answer to that question is “because we’re deprecating the current infrastructure” … then you need to think harder. Market your work in a way that appeals to your users. Are you reducing cost with this new infrastructure? Or are you improving the reliability of their software as a result of this new infrastructure? You have to be strategic in the way you present the migration to the world, or rather to your users.

Leemay Nassery. (Courtesy photo)

Once the reason for the migration is compelling to your users, think about how you are enabling the migration to happen. Do you have documentation so it’s super easy to do the migration? Have you identified teams that could be considered early adopters?

Similar to marketing a new product, you need movers and shakers that are your first users to opt in. These are the teams that are open to taking a chance on your new platform. Once you’ve identified those teams, serve them first. Consider loaning engineers to embed directly onto the team a successful migration. They can be your brand ambassadors — they’ll advocate and help with word of mouth.

With the early adopters, also consider getting their initial feedback. Were there aspects of the migration that were super painful? Could you build a tool or means for making it less painful? Is there boilerplate code you could provide that all teams can leverage, so there’s one less thing for them to do? If you deliver on these requests, they’ll keep coming back to you. It’s not easy, but it’s not impossible. Never underestimate the power of asking people’s opinion — you’ll learn and they’ll feel like you actually care about them as users of your platform.

###

Software engineering isn’t supposed to be a drag, yet we often make it drag. You can make migrations less painful and more interesting by making it clear why it’s important. Have data to support the why, and track that data. Use the data to motivate both your team and your users.  People will make time for work they benefit from. And if you’re finding that it’s very difficult to create such a narrative, maybe the migration shouldn’t happen in the first place.

As someone who has been on both sides, asking teams to migrate to a new platform and avoiding a migration at all costs, I get it. Migrations are TOUGH. You really have to have a compelling reason to get teams to do the migration (that is, if you’re not providing the consultation to services to do it for them).

Tracy Chapman said it best: ”Give me one reason” … to do this migration.