Scaling Without Breaking

The Situation

A growth mandate with no delivery system to support it

A global cloud accounting platform had made a strategic decision: expand its UK engineering centre to build dedicated product capability for the UK market. The plan was clear — stand up multiple focused teams, bring offshore responsibilities onshore, and accelerate delivery of features that UK accountants actually needed.

The engineering department was not structurally ready for this. A single development team was operating without a functioning product ownership model. Developers were filling the product management vacuum — writing their own stories, managing their own prioritisation, maintaining their own support SLAs — while also being expected to deliver. The result was fragmented focus, unpredictable cycle times, and a sprint completion rate of precisely zero: no sprint in the preceding eight had delivered its committed scope.

The Head of Engineering could see this from the outcomes. What he lacked was the capacity to work inside the system day-to-day — to sit with the teams, coach the newly promoted engineering managers, and hold the delivery model together as the organisation scaled around it.

The Commission
The Head of Engineering had seen this approach work under comparable conditions at a previous scale-up. He brought in the same practitioner — not to audit and advise, but to work inside the system as a delivery partner to leadership: embedded coach, team facilitator, and system diagnostician simultaneously.

The Constraint

The transformation had to be delivered alongside continued product delivery. There was no pause, no "transformation phase", no protected time. Teams were expected to ship while being rebuilt. The engineering managers supporting them were recently promoted from staff engineer roles and were navigating leadership for the first time.

The Scope

The engagement covered the UK accounting product development organisation — one team scaling to three, all based in London. The same client later commissioned a second engagement to address its Payroll product organisation; that work is documented in Case Study 02.

The Approach

A structured diagnostic was conducted across three dimensions: how the team operates, how work reaches the team, and technical practices. Findings were shared with the full leadership triad — Engineering, Product, and Design heads. Anything actionable independently was addressed immediately; anything requiring leadership decisions was escalated with evidence and a clear recommendation.

The Diagnostic

Baseline assessment: Team 1 at engagement start

Within weeks of engagement, a structured baseline assessment was completed using a four-dimension delivery health framework covering product ownership maturity, team health, engineering practices, and organisational conditions. The results confirmed the structural diagnosis and gave leadership a precise starting point.

Delivery Health Assessment — Team 1 (Baseline)

Engagement start · Target: 75 / 99 across all dimensions

Product Ownership

3 / 99

Critical

Team Health

38 / 99

Below Target

Engineering Practices

50 / 99

Below Target

Organisation

69 / 99

Near Target

Critical finding: A Product Ownership score of 3/99 is effectively zero. The PO function was absent in practice — development engineers were making product prioritisation decisions, writing their own stories, and managing support SLAs, consuming time that should have been spent building. This structural void was the primary driver of the delivery problems the Head of Engineering had identified — and the first thing addressed.

The Five Dysfunctions of a Team assessment, run concurrently, identified Commitment (3.0/5) and Accountability (2.86/5) as the two weakest fundamentals — precisely the dimensions that determine whether a team can reliably deliver against a plan.

Team 1 — Baseline

Engagement start

Trust

3.63

Conflict

3.38

Commitment

3.00

Accountability

2.86

Results

3.63

Team 3 — 5 months later

5 months in

Trust

4.75

Conflict

4.88

Commitment

4.43

Accountability

4.71

Results

4.88

The Intervention

System changes, not surface fixes

The diagnostic identified three primary structural failures. Each was addressed through a combination of leadership coaching, team-level experimentation, and process redesign — always proposed as experiments owned by the teams, never imposed as mandates.

Structural

Product Ownership Model Redesign

The most urgent structural failure was the absent product ownership function. Product Managers were operating strategically — vision, roadmap, stakeholder management — but the tactical layer had defaulted to the development team. A clear PM / PO split was implemented: Product Managers retained strategic ownership; tactical product work was either formally assigned or restructured so that engineers were no longer pulling double duty. This single change freed the development team to focus on building.

Team Operating Model

Standing Up Three Focused Product Teams

