Scaling a development team when hiring is the blocker

The Swiss engineering market has a structural imbalance: demand for cloud, data and platform skills exceeds local supply, and it has for several years.

The consequence is not that hiring is expensive. It is that hiring is slow — five to six months from opening a role to a contributing engineer, most of which is notice period and onboarding rather than search. For a plan built on capacity arriving in Q2, that is the plan failing quietly.

This is what to do when the roadmap will not wait.

Why the traditional model stops working

Three things compound, and none is about salary.

Notice periods are contractual. Three months is standard for senior roles here and is not negotiable regardless of what either side wants.

The pool is small for specialised profiles. For MLOps, data engineering or platform work, the number of qualified people realistically available is genuinely limited — and you are competing with employers who can pay more and wait longer.

Onboarding consumes the team you already have. Each new engineer takes weeks of existing engineers’ time. Hiring three at once can reduce output for a quarter, which is the opposite of the intent.

The honest conclusion: permanent hiring is the right instrument for permanent needs and a poor instrument for a capacity gap with a date on it.

Step 1 — Separate the skill gap from the timeline gap

These are different problems and they get conflated, which produces the wrong solution.

A skill gap means nobody in the team can do this. It persists after the project. If the capability is core to your business, hire for it — and accept the timeline.

A timeline gap means the team could do this, but not by the date, because they are doing something else. It ends when the peak ends.

Write the distinction down per item on the roadmap. Most teams discover that two-thirds of what they were about to hire for is a timeline gap, and hiring permanently for a timeline gap creates a cost that outlives the need by years.

Step 2 — Bring in flexible capacity, evaluated properly

For the timeline gaps and the specialised-but-temporary work, external capacity is the instrument. What decides whether it works is not the rate card.

Four things predict the outcome:

• Named people, not a pool. A named team accumulates knowledge of your systems; a pool resets it at every rotation, and you pay the specification cost again each time. This is the strongest single predictor.
• Overlap with your working day. Same-day review, demo and coordination is the difference between a team and a queue. A 24-hour round trip on each question turns a two-day task into a week.
• Access to what they are building against. Production telemetry, the ticket queue, real usage. A team that cannot see the consequences of its work cannot own outcomes, whatever the contract says.
• Knowledge transfer built in. Ask what documentation you receive and what would have to happen for your own team to take over. A partner comfortable with that question is a different proposition from one who deflects it.

The fuller criteria are in choosing a software development partner in Switzerland.

The regulatory item to settle before anyone starts: engineers in another jurisdiction touching personal data is a real question under revDSG/nDSG and GDPR. Pseudonymised datasets, documented access controls and sub-processor records answer it — but not retrospectively.

Step 3 — Judge on speed, quality and fit together

Optimising for any one of these produces a predictable failure.

Speed alone gets you people next week who need everything specified, which moves the bottleneck onto your seniors rather than removing it.

Quality alone reproduces the hiring timeline you were trying to escape.

Fit alone is pleasant and does not ship.

A practical test that covers all three: start with something small, real and time-boxed — not the largest item on the roadmap. A first engagement with a defined end tells you more than any selection process, and it costs far less than discovering the same thing mid-programme.

What to do in parallel

Two things that reduce the capacity you need at all, and are usually cheaper than the hire:

Remove toil. Manual release processes, environment provisioning that takes days, the recurring incident nobody has had time to fix. A week here often returns more than a quarter of recruiting.

Check whether the constraint is structural. If a change needs four systems to agree, adding engineers does not help — delivery speed is an architecture property at that point, not an effort property. The diagnostic is in the hidden costs of scaling.

Measuring whether it worked

Not headcount. Three numbers:

• Time from decision to first merged change — the real capacity cycle, onboarding included
• Cost per delivered change, over quarters. If it rises as the team grows, the constraint was structural.
• Share of time on unplanned work — rising means the estate is consuming the capacity you added

If cost per delivered change is not falling, you added people to a problem that was not a people problem.

Related reading

• How Swiss startups can scale tech teams without delay
• Maximising engineering ROI: the CFO’s guide
• Dedicated engineering teams

If the roadmap needs capacity sooner than a hiring cycle allows, book a call. No obligation.