How to convince my engineering org to participate in large-scale migration?
Context:
(1) My team owns a service for which we're rolling out a new version with a big revamp of all the public interfaces and a ton of breaking changes.
(2) This is a legacy system that is being refactored to resolve some severe issues that its consumer systems have been complaining about for a long time.
(3) This service has many consumers in our org across multiple teams that depend on it for a lot of critical functionality.
(4) We need to migrate all consumers to the new service. My team cannot parallely support both the versions and the legacy system has to be deprecated before the new service deployment.
Challenges:
(1) Originally, the plan was for my team to roll out the new service and migrate all of the consumers to the new service as well.
(2) Now, we've had a huge scope expansion in the refactoring itself due to which the project timeline has extended massively.
(3) My team feels that working on such a long timeline project is risky and prone to further scope expansion if new consumers start using the old legacy system in the meanwhile.
(4) Another challenge with this is that my team has no context or understanding of all the consumer systems.
Questions:
(1) What approach can I use to now change the plan and convince the managers/tech leads of the consumer teams to own the migration of their consumers code to the new service?
(2) In general, what approach would be ideal for such a large-scale migration - Centralized migration by the service provider team vs distributed migration by all the respective consumer teams?
Discussion
(1 comment)- 110 months agoTech Lead @ Robinhood, Meta, Course Hero
Great questions - I really appreciate all the detail!
(1) What approach can I use to now change the plan and convince the managers/tech leads of the consumer teams to own the migration of their consumers code to the new service?
Guiding principle: Put yourself in their shoes.
As an engineering leader, your goal is to make sure that your team is able to accomplish its existing projects on time. This means that the default knee-jerk response to some outside team coming in with extra work will be: "My team already has a bunch of stuff to do and absorbing your task will make us fall behind - Why should we do it?"
In order to convince them to incorporate your ask, you need to overcome that initial mentality. Make it clear what the impact of your work is, how it benefits their team, and have a basic understanding of their roadmap so you can come in with some sort of plan for them to weave in your work.
Zooming out from the tactics, a lot of convincing others depends on the strength of your relationship with them. We talk about this in-depth in our masterclass: [Masterclass] How To Build Deep Relationships Quickly In Tech
(2) In general, what approach would be ideal for such a large-scale migration - Centralized migration by the service provider team vs distributed migration by all the respective consumer teams?
Obviously the distributed migration - You even mention that your team doesn't have a rock-solid understanding of all consumer systems.
However, like with most ideal options, this path is much harder than a centralized approach where you more or less do all the work. As a Series C startup, I imagine that bonds between teams are pretty tight, so hopefully you're able to convince folks to band together? This something you'll need to play by ear - If there's too much friction, it's possible that a "Fine, I'll do it myself" approach is needed.
