§ CASE STUDY Strategy diagnostic · SaaS transition

Seven cascading failures. One question nobody had asked.

A $100M, 60-year engineering consultancy had grown a $3–5M software business almost by accident — and it was quietly straining under its own weight. The problem wasn't the code. It was a decision no one had made.

Diagnostic interviews
15+
Competing visions
51 owner
Products in focus
8–102 core
§ THE CLIENT

A privately owned engineering consultancy, 60 years in oil & gas technical services. Software crept into the business almost by accident — point solutions and calculators built to support consulting engagements, then two flagship products that grew into genuine SaaS offerings with customers across three continents.

By 2026, software was generating $3–5M a year in license fees and consulting pull-through. On paper, that looked like traction. Underneath, the organization was straining.

Industry
Engineering consulting
Revenue
~$100M (software $3–5M)
Age
60 years, privately owned
Products
8–10, team for 2
§ THE SITUATION

Everyone was working hard. Nothing felt like it was working.

Tech leads were coding, reviewing pull requests, managing deployments, and mentoring — simultaneously. Product owners were doubling as salespeople and client-success managers. Division leaders were running one-person go-to-market operations. The team was maintaining eight to ten products with the bandwidth to properly support two.

Leadership's shorthand for all of it was blunt: "digital doesn't work." The mandate was to find out whether that was a talent problem, a process problem, or something else entirely.

§ THE DIAGNOSTIC

The engagement opened with 15+ semi-structured interviews — executives, division leaders, product owners, tech leads, developers, QA, design — built to surface what individual roles were actually experiencing, not what leadership assumed. Interview data was scored against a six-dimension SaaS maturity model, calibrated for a consultancy attempting a software transition rather than a company that started as software.

Every dimension landed between 1.0 and 2.0 on a five-point scale — "ad hoc" to "emerging." But the lowest scores weren't in engineering. They were above the code.

Strategic alignment
Ad hoc · floor
Customer success
Ad hoc · floor
Business model
Emerging
Go-to-market
Emerging
Product management
Emerging
Engineering operations
Emerging
§ THE ROOT CAUSE

Tracing the failures back, one root cause explained nearly all of them: the company had never explicitly decided whether it was building a software business.

Five different leaders held five different visions — one saw platform consolidation, another a consulting enhancement, another a $10–20M growth business over five to ten years. None were wrong. None had ever been forced to converge, because nobody had asked the question at the level of authority required to answer it.

The result was a governance vacuum: any leader could veto a decision, but no one could greenlight one. One designer had redesigned the same feature three times, because leaders who missed the meetings vetoed already-completed work.

§ THE PLAN

The deliverable wasn't a report — it was a diagnosis paired with a sequenced plan across six phases (0–5), built on one principle: each phase frees the capacity the next one needs. Phase 0 was the lever — the decision itself.

PHASE 0
Make the decision
Appoint one accountable owner of the software business. Stand up a two-tier technical leadership structure — an internal Head of Engineering for execution, paired with a fractional CTO for strategic direction. Create a formal incubator to hold the 6–8 non-core products so the two flagships get the team's full attention.
PHASE 1–2
Free the capacity
DevOps automation and product analytics — sequenced to when the team would actually have bandwidth to sustain them.
PHASE 3–5
Build the discipline
A buy-vs-build framework, pricing discipline, and a real software P&L — each timed to the capacity the earlier phases released.
§ THE RESULT

The engagement replaced five competing visions with one documented decision and a roadmap the executive team could hold each other accountable to. In the weeks following the diagnostic:

DimensionBeforeAfter
AccountabilityAnyone can veto, no one can greenlightOne accountable owner appointed
Technical leadershipTech leads wearing four hatsHead of Engineering + fractional CTO
HiringStalledPhase 0 DevOps + CTO searches launched
Product focus8–10 products, 2-product teamCost-neutral plan rationalizing to 2 flagships
Strategy5 competing visions1 documented decision + sequenced roadmap

An organization that had relitigated the same decisions for years now has one answer, one owner, and one sequence to follow.

— Engagement summary
On the record

The metrics are deliberately absent — for now. This was a structural reset, not a quarter-over-quarter story. The more interesting numbers — test coverage, deployment frequency, renewal rate — are worth revisiting once Phases 1–2 have run. This case is anonymized at the client's request, and a version with hard post-implementation metrics can follow when the results are in. I'd rather show you nothing than show you numbers that aren't real yet.

§ THE TAKEAWAY

Seven operational failures, fifteen interviews, a six-dimension maturity model — and the whole thing resolved to one question asked at the level of authority that could answer it. That's the pattern under most stalled businesses: the expensive problem isn't a lack of effort or talent. It's a decision that's been quietly deferred, hiding behind everything downstream of it.

Find the system, and the single smallest change that moves it. Usually it's one level up from where everyone's looking.

What decision is your business quietly working around?

A Two-Day Teardown finds where the money is actually stuck — often a decision nobody has made — and names the one to three moves that unstick it. You keep the map either way.

Book a Teardown