CTO, squad or expert reinforcement: which model should you choose?

Start from the responsibility to delegate, not from headcount

Before choosing a model, identify what is genuinely missing: a skill, delivery capacity, or technical leadership. Headcount never settles the question. A large team may need steering; a small, well-organised team may simply need an expert on one specific subject.

The useful question is therefore: what can your organisation not carry today? An honest answer avoids hiring three developers when the problem is an absence of decision-making, or installing heavy governance when you simply need two months of capacity.

Expert reinforcement: one skill inside your organisation

This model works when your team knows how to organise the work and validate the results. You keep prioritisation, rituals and delivery responsibility; the expert brings technical command you do not have in-house, or extra capacity for a defined period.

Specify the assignment, the expected seniority, the stack, the availability and the people involved. The profile joins an existing way of working: onboarding time and appropriate access are still required, even for a short assignment. An expert who waits three weeks for access costs you three weeks.

• You keep control over priorities and validation.
• Ramp-up is fast, and so is the exit.
• Success depends on your ability to frame the work.

The part-time CTO: decisions and trajectory

The CTO works on technical strategy, architecture, priorities and organisation. This does not replace development capacity: the role decides, arbitrates, structures and makes choices readable for management and for the teams alike.

The mandate must state which decisions the CTO carries, which teams they support and how often you meet. A shared roadmap makes the work observable: without one, the role dissolves into meetings and the benefit becomes invisible after three months.

The squad: collective delivery capacity

A squad combines skills and leadership over a defined scope. It takes charge of delivery, with a technical lead who organises the work, settles day-to-day choices and reports back. It is the model that delegates the most, and therefore the one that requires the most precise framing.

Define the product owner role on your side, the acceptance criteria, the dependencies and the demo cadence. A dedicated team still depends on a clear backlog and on reachable decisions: a squad waiting two weeks for a validation produces debt, not value.

The questions to ask before starting

Whatever the format, the same questions prevent an essential responsibility from falling between two teams. Ask them before signing, not at the first incident.

1. Who prioritises the work, and against which criteria?
2. Who decides on the architecture, and how far does that mandate go?
3. Who accepts a release, and within what timeframe?
4. Who handles external dependencies and access?
5. Who keeps the sources, the documentation and the secrets?

The three models often combine over time: an expert to get past a milestone, a CTO to set the trajectory, then a squad to deliver. What matters is not choosing once and for all, but knowing at every stage who carries what.

An engagement model is not chosen from an org chart, but from the list of what you no longer want to carry alone.