As the planned expansion proceeded — Team 1 splitting into Teams 2, 3, and 4, each with dedicated PM and XD — each new team was stood up with explicit operating agreements: a Definition of Done, a Definition of Ready, agreed working practices, and relative estimation processes. Onboarding was deliberate, not left to institutional osmosis. The Five Dysfunctions framework was used as a diagnostic and coaching tool for each team, giving the teams a shared vocabulary for the health of their working relationships. Every change was proposed as an experiment, owned by the teams from the outset. Nothing was imposed.

Flow & Predictability

Sprint Commitment and Iteration Discipline

The teams had not treated the sprint timebox as a genuine commitment. Sprint Reviews were restructured — Product Managers led the planning narrative including progress against commitment, engineers demonstrated the work. Epics were given explicit acceptance criteria; support incidents were planned in early. Over twelve sprints, delivery against commitment moved from 58% to 90%.

Technical Practices

Cycle Time Reduction Through Branch Discipline and Pairing

Code branches were being held open for days before merging, creating compounding integration risk as team count grew. Draft pull requests were introduced as a lightweight mechanism to integrate more frequently and surface feedback earlier. Pair programming was introduced as a tactical tool for complex areas. Cycle times across all three teams were halved within months of the expansion.

The Results

Measurable outcomes across flow, predictability, and team health

All results were tracked continuously via flow metric data, sprint completion records, and quarterly assessments. The following reflects the state of the UK accounting product organisation approximately five months after engagement commenced.

Work Delivered vs. Committed

58% baseline

90%

Across 12 consecutive sprints, measured by points delivered against sprint commitment

Sprints Completing Full Plan

0% baseline

42%

Percentage of sprints where the team delivered 100% of committed scope — from zero in 8 prior sprints

Product Owner Agility Score

3 / 99 baseline

85 / 99

Delivery health framework score for product ownership maturity — above the 75-point target threshold

Cycle Time by Team — Before & After

Moving average in days per user story

Team 1 (origin)

Before

After

7–15 days
high variability

Team 2

Before (8.0d)

After (3.6d)

−55%

Team 3

Before (6.6d)

After (2.7d)

−59%

Team 4

Before (5.4d)

After (2.6d)

−52%

The same client recommissioned this practitioner for a second engagement covering a separate product organisation, following a break in which all external engagements had been suspended. That engagement is documented separately in Case Study 02 — Unwinding the Feature Factory.

What This Demonstrates

The signals a CTO or VP Engineering should take from this

Diagnostic before intervention

Every recommendation was grounded in a structured assessment. The leadership team received a written diagnostic with evidence, not a list of opinions. Progress was tracked against the same framework, making improvement visible and attributable.

Transformation without stopping delivery

The engineering organisation tripled in team count and improved delivery outcomes simultaneously. There was no protected transformation phase. The approach was designed to be delivered in parallel with continued shipping.

System thinking, not ceremony coaching

The most impactful change — fixing the product ownership model — had nothing to do with Scrum ceremonies. It was a structural diagnosis: the wrong people were doing the wrong work. Removing that constraint unblocked everything downstream.

Works inside the leadership system

Findings were shared across the full Engineering, Product, and Design leadership triad. Nothing was escalated without evidence. Nothing within remit waited for permission. The practitioner operated as a genuine partner to leadership, not a consultant who reported in from outside.

Results that prompted a return

When the same client later needed to address a second, structurally different product organisation, having paused all external engagements during COVID-19 they made a specific exception to recommission this practitioner. The decision to return is documented in Case Study 02.

Prior relationship as proof of model

The Head of Engineering had seen this approach work under comparable conditions at a previous company. He didn't issue an RFP. The commission was based on observed results — which is the strongest available signal about the reliability of any methodology.

Structural change and coaching ran together

Reorganising into three focused teams created the right structural conditions. Coaching ran alongside — helping the new teams build working agreements, find a shared vocabulary for their health as a group, and develop the trust required to hold each other to commitments. Neither the structure nor the coaching alone would have produced the same outcome.

Unwinding the Feature Factory

Recognise the problem? Let's talk about the fix.