Liberty Mutual

In late 2016, Xentaurs had sold a Docker and cloud migration engagement to Liberty Mutual's Consumer business unit. The engagement was struggling—things weren't going well, and changes needed to be made. That's when they called me in.

Liberty Mutual was skeptical, to say the least. I had about three hours to prove myself or I'd be sent home. Fortunately, my first day coincided with their planning kickoff. That's when I took control of the room and started running sticky note Agile exercises to structure the work ahead.

The team was already convinced that Docker could give them a cloud-agnostic deployment strategy—that wasn't the issue. What they lacked was a concrete plan to get there. I provided that plan: Chef recipes to automate Docker Datacenter deployments, with Fusion built on top as the developer experience layer.

The foundation was Chef recipes that automated Docker Datacenter deployments—the infrastructure layer that made container orchestration possible at enterprise scale. On top of that, we built Fusion: a self-service automation platform that gave developers a clean interface for deploying into this infrastructure.

At the heart of Fusion was the "Fusionfile," a declarative configuration where teams could specify everything their application needed without understanding the underlying Chef or Docker complexity.

The Fusionfile approach embodied the same philosophy I'd developed at Pearson and refined at Aetna: give developers self-service capabilities while the platform enforces operational best practices automatically.

We started by containerizing three initial applications, including some challenging enterprise workloads. One notable success was containerizing IBM DataPower—not exactly the easiest thing to put in a container.

We also implemented Automated Virtualized Testing (AVT), which allowed teams to run integration tests against virtualized versions of their dependencies. This removed another bottleneck from the deployment pipeline.

The Sr. Director of Cloud and Automation Engineering had two teams: one writing Chef recipes for the infrastructure layer, and another building Fusion for the developer experience. The problem? These teams were constantly dependent on each other. A single feature would take two sprints—one team would build their piece, then wait for the other team to build theirs.

I suggested "cake slicing" as a solution. Instead of organizing by technology layer (all Chef work on one team, all Jenkins/Fusion work on another), reorganize into cross-functional teams. Each team would have both Chef and Jenkins engineers, capable of delivering complete features end-to-end in a single sprint.

The principle applies beyond this specific case: organize teams around delivering value, not around technology layers. When teams can deliver complete, working features without waiting on other teams, velocity increases dramatically.