From Sporadic Releases to Momentum

A story from a recent client engagement (details anonymised).

Situation

A software company with over thirty engineers, designers, and QA staff was struggling to scale its delivery. The teams operated in a project mindset, working reactively to customer requests, with minimal shared vision. Releases were infrequent, ownership was blurred, and leadership lacked visibility into progress.

The organisation wanted to evolve into a true product company, but didn't yet have the frameworks, rituals, or architecture to support it.

Approach

I began by introducing a shared language and structure:

Organisational Changes

Ran workshops to establish cross-functional teams around outcomes, not functions.

Set up a lightweight RFC/ADR process to make decisions explicit and discoverable.

Facilitated retrospectives and architecture guilds to build collective intelligence.

Clarified roles and accountability, ensuring POs, designers, and engineers owned the same goals.

Technical Improvements

Introduced sprint zero for teams to co-design their environments, CI/CD, and definitions of done.

Improved the release pipeline, enabling multiple deploys per week instead of one per month.

Introduced observability and automated quality gates for consistent confidence.

Moved toward API-driven modularisation, enabling teams to ship independently.

Throughout this process, we fostered a shared product strategy that connected business priorities with technical feasibility.

Outcomes

Over several months, the change was visible:

Delivery Metrics

Release cadence improved to multiple times per week

Cycle time and incident rates both dropped

Teams self-organised around problem-solving

Cultural Changes

Product discussions shifted from "what's urgent" to "what delivers value"

A culture of writing, reflection, and collaboration emerged

Teams started to feel proud of what they were building again

But beyond metrics, the greatest success was psychological: Teams started to feel proud of what they were building again.

Reflection

This project reaffirmed my belief that technology transformation is culture change disguised as architecture. When people see how their work connects to outcomes (and when systems support that) velocity, quality, and morale all rise naturally.

This story excludes client names and dates for confidentiality.

Interested in similar transformation work?

Let's discuss your challenges ← Back to work overview

From sporadic releases to momentum