Choose the delivery model before you choose the team

When a product organisation needs more engineering capacity, the first conversation often moves quickly towards roles, seniority and availability. How many engineers are required? Which skills are missing? How soon can interviews begin?

Those questions matter, but they are not the first decision.

Before choosing the team, the client and delivery partner need to agree how the work will be owned. Otherwise, capable engineers can join a sensible roadmap and still create more coordination, slower decisions and unclear accountability.

The right delivery model establishes who directs the work, who makes technical decisions, who manages execution and who carries responsibility when circumstances change.

Two models can both work

Most external engineering relationships sit somewhere between two clear models.

In a client-led engineering-capacity model, the client interviews and selects the engineers. Those engineers join the client’s existing team structure, ceremonies and tools. The client retains control of the roadmap, priorities, architecture and daily engineering direction. The delivery partner takes responsibility for employment, payroll, HR, support and continuity.

In a partner-led software-delivery model, the client retains product direction and agreed ownership, while the delivery partner accepts responsibility for planning, engineering execution and delivery against defined expectations. Progress is governed through clear review points, decisions and outcomes rather than day-to-day task allocation by the client.

Neither model is inherently better. Each can be effective when it matches the client’s leadership capacity and the nature of the work.

Problems begin when the model is implied

Delivery relationships become difficult when both parties believe they are operating under different assumptions.

A client may think it has commissioned an outcome while the partner believes it has supplied individual engineers. The partner waits for detailed direction; the client waits for delivery leadership. Engineers receive conflicting signals, decisions slow down and accountability becomes harder to locate.

The opposite mismatch is equally disruptive. A client may want direct control of priorities and technical choices, while the partner introduces an additional management layer that filters communication and distances engineers from the people making product decisions.

In both cases, the problem is not primarily engineering capability. It is an unclear operating boundary.

Define four ownership boundaries

Before recruiting or assigning engineers, both sides should define four areas of responsibility.

1. Product direction

Who owns the roadmap, decides what matters next and resolves conflicts between commercial priorities? A delivery partner can advise, challenge assumptions and surface risks, but product direction should remain visibly owned.

2. Technical standards

Who approves architecture, engineering practices, security expectations and quality thresholds? If the client already has established standards, incoming engineers should work within them. If the partner is responsible for delivery, its authority to make technical decisions must be explicit and bounded.

3. Engineering execution

Who converts priorities into plans, coordinates the work, manages dependencies and responds when delivery moves off course? This is often where ambiguity becomes expensive. Execution cannot be jointly assumed and individually avoided.

4. Team continuity

Who manages employment, performance support, replacement planning and the retention of product knowledge? Continuity is not only about keeping the same people. It also requires documentation, shared context and working relationships that can survive change.

These boundaries should be understandable to the engineers doing the work—not only to the people who signed the agreement.

When client-led capacity is the better fit

Client-led capacity usually works well when the organisation already has strong product and technical leadership. The client knows what it needs, has established engineering practices and wants additional engineers to operate directly inside its existing model.

This approach is particularly suitable when the need is for specific roles, a small number of experienced engineers or a complete team that will remain under the client’s daily direction.

The advantage is proximity. Engineers participate in normal communication, receive context directly and remain accountable to the same priorities as the internal team. The client does not surrender control in exchange for capacity.

The model becomes less effective when the client lacks the time or leadership needed to direct the additional team. Adding engineers does not replace missing product decisions, technical ownership or delivery management.

When partner-led delivery is the better fit

Partner-led delivery is more appropriate when the client can define the product objective but wants another organisation to take responsibility for engineering execution.

The work may be a product area, a defined workstream or an end-to-end software initiative. The partner needs enough authority to plan delivery, organise the team, manage dependencies and make agreed technical decisions. The client should still retain visibility through demonstrations, decision records, risk reporting and regular review points.

This model fails when responsibility is transferred without authority, or when authority is granted without transparency. A delivery partner cannot own an outcome while waiting for approval on every operational choice. Equally, a client should not have to lose visibility to obtain accountable delivery.

The operating model must exist in daily work

A contract can describe responsibilities, but the real delivery model is revealed through everyday behaviour.

Who attends planning? Who can change priorities? Where are architectural decisions recorded? Who speaks directly with engineers? Who responds when delivery is at risk? How are replacements handled without losing critical context?

If the answers differ from the written agreement, the practical operating model will eventually override the contractual one.

Clear communication paths, decision rights and escalation routes make responsibility visible. They also reduce the amount of coordination required from senior client leaders, because teams know where decisions belong.

The model can change—but the change must be explicit

An engagement does not need to remain in one model forever.

A client may begin with partner-led delivery while establishing a new product capability, then move towards direct leadership as its internal organisation matures. Another client may initially manage a dedicated team directly, then ask the partner to take ownership of a defined workstream.

Either transition can work. What matters is that responsibility is deliberately transferred. Roadmap ownership, technical authority, delivery expectations and reporting should be restated rather than allowed to drift.

Decide before the first interview

Before discussing individual candidates, leaders should be able to answer five questions:

1. Who owns product direction?
2. Who makes and records technical decisions?
3. Who manages engineering execution each day?
4. What outcome is the team accountable for?
5. Who protects continuity when people or priorities change?

If those answers are clear, team selection becomes more precise. The client can assess engineers against the environment they will actually join, and the delivery partner can provide the support the model genuinely requires.

At NGBS, we treat this choice as an operating decision rather than a packaging exercise. Some clients need engineers who become part of their existing team. Others need NGBS to take responsibility for software delivery. Clarity about that distinction creates a stronger foundation than headcount alone.