This week, we will follow up last week’s post about monolith vs microservices by discussing how you can incorporate this change into your roadmap.

As a Product Manager, the architecture of the system isn’t your decision, but you are an important stakeholder. It’s important to know that making the transition often takes a long time. If you thoughtfully include it in your roadmap, you can lessen the difficulty. Here are the top questions to ask your engineers if they’re talking about doing this:

1. Are there frameworks and libraries other teams are already using to do this? In an organization that has embraced services, there should be examples that can make the transition easier. At my company, we have a sample service that comes pre-loaded with things like a database, pipelines for testing and delivery, and testing suites so that teams don’t have to do extra work to scaffold their services. If your organization is very early in this transition, then your team may have to do research and pick new technologies, which will be more experimental and take more time.
2. What other teams are dependent on our part of the code? If you own a piece of the system that other teams depend heavily on (e.g. user data or authorization), this change is going to impact a lot of people who may not be ready for it. Better put on your stakeholder-management hat and get talking to those other teams & PMs! If the answer is “we don’t know,” an important first step will be to socialize this potential change and find out.
3. What are our options to transition traffic from the old code to the new code? Just like rolling out a new feature to users, there are many approaches to rolling out a new backend, which could impact the user experience. Your stakeholders (in support, for example) will need to know that a change is happening that could impact users in case they see an increase in tickets.
4. Who will support and be on-call for our code? With a monolith, you will typically see a centralized support team who is on call for issues, but as the monolith gets broken apart into independent pieces, that team can’t keep up. A move to services often includes a move to dev ops, where your engineers may have to be on call and maintain the service themselves so that it stays up. This places additional responsibility on the team that will have an ongoing impact on your roadmap: in the same way you should always plan wiggle room for unexpected bugs, you will have to make wiggle room for operational tasks like deployments and upgrades.

One thing you SHOULDN’T ask: how long will this take? If they give you a straight answer, they are probably kidding themselves. I would approach roadmapping this in an ongoing, nebulous way. Work with your team to break the work down into phases as much as possible, and try to estimate the smaller chunks, but keep some percentage of your capacity reserved for this for as long as it takes. You can’t expect this to happen in the background and keep up a normal delivery cadence, so you will have to communicate it as a deliverable on your roadmap outwards to stakeholders.

When you thoughtfully partner with your development team to plan and roadmap this transition, you can achieve technical improvements while still delivering value to your users and stakeholders.