Learning to build software as part of an agile team
Four years building and supporting a microservices-based property and casualty insurance underwriting system on a cross-functional agile team.
- 4 yrs
- Hands on the keyboard
- XP
- Trained by Pivotal consultants
What this was
An expansive microservice-based underwriting system, built 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.
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 actually 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 genuinely 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
Four years of engineering is the reason the product work that came after it was any good.