What options can organisations use to increase engineering capacity?

Recruitment is only one response to insufficient engineering capacity. It may be the right response when demand is enduring and internal ownership matters, but it will not solve every bottleneck and it takes time to produce effective capacity.

A responsible decision begins with the outcome and the constraint. It then compares options on the same basis, including time to effect, skills, integration, control, knowledge retention, reversibility, operational responsibility and total cost.

Reduce demand and improve the delivery system

The fastest capacity may come from stopping or sequencing work that does not support the most important outcomes. A team with ten simultaneous priorities is not necessarily under-resourced; it may be overcommitted. Narrowing work in progress can shorten feedback and reveal whether more supply is still required.

Remove repeated friction. Better automated tests, deployment, observability, documentation, environments and reusable platform services can release time across many changes. Simplifying a product or retiring an expensive component may remove continuing operational demand. These investments have costs of their own, so connect them to observed delays and product needs.

Changing the system is not a reason to avoid legitimate recruitment. It prevents an organisation from placing more people into the same queues and complexity without understanding the likely result.

Build enduring internal capability

Develop existing people when the capability is strategically important and demand will persist. Pairing, coached delivery, communities of practice and access to real customer and operational evidence can build both skills and organisational context. Internal mobility may bring domain knowledge that external hiring cannot provide immediately.

Recruit permanent engineers when ownership, continuity and long-term product knowledge matter and the expected demand supports the commitment. Consider the full path to capacity: attraction, assessment, notice periods, onboarding, management and the time experienced colleagues spend transferring context.

Permanent teams still need access to specialist expertise. A small enabling group, internal platform or temporarily embedded specialist may remove a constraint across several products more effectively than duplicating a rare skill in every team.

Use external capacity with explicit boundaries

Contractors can provide individual skills or temporary flexibility. A delivery partner can supply a team, specialist capability or outcome-focused service. Commercial products may replace work that does not differentiate the organisation. Each option changes control, coordination, dependency and knowledge-transfer needs.

External people should work with the product team rather than receive a fixed specification through a separate chain. Define decision rights, technical standards, access, security, operational ownership and the knowledge that must remain internally. GOV.UK guidance recommends identifying the skills needed, integrating contractors with permanent staff and planning knowledge transfer.

Compare total cost and exit conditions, not only day rates. Include procurement, oversight, integration, licensing, change, support and the cost of switching. Avoid long commitments before the problem and delivery approach are sufficiently understood.

Test AI as an additional capacity source

AI assistance can support coding, testing, analysis, documentation and other engineering tasks. Agent-enabled tools may undertake larger bounded sequences. Their useful capacity depends on task suitability, context, feedback, permissions and human review. Output that creates more checking, rework or risk is not free capacity.

Start with real demand and a controlled comparison. Define the baseline, expected outcome, quality and security guardrails, human effort and stop conditions. Observe end-to-end flow rather than only time spent generating code. Current DORA research characterises AI as an amplifier of the surrounding organisational system, which supports investing in technical and cultural foundations alongside tools.

Combine options deliberately. An internal team might improve its deployment path, use a specialist partner for a migration and trial AI assistance on well-tested maintenance work. Review whether each intervention builds durable capability or creates a dependency, and change the mix as demand and evidence evolve.

Example

A financial-services firm needs to modernise a customer portal while maintaining its existing service. It first stops two low-value enhancements and automates a slow release check. It recruits for enduring platform ownership, brings in a partner with migration experience under an explicit knowledge-transfer plan, and trials AI assistance on bounded test creation.

Leaders review lead time, production quality, internal ownership, cost and human oversight. The mix provides earlier capacity while leaving the organisation able to operate and evolve the platform after the partner exits.

FAQs

• Should we improve productivity before hiring more engineers?

  Diagnose the constraint first. Flow improvements may release capacity and make recruitment more effective, but they should not become an indefinite demand for existing teams to absorb genuinely excessive work.

• When is a delivery partner preferable to contractors?

  A partner may suit a bounded outcome requiring a coordinated mix of skills, while contractors may suit specific roles integrated into an existing team. The contract, internal ownership, operational model and knowledge-transfer needs matter more than the label.

• Is buying software a form of engineering capacity?

  It can avoid building and maintaining a commodity capability, releasing attention for other work. The organisation still needs capacity for selection, integration, assurance, operation, supplier management and future change.