How to scale a tech company
without starting with technology.

The technology reflex

When a software company falls behind, it reaches for technology. More automation, better tooling, a platform to remove the manual work. It feels like the native move because the company thinks of itself as a technology company, and technology is what it is good at.

But systems scale whatever shape is already there. Put automation over an organisation where nobody owns the decisions, and you get the same chaos, faster and harder to see.

Systems go last. I learned that in the wrong order.

Solving the wrong problem

Thirty-five people. Deliveries running six to twelve months late. Customers are churning. The diagnosis was engineering, and I was brought in to fix engineering.

So I fixed engineering. A front-end component library, a development framework, and twelve new people into my team. Onboarding fell from three months to six weeks. The inputs got measurably better.

The deliveries did not.

That is the useful part of this story. I did the competent, obvious thing first, and it worked exactly as intended without moving the outcome. Engineering had never been the constraint. Product operations were the constraint, and nobody upstream owned them.

The invisible workload

The executive team measured one thing: delivery timelines. In practice, that meant engineers were pushed without boundaries, individual deliveries were micromanaged, and a second body of work accumulated outside the roadmap, unprioritised against anything else.

Nobody was behaving badly. The team had built the company. But the job had changed underneath them, and nobody had been sponsored to change with it. There was no mandate from the top to develop the executives into the scale the business had reached.

Being miscast is a diagnosis, not a verdict. It forces a choice: coach the person into the role with real backing, or change the role. What kills companies is doing neither for two years, then reaching for a replacement when the runway is short.

Where systems break

Companies do not degrade smoothly. They break at levels, and each level dissolves the operating shape that worked at the one below it. A sixty-person company with two layers of management is a hundred-person company’s problems arriving early.

I joined at thirty-five people — the first tier by headcount, but carrying the middle tier’s constraint with none of its structure. The company had grown without graduating.

The struggling executives had been excellent at the level below. Nothing about them had declined. The level had changed, and nobody had been asked to change with it.

Why the mandate stalls

Governance came first. Departments began communicating about releases and roadmaps in one place rather than four. Things improved, but they did not transform.

What transformed them was org design. The teams were broken into specialised feature teams, each with an owner. Delays fell from roughly six months behind to roughly one.

One initiative ran the other way, and it is worth its place here. A standardised user-story format across four teams was worth about €188,000 a year in reduced rework. It returned under €8,000 — because when I moved on to the product mandate, the prior team was reinstated and the practice was dropped within months. Nothing about it had stopped working. The owner changed. That is the sequence enforcing itself, whether or not you believe in it.

Then we hit the technical wall. The product was a monolith, single-tenant, built by a team that had not built a scalable SaaS product before, running business-as-usual while attempting the rebuild. There had been three failed attempts across three years. All three failed because no product operations existed to put stakeholder, product and engineering review in the right order.

The decision was made to carve my team out, with me taking the product mandate. Engineering had been building blind for six months with no written scope or specification. And the industry’s biggest annual conference, where vendors live or die by their demonstrations — was six months away.

I installed product operations: two product iterations a week, every week. Within three months, specifications ran a month ahead of engineering — the difference between a team executing and a team guessing.

We shipped a beta at the first industry conference and the main release at the next, which took a main-stage award. Delivery went from once a quarter to four commits a day.

The group eventually reached three hundred people through two acquisitions — the stage where growth becomes capital allocation, which is the sponsor’s move rather than the operator’s. That number was survivable only because the structure had been built for the first phase.

Org design. People. Process. Systems.

That sequence is not a philosophy. It is the order I arrived at by trying it backwards.

The number that shows decay

When a company is late and churning, the instinct is to add capacity, and after that, technology. Both are visible, both are purchasable, and both leave the operating shape untouched.

There is a tell you can read before any diligence: revenue per head drifting below €100,000 while revenue still grows. Headcount rose and the operating model did not.

The shape is the thing. Find out who owns the decision that is actually late — in most of these companies, the answer is nobody — and fix that before buying anything.

Figures draw on an executive mandate at a PE-backed vertical B2B-technology group; the group and its customers are not named. The staging draws on a published scaling roadmap, re-expressed; the revenue-per-head figure is from published SaaS benchmark surveys. Bases and classifications are held in a separate evidence note, available on request.

The sequence, installed function by function, is the Method page →