My company, CircleCI, is a big believer in the blameless postmortem—the idea that when you discuss a project and take emotion out of the picture, you create a true learning experience. Following our migration to a microservices architecture, we had a good opportunity to run a blameless postmortem on what we did right and wrong, and what we’d do differently next time. If you’re thinking about starting the journey to microservices, I’d like to share some advice for creating a smoother transition.

Our move away from monolithic architecture took on urgency when we had a 24-hour outage in 2015. We wanted to be cautious: We’d heard a lot of tales of poor decision-making when transitioning full-stop into microservices. On the other hand, incremental changes to architecture weren’t bringing the transformation we needed. Early wins breaking up our architecture gave us confidence that this was the right direction for our team, and we decided to go all in. Almost immediately, the wheels started coming off the wagon. Engineering productivity ground to a halt. We realized we were throwing people into an unfamiliar environment—like moving from the small-town comfort of the monolith to the unknown microservices big city.

In our post-mortem, we came up with three sources of friction in our microservices migration, and we developed ways to address them.

1. Decision-making

“Analysis paralysis” is being faced with a decision that’s so complex that you spend ages considering all the options without pulling the trigger on anything. The solution is to make hard decisions early on, and then reduce future decision-making to exceptions only—choosing to go in another direction only when that initial decision fails you.

.) For example, our site reliability engineering (SRE) guild has a weekly meeting that anyone can attend. When people are working on the same problem—like a gRPC library or connecting databases—we can centralize the work.

Today, more than a year after our initial launch, we’re feeling the impact of microservices. We’re running at five times the utilization of the previous platform, and the old operational concerns (like slow builds and outages) have largely disappeared. We were successful because we recognized that this project was an investment in engineering, not a product delivering value to customers.

Getting buy-in on this point is key when you’re breaking up architecture into microservices, because you’ll be making a lot of upfront decisions and investments. If you choose to approach a transition like this piecemeal, be aware that you’ll be facing a lot of rework. Make sure to have a healthy conversation about this investment before you take the first small steps toward microservices.

This article is published as part of the IDG Contributor Network.