The Growth-Ready CEO: capital, people and technology

Growth plans usually fail on one of three constraints, and almost never on the one the plan was written about.

A plan built around a market opportunity fails because the engineering capacity was not there. A plan built around a product launch fails because the capital structure could not absorb the working-capital swing. The three are coupled, and treating them separately is what produces plans that look sound and do not execute.

Capital: the question is shape, not amount

Swiss mid-market companies are not generally capital-starved. They are frequently capital-mismatched — the money available is the wrong shape for what growth requires.

Three distinctions worth making explicit:

Growth capital versus working capital. Expanding often increases the gap between paying for something and being paid for it. That is a working-capital problem and it is not solved by an investment budget.

Committed versus flexible. Capital committed to a fixed cost base — permanent headcount, owned hardware, long leases — cannot be redeployed if the market moves. In an uncertain period, flexibility has a value that is usually under-priced.

Timing. A great many plans are correct and mistimed. The investment lands one quarter before the revenue that supports it, and the gap is where plans break.

The practical question for a CEO: if growth is 30% slower than planned, what in the cost base can be adjusted, and how quickly? If the honest answer is “very little”, the structure is a bet on the forecast rather than a plan.

People: competing for talent without competing on salary alone

The Swiss talent market is tight, particularly in cloud, data and AI engineering. Competing purely on salary is available to a small number of employers, and most mid-market companies are not among them.

What works for the others is changing the shape of the need rather than winning every hire:

• Hire permanently where continuity is the product. Knowledge of your business, architecture ownership, customer-facing engineering. These roles are worth waiting and paying for.
• Bring in flexibly where the skill is specialised or time-bounded. MLOps for one platform build, cloud architecture for one migration. Creating a permanent role for a temporary need is expensive in both directions.
• Reduce the number of people required by removing toil. Automating a manual release process is often cheaper than the engineer you would hire to keep running it.

There is also a retention effect worth naming: engineers leave organisations where they cannot see the consequence of their work. That is a structural property of how teams are set up, not a compensation problem, and it is discussed further in building a global capability centre to Swiss standards.

Technology: the constraint is usually structural

By the time growth is the agenda, the technology question is rarely “what should we adopt?” It is “what is currently preventing us from moving faster?”

The answers cluster in four places:

A core system nobody wants to touch. Stable, undocumented, maintained by a small number of people. It works, and it sets the pace of every change. Replacement is not the answer — incremental modernisation is, as set out in seven principles of legacy modernisation without downtime.

Unclear system boundaries. When four systems must agree for a small change to ship, delivery speed is an architecture property, not an effort property. More engineers will not fix it.

Data that cannot answer questions. If the business cannot get a number without someone exporting to a spreadsheet, every decision runs at manual speed — and AI on top of that data will inherit the same problem.

Compliance handled as a late review. Under revDSG/nDSG, GDPR, and the EU AI Act where relevant, the required evidence cannot be produced retrospectively. Handled as a final gate, it delays releases; designed in, it is close to free.

Aligning the three

The alignment question is simple to ask and uncomfortable to answer: for the growth we are planning, which of the three is the binding constraint?

Most leadership teams answer “all of them”, which is a way of not answering. There is normally one, and the plan should be built around it:

• If capital binds, the technology plan should favour reversible, incremental steps with early returns — not a programme that pays back in year three.
• If people bind, the plan should reduce the number of specialists needed and use flexible capacity for the rest.
• If technology binds, hiring and spending more will not help until the structural constraint is addressed, and the first quarter’s work belongs there.

Getting this wrong is expensive in a specific way: the organisation invests heavily in the constraint that was not binding, and is then surprised that nothing moved.

A short diagnostic

Five questions, honestly answered, place you:

1. If growth is 30% below plan, what can we adjust, and in what timeframe?
2. Which roles are we hiring permanently that we would not need in three years?
3. What is our time from “the business asks” to “the change is live”?
4. Can we get the key numbers without a manual export?
5. Which compliance threshold do we cross next, and is it budgeted?

Related reading

• The engineering ROI playbook
• The hidden costs of scaling
• Dedicated engineering teams

If you want an outside read on which constraint is actually binding, book a call. No obligation.