Scaling Without
Breaking

This engagement began because the Head of Engineering had seen me work in a previous role. He didn't issue a brief or run a selection process. He commissioned the work on the basis of what he'd observed. That's the pattern I want to be clear about: the referral came from demonstrated results, not from a proposal.

It also led directly to a second engagement — documented in Case Study 02 — where the same client made a specific exception to their freeze on external engagements during COVID-19. The trust was already established. That's the relationship this kind of work produces when it goes well.

The full diagnostic methodology, assessment data, and intervention detail are documented on orchiture.com. What follows is the shape of the engagement.

A global cloud accounting platform — UK subsidiary of a major US SaaS company — needed to triple its engineering capacity. The business was growing. The team structure wasn't ready for it.

The original team was scaling into three. Engineering managers were being promoted from individual contributor roles — technically strong, but without experience leading teams at this pace of change. In the eight sprints before engagement, zero had delivered their committed scope. Cycle times were running at 7–15 days per user story, with high variability between team members.

The product ownership model was the underlying problem: the wrong people were doing product work, and this was creating a cascade of downstream dysfunction. But this wasn't visible from inside the system. The diagnostic found it.

All changes ran alongside live delivery. There was no protected transformation phase.

All results tracked continuously via flow metric data, sprint completion records, and quarterly agility assessments against the same framework used at baseline.

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. Engineers reported not having enough time to write code; one hadn't written any at all, spending their time instead doing work that should have belonged to product management. Removing that constraint unblocked everything downstream.

The engineering organisation tripled in team count and improved delivery simultaneously. There was no protected transformation phase. This is only possible when the diagnosis is structural rather than symptomatic — when you fix the root, not the branch.

The prior relationship is also worth naming. The Head of Engineering commissioned this work because he'd seen the same approach work at a previous company. He didn't issue an RFP. That kind of trust is the strongest available signal about a methodology — and it's what produced the second engagement.

The organisation that started this engagement could not keep a sprint commitment. The one that ended it was scaling three teams at once, shipping with confidence, and building the structural conditions for further growth. Those are different kinds of organisations. The gap between them is what this engagement built.