Helping move an underwriting platform off its monolith

What this was

A property and casualty insurance underwriting platform at Liberty Mutual, built and run by a cross-functional agile team. I was an engineer on it for four years. Not a technical product manager who occasionally opened the repository: an engineer whose job was writing and maintaining the code.

It did not start as the microservices system it ended up being. It started as an on-premises monolith.

Moving off the monolith

Over those four years the platform moved from that on-premises monolith onto AWS microservices, and the legacy system was retired.

I want to be precise about my part in that, because “worked on a cloud migration” is a claim people stretch. I was one of the engineers writing the microservices. I did not run the program, and the decision to go was not mine. What I can say is that the migration finished and the old system was turned off. Plenty of modernization efforts quietly become a permanent second system running alongside the first, so that ending is worth stating.

That is most of what I took from it. A migration is not done when the new thing works. It is done when the old thing is gone, and the hard part lives in the gap between those two moments: undocumented behavior, an integration only one team remembers, a report that turns out to matter. Underwriting is a domain where “close enough” is not a passing grade, so parity had to be proven rather than asserted.

The work

I wrote maintainable production code in Angular, Java, TypeScript, and SQL across the system. I supported implementations and deployments through testing, validating features and functionality, correcting code, and fixing bugs before go-live. When something broke, I worked with product owners, developers, customers, and scrum masters to find the root cause rather than the nearest symptom.

The formative part was the training. Liberty Mutual put me through a practical Extreme Programming program with Pivotal Software consultants: pairing, test-first, continuous integration, small releases, done properly rather than as a poster on the wall. That is where I learned what a healthy delivery team feels like from the inside, and it is the standard I have measured every team against since.

Why it matters

I moved into product deliberately, not because I could not code. That distinction shows up constantly in the job:

• I can read the codebase we are arguing about, so estimates and risk conversations start from evidence
• I know the difference between a request that is hard and one that is merely unfamiliar
• I know what it costs a team when a product owner writes a vague story, because I have been the person who had to implement one
• I have been inside a legacy migration as one of the people doing the work, which is a useful corrective when I am later the one drawing the plan for one

Four years of engineering is the reason the product work that came after it was any good.