Building a global capability centre to Swiss standards

A global capability centre is easy to set up and hard to make valuable. The setup is a lease, a recruiter and a manager. The value depends on where the centre sits on a maturity curve that most never climb.

This is that curve, and what it takes to move up a stage.

Why Swiss companies are looking at this differently

Swiss organisations arrive at the GCC question from a different direction than their US peers. The driver is rarely labour arbitrage alone — Swiss engineering costs are high, but so is the tolerance for paying for quality.

The actual drivers are usually:

• Capacity that cannot be hired locally in a reasonable timeframe, particularly in cloud, data and AI engineering
• Coverage — CET overlap for daily coordination, with work continuing after Swiss hours
• Continuity — a stable team that accumulates knowledge of your systems, rather than a rotating contractor pool

That third driver is the one that determines whether the centre ends up valuable, and it is the one most affected by which maturity stage you stop at.

The four stages

Stage 1 — Staffing

The centre supplies people. Work is specified elsewhere, sent over, and returned. Success is measured in headcount and utilisation.

This stage is legitimate as a starting point and damaging as a destination. The failure mode is specific: because all context lives at the requesting end, every task carries a full specification cost, and the centre never accumulates judgement. Velocity plateaus, and the usual conclusion drawn is that the people are the problem.

Stage 2 — Delivery ownership

The centre owns components end to end — build, test, release, support. Specification moves from “how” to “what”.

The change that makes this work is not seniority, it is access: to production telemetry, to the ticket queue, to the users. A team that cannot see the consequences of its work cannot own outcomes, whatever the org chart says.

Most centres that create real value are at least here. Many stop here, which is a defensible choice.

Stage 3 — Capability ownership

The centre owns a capability rather than a component — an entire domain, including its roadmap, its architecture decisions and its technical debt.

What this requires is uncomfortable for the parent organisation: the centre has to be allowed to say no, and to propose work that was not requested. A capability owner who can only execute requests is still stage 2 with a longer job title.

Stage 4 — Co-creation

The centre originates. It proposes products, runs experiments, and its engineers are in the conversations where direction is set.

Few centres reach this, and not all should — it requires a scale of investment and a degree of trust that only makes sense if the capability is strategic. Treating it as a universal goal produces disappointment.

The risk of staying at stage 1

Stage 1 looks cheap and is the most expensive per unit of work delivered, for reasons that do not show up in the rate card:

• Specification overhead. Every task is fully specified because no context is assumed. That cost sits with your most expensive people.
• Attrition. Engineers who never see the consequence of their work leave. Each departure resets whatever context had accumulated.
• Quality that cannot improve. A team without access to production cannot learn from failure, so the same categories of defect recur.

The measurable symptom: cost per delivered feature stays flat or rises as the centre grows. If adding people does not reduce unit cost, you are at stage 1 regardless of what the operating model document says.

The governance that makes each stage work

Swiss organisations tend to be good at this part, and it is what distinguishes a centre that matures from one that expands.

Named accountability on both sides. Not a vendor relationship and a delivery manager — a person here and a person there, each with authority to decide.

Decision rights written down. Which decisions the centre makes alone, which it proposes, which it escalates. Unwritten, every decision escalates by default and stage 2 never arrives.

Data access resolved before the team starts. Under revDSG/nDSG and GDPR, engineers in another jurisdiction touching personal data is an access question that needs an answer — pseudonymised datasets, access controls, documented sub-processing. Solvable, but not retrospectively.

Quality standards that are the same standards. A separate, lower bar for the offshore team guarantees the centre never progresses, because it institutionalises the assumption behind stage 1.

Engineering practice as the differentiator

Between stages, the thing that actually changes is practice rather than seniority:

• Trunk-based development with automated tests, so ownership does not depend on a release manager
• Observability the centre can read, because you cannot own what you cannot see
• Documented architectural decisions, so the reasoning survives staff changes
• On-call participation — the clearest signal that ownership is genuine

That last one is a good test of stated maturity. A centre that owns delivery but is not on call does not own delivery.

How to use the model

Place the centre honestly, then pick one stage to move up. Skipping a stage does not work — a centre without delivery ownership cannot hold capability ownership, whatever the mandate says.

For most Swiss mid-market companies the right ambition is a solid stage 2 with one domain at stage 3. That is achievable in a year or two, and it produces the continuity benefit that motivated the centre in the first place.

If you want to work through where a centre or a dedicated team sits and what the next stage would require, book a call. No obligation.