What Delivery Transformation Actually Looks Like

The word "transformation" makes me uneasy. It sounds like a PowerPoint event -- someone buys a framework, renames the meetings, and declares victory.

I have led two large-scale delivery transformations. One at a $350M healthcare enterprise with 70+ teams. One at a defense software factory with a 9-person government division and 30-person contractor org. Neither looked anything like a PowerPoint event.

The healthcare enterprise

When I arrived at Kaiser Permanente's digital organization, the product model was aspirational. Teams had PM titles. They had Jira. They had standups. What they did not have was a shared understanding of what product work actually meant.

The first thing I did was listen. I assessed 9 experience groups across 5 dimensions using a Crawl/Walk/Run maturity rubric: product roles, product organization, planning, discovery, and delivery. Most groups scored 1-2 on the 5-point scale. The patterns were consistent: discovery was primarily technical -- teams validated feasibility but rarely asked whether the thing was worth building. OKRs existed but were fragmented -- 144 of them, with no coherent cascade. Planning happened annually, which meant teams were locked into commitments made on information that was already stale.

I wrote a candid memo to my coaching lead. It named the hard truths: HiPPO culture where the loudest executive determined what got built. Year-ahead forecasting that punished teams for learning. Shared services that created bottlenecks at every handoff.

The memo was uncomfortable. But once the truth was on the table, everyone could point in the same direction.

What I built

I did not install a framework. I built learning infrastructure.

Four Quick Start Guides that taught the basics -- how to write a user story, run a retro, prioritize between great ideas, send a stakeholder update. Not theory. One-pagers with step-by-step instructions and worked examples. I built a 40-resource learning hub organized across 10 product practice categories. I designed the OKR cascade framework that connected enterprise metrics through customer-level outcomes to squad-level key results.

Then I coached. Fifty PMs through async modules and live sessions. Fifteen executive OKR workshops to connect roadmaps with measurable outcomes. A PM Community of Practice with office hours and "Bring Your Own Backlog" sessions.

What changed

One portfolio cut delivery cycle time by 12 weeks after a value stream mapping initiative. Not because of the map -- because the map made the waste visible, and visible waste is harder to ignore.

The board recognized the work as a 2023 transformation milestone. The learning hub reached approximately 20,000 KP IT staff. Over 1,100 people attended the workshops and bootcamps.

But the metric I care about most is not reach. It is this: teams that went through the coaching started asking "what outcome are we trying to move?" before they asked "what should we build?" That shift is the entire transformation. Everything else follows from it.

The defense software factory

The defense engagement was a different animal. A U.S. Space Force division had been cycling for six months with no clear output. The engineering talent was real. The delivery was not happening.

The first thing I found was a gap between ambition and practice. The organization wanted to be a modern software factory. But the teams had never been through a Discovery & Framing process. They had never shipped an MVP. The operational acceptance requirements created a fear of deploying anything to production.

What I did

I coached the first app team through their entire lifecycle -- from Discovery & Framing through inception, MVP, and production deployment. The team learned by doing. We mapped user personas, built journey flows, prioritized a problem list, and turned that directly into an inception backlog. No handoff document. The learning became the plan.

I created outcome-based portfolio roadmaps and iterated them across 7 contract line items over 7 months. Each update connected the work to measurable results, not feature lists.

The operational acceptance breakthrough was the hardest win. Traditional OA was a multi-month gate that teams feared. We navigated a path to clear the first app for production without the traditional process, unblocking deployments for the entire organization. The team Slack thread called it a "huge victory."

What changed

MVP cycle time went from six months to two weeks. That is a 92% reduction. The same engineers. The same technology. Different practices, different coaching, different relationship with risk.

What most transformation plans get wrong

Both transformations taught me the same lesson: the plan does not transform anything. The daily practices do.

They start with the org chart. Reorgs feel like progress. They rarely are. Both transformations happened with the existing org structure. The teams did not need different reporting lines. They needed different habits.

They install a framework instead of building capability. SAFe, Spotify model, dual-track agile -- none of these work as an installation. They work as an aspiration that teams grow into through coaching and practice. The Quick Start Guides I built at Kaiser were not a framework. They were training wheels that teams could remove once they had the muscle memory.

They measure adoption instead of outcomes. "We have 90% Jira adoption" is not a transformation metric. "Teams are shipping smaller increments and getting user feedback weekly" is. The first measures compliance. The second measures capability.

They skip the uncomfortable memo. Every organization I have transformed needed someone to name what was actually happening. Not what the dashboard said. Not what the status report claimed. What was actually happening in the teams, in the meetings, in the backlogs. That honesty is the precondition for everything that follows.

The one thing

If I could distill delivery transformation to one practice, it would be this: get the team to ship something small to a real user, this week. Not next quarter. Not after the planning cycle. This week.

Everything else -- the rituals, the roadmaps, the OKRs, the coaching -- exists to protect and sustain that practice. Ship something small. Learn from it. Do it again. That is the transformation.

---

I help teams go from stalled to shipping. If your organization is stuck in transformation theater, let's talk about what actually works.