Written by Technical Team | Last updated 21.10.2026 | 17 minute read
Large NHS digital programmes are usually good at measuring delivery capacity. They know how many engineers are assigned, how many squads exist, how many roles remain unfilled, how much of the budget has been committed and whether a supplier is delivering the number of people it promised.
Those measures are necessary, but they can create a false sense of control. A programme can have a hundred people and still lack the capability to solve one of its most important technical problems.
The distinction is easiest to see in areas such as interoperability, identity, clinical safety, national service integration, EPR connectivity, data migration and large-scale platform architecture. Adding more people can increase throughput once the problem is understood. It does not necessarily improve the programme’s ability to understand the problem in the first place.
A team might have twenty developers but nobody who has designed a high-volume event-driven integration across NHS organisational boundaries. It may have several architects but nobody who understands the operational characteristics of the clinical systems being integrated. It might have a substantial testing function but limited experience of failure modes involving delayed, duplicated or out-of-order clinical data.
The programme has capacity. What it lacks is capability.
Capacity is relatively straightforward to model when the work is well understood. If an NHS team has an established architecture, a stable backlog, clear interfaces and mature engineering practices, another competent developer may increase throughput. More test engineers may increase test execution. More delivery managers may allow additional workstreams to run in parallel.
There are limits because larger teams create more communication and coordination overhead, but the underlying idea is sound.
Capability behaves differently.
Consider a national service that needs to exchange patient information with multiple local systems. The implementation might initially be described in familiar terms: build an API, transform the data, authenticate the caller, persist some state and pass the result downstream.
The hard work usually sits underneath that description.
What happens when two systems disagree about patient identity? Which identifier is authoritative? What happens if the local system has stale demographic information? Can a failed transaction be replayed safely? What if the receiving service processed a request but the acknowledgement was lost? What happens when a message arrives twice, or when updates arrive out of sequence?
Those are not simply coding questions.
They involve distributed systems design, NHS data standards, operational behaviour, local clinical system constraints and sometimes clinical risk. Someone needs to understand the interaction between those areas well enough to make a design decision that will still be safe and operable when the service is handling real traffic.
The same applies to integrations using FHIR. A programme can have a large engineering team and still run into problems if nobody has sufficient depth in healthcare interoperability.
Using FHIR does not remove ambiguity. Teams still need to agree profiles, resource boundaries, identifier semantics, terminology, extensions, cardinality and the treatment of absent or uncertain data. Two systems can produce perfectly valid FHIR resources while representing materially different meanings.
An experienced engineer tends to look for those problems early. They will ask for real payloads rather than relying on interface specifications alone. They will compare values across systems, environments and organisations. They will look for local codes, inconsistent identifiers, unexpected optionality and assumptions hidden in implementation guides.
That activity can appear slower than simply assigning more developers and starting implementation.
In practice, it often removes weeks or months of rework.
This is the central difference between capacity and capability. Capacity is the ability to process more known work. Capability is the ability to recognise, understand and solve a class of problem correctly.
The two should not be confused.
A useful test is to ask what would happen if the programme doubled the number of people assigned to a problem.
If doubling the team is likely to reduce delivery time substantially, capacity is probably the main constraint.
If twenty people would spend longer discussing the same architectural uncertainty, the constraint is probably capability.
NHS digital transformation depends on more than delivery capacity. Large NHS technology programmes also need the right technical capability in areas such as healthcare interoperability, FHIR integration, EPR connectivity, identity, clinical safety and platform architecture. Increasing headcount can accelerate well-understood work, but it will not resolve architectural uncertainty or specialist knowledge gaps. The most effective programmes identify these capability needs early and apply experienced technical expertise before key design decisions become costly to change.
The most difficult parts of NHS technology programmes often sit at boundaries rather than inside individual applications.
Those boundaries may be between systems, suppliers, organisations, data models, clinical workflows or ownership structures.
A web application built inside a single organisation may have clear control over its database, deployment environment and user journey. A national NHS service rarely has that luxury. It may depend on systems operated by NHS England, Trusts, ICBs, primary care suppliers, identity providers, messaging infrastructure and third-party clinical platforms.
Each boundary introduces assumptions.
An API might be technically available but behave differently across environments. A clinical system may support the same standard through several implementation variants. A Trust may configure an EPR differently from another Trust running the same product. An identifier that looks globally unique may only be unique inside a particular namespace.
Even apparently simple national integrations can contain complex operational behaviour.
Suppose an NHS service receives events from hundreds of organisations and sends them to downstream consumers. The happy-path code may be straightforward. Production behaviour is defined by the failure cases.
If a downstream service becomes unavailable, should messages be retried immediately? Should they be queued? What is the retry policy? What happens after six hours of failure? What happens when the downstream service recovers and several million queued events begin processing at once?
A naive recovery strategy can create a second incident.
If every worker retries aggressively, the recovering dependency may be overwhelmed. If retry intervals become too long, clinically relevant updates may remain delayed after the service itself is healthy. If retries are unbounded, permanent failures may consume resources indefinitely.
Then there is duplicate processing.
A request may reach a receiving system successfully while the response is lost because of a network failure. The sending system sees a timeout and retries. If the receiving operation is not idempotent, the retry may create a second record.
A technically simple integration has now become a problem involving acknowledgement semantics, idempotency, durable state, retry behaviour and reconciliation.
The same principles apply when integrating with GP systems, EPRs or national APIs.
An engineer who has worked extensively with healthcare integrations will often ask questions that a generalist team may not initially consider. What happens if the patient’s demographic details change between requests? What if an NHS number is corrected? What if a source system sends a local identifier where the receiving system expects a national identifier? How is provenance retained after transformation? Can an operator trace the source of a clinical value after it has passed through several systems?
Those questions are not evidence of unnecessary caution. They are part of designing an integration that can be supported in production.
Capability is particularly important where a technical decision interacts with clinical workflow.
A delayed record update may not look serious from an infrastructure perspective. CPU utilisation is normal, containers are healthy and APIs are returning 200 responses. But if a clinician is making a decision based on information that should have been updated ten minutes earlier, the service may be operationally healthy and clinically problematic at the same time.
Monitoring only the technology is not enough.
Teams need to understand what successful service behaviour means in the context of healthcare delivery.
Capability gaps become harder to see as NHS programmes grow.
Large programmes need abstraction. Resource plans classify people as software engineers, solution architects, delivery managers, business analysts, product managers, testers and service designers. Commercial arrangements often reinforce those categories because people are bought and reported against defined roles.
The abstraction is useful for programme management but dangerous when it creates an assumption of interchangeability.
Six architects are not necessarily six units of identical capability.
One may have deep experience of identity and access management. Another may specialise in cloud infrastructure. A third may understand NHS interoperability and national services. Another may be strongest in application architecture.
If the programme’s immediate problem concerns clinical terminology, event-driven interoperability or integration with a particular class of healthcare system, a spreadsheet showing six architects does not tell you whether the required capability exists.
The same problem occurs with engineering.
Two senior developers may be equally capable software engineers while having very different experience relevant to an NHS programme. One may be highly effective at building transactional web services. The other may have spent several years operating messaging platforms where data crosses organisational boundaries and messages can be delayed, duplicated or replayed.
Neither is inherently better. They solve different problems.
Large teams can also make capability gaps less visible because activity continues around them.
Stories are completed. Sprint velocity looks reasonable. Services are deployed. Architecture meetings take place. Documentation is produced.
Meanwhile, the difficult decisions accumulate around the edges.
A data migration has unresolved semantic differences between source and target systems. An integration depends on assumptions that have never been tested against production data. A service has logging but no reliable reconciliation process. Clinical safety concerns are being managed through documentation rather than design changes.
The programme looks busy, but some of its most important risks are not reducing.
This is often the point where programmes respond by adding governance.
Additional design boards, assurance processes and approval gates can sometimes help, but they do not create technical capability.
In fact, they can make the problem worse if a small number of genuinely experienced people become responsible for reviewing increasingly large amounts of work. Those people spend their time attending meetings, approving designs and resolving escalations rather than working with teams early enough to shape the solution.
They become bottlenecks.
The programme may conclude that architecture is slowing delivery, when the underlying problem is that too much of the programme depends on too little relevant expertise.
A better response is usually to place capability closer to the engineering work.
A useful delivery model starts with the technical characteristics of the programme rather than a standard team template.
Different NHS services require different concentrations of expertise.
A relatively self-contained public-facing service may be delivered effectively by a conventional multidisciplinary product team. A national integration platform serving hundreds of organisations has a different capability profile. A major EPR migration has another. A data platform processing national healthcare datasets has another again.
The first step is to identify decisions that will be expensive to reverse.
For an integration-heavy programme these may include data ownership, canonical models, identity, interface contracts, event semantics, API versioning and failure recovery.
For a national platform they may include workload partitioning, tenancy models, resilience boundaries, observability, deployment architecture and operational ownership.
For systems handling clinical information, teams need to understand how technical behaviour maps to clinical risk. That work cannot sensibly be left until the end of delivery as an assurance exercise.
Once those areas are identified, the programme can map capability against them.
This does not require a complicated framework. A simple capability assessment can establish:
The result is much more useful than simply knowing whether every role on the resource plan is filled.
The timing of specialist involvement matters as much as the amount.
An interoperability specialist reviewing a completed design after several teams have started implementation has limited leverage. The same person involved while identifiers, resource models and failure semantics are being defined may prevent months of later rework.
The most valuable intervention is often small.
A specialist may spend several days helping a team define an integration pattern, build a reference implementation and test it against realistic failure conditions. Once the pattern is understood, the wider engineering team can implement subsequent integrations without continuous specialist involvement.
This is a better use of scarce expertise than placing the same person permanently into a governance function.
Good programmes use senior specialists to create leverage.
They establish patterns. They expose hidden assumptions. They solve the genuinely unfamiliar parts of the problem. They review difficult decisions and help the surrounding team acquire enough understanding to continue independently.
This is particularly effective in NHS programmes where the same types of boundary recur.
A programme may need to connect to several EPRs or local systems. The first implementation may require deep investigation. By the third or fourth, much of the technical pattern should be understood.
The capability has moved from an individual into the programme.
Code review can be used in the same way.
A superficial review asks whether the code follows the expected style and has enough tests.
A capability-building review asks why the system behaves the way it does.
Why is this operation retried? What guarantees that the operation is safe to repeat? What happens if the database commit succeeds but the message acknowledgement fails? How does an operator distinguish a temporary downstream outage from a permanently invalid clinical payload? Can the transaction be reconciled independently of the normal processing path? How would this interface evolve if another consumer needed different information next year?
Those questions transfer engineering judgement.
Documentation should do the same.
Architecture decision records are much more useful when they capture constraints and rejected options rather than merely recording the technology selected.
“Use Kafka” provides little reusable knowledge.
“Use durable asynchronous messaging because producers and consumers are operated independently, downstream availability cannot be guaranteed, consumers require independent scaling and the programme has accepted eventual consistency” tells future teams why the architecture exists.
The reasoning is the capability.
Production is where the gap between capacity and capability becomes most obvious.
A large team can build a service that passes functional testing and still struggle to operate it effectively.
Consider an NHS integration service processing transactions for many organisations. Standard infrastructure monitoring may show CPU, memory, pod health, request latency and error rates.
Those measures are useful but insufficient.
The operational team also needs to know whether the service is processing the volume of healthcare transactions expected. It needs to know the age of the oldest unprocessed message, whether particular organisations are experiencing failures, whether one message type is deteriorating and whether data entering one side of the system is successfully emerging from the other.
A service can have perfectly healthy infrastructure while silently failing its purpose.
This is why experienced platform and integration engineers tend to design observability around service behaviour rather than infrastructure alone.
They introduce correlation identifiers that survive system boundaries. They monitor queue depth and message age. They distinguish transient technical failures from permanent data-quality problems. They build reconciliation processes that independently compare expected and actual outcomes.
They also design for recovery.
A dead-letter queue is not a recovery strategy.
Someone must decide why messages enter it, how they are classified, who owns them, what information an operator needs to diagnose them, whether they can be safely replayed and what happens when thousands accumulate.
The same applies to certificates, credentials and external dependencies. A production service that depends on NHS infrastructure needs clear visibility of certificate expiry, API quota behaviour, network dependencies and operational ownership.
These are engineering decisions, not housekeeping.
Teams acquire this capability by operating real systems and learning from failure. It is difficult to reproduce simply by increasing headcount.
That does not mean programmes should rely indefinitely on a handful of experienced individuals.
The aim should be to use experience to improve the operating model of the whole team.
Incident reviews should identify missing engineering controls rather than simply human mistakes. If an outage was difficult to diagnose because correlation IDs were missing, add them. If replaying messages required direct database changes, build proper tooling. If only one engineer understood how to recover the service, turn that knowledge into automation and runbooks.
Over time, good operational capability becomes encoded in the system.
Capacity remains essential. NHS programmes cannot deliver without enough engineers, designers, testers, product people and delivery professionals. Deep specialists are not substitutes for functioning multidisciplinary teams, and treating every technical problem as specialist work creates unnecessary dependency.
The useful skill is diagnosing the actual constraint.
If the architecture is understood, the interfaces are stable, the engineering patterns are established and the backlog consists largely of implementation work, more capacity can help.
If teams are repeatedly reopening fundamental decisions, discovering unexpected behaviours late in testing, escalating the same technical questions or depending on a small number of people to rescue difficult work, the issue is unlikely to be solved by simply adding more people.
The programme needs capability in the area causing the uncertainty.
Large NHS technology programmes are particularly susceptible to confusing the two because their scale makes headcount highly visible. A programme can see that it has 120 people. It is much harder to see that only two of them have previously solved the specific interoperability, identity or operational problem on which an important workstream depends.
The strongest delivery organisations treat those as different dimensions.
They maintain enough capacity to deliver sustained volumes of work, but they also understand where deep experience is needed and make sure it is available before the relevant decisions become expensive to change.
The result is not a programme dominated by specialists. It is usually the opposite.
Small amounts of relevant expertise, applied early and close to the engineering work, allow much larger teams to move faster and make better decisions independently.
That is the practical difference between delivery capacity and delivery capability. One determines how much work a programme can attempt. The other determines whether the programme can solve the difficult problems hidden inside that work.
How should NHS digital programmes assess technical capability when selecting suppliers?
NHS digital procurement should assess relevant delivery experience as well as supplier size, day rates and available headcount. Evaluation criteria can test whether proposed specialists have previously delivered comparable NHS technology programmes, worked with the required standards and platforms, and can demonstrate how they solved similar technical risks. Requiring named expertise, evidence from previous projects and scenario-based technical evaluation can make supplier capability easier to distinguish from simple resource availability.
What technical capability should be included in an NHS digital programme business case?
A digital business case should consider the specialist skills required to build, operate, secure and eventually change the service throughout its lifecycle. This can include architecture, cyber security, data engineering, service management, accessibility, clinical informatics and technical leadership alongside core software delivery. Including these requirements early helps expose capability costs that might otherwise emerge after procurement or implementation has begun.
How can NHS organisations avoid becoming dependent on technology suppliers?
NHS organisations can reduce supplier dependency by retaining enough internal technical knowledge to make informed architecture, commercial and service-management decisions. Contracts can also require usable documentation, knowledge transfer, open standards, accessible operational data and appropriate exit arrangements. This makes it easier to change suppliers, bring services in-house or evolve NHS digital services without losing critical knowledge.
What is the relationship between technical capability and technical debt in NHS digital transformation?
Insufficient technical capability can make technical debt harder to recognise and manage because short-term delivery decisions may create long-term constraints that are not immediately visible. NHS digital transformation programmes should therefore consider maintainability, upgrade paths, unsupported technology, automation and future integration when evaluating technical decisions. Managing technical debt as an ongoing investment concern can reduce the risk of creating tomorrow’s NHS legacy systems.
Should NHS digital programmes build specialist capability internally or buy it from suppliers?
Most large NHS digital programmes benefit from a mixture of permanent internal capability and external specialist expertise. Capabilities needed continuously to govern, operate and evolve important NHS services are strong candidates for internal ownership, while rare or temporary expertise may be more economical to obtain externally. The key question is whether the NHS organisation will retain enough knowledge and decision-making capability after the supplier or specialist leaves.
Is your team looking for help with technology delivery? Click the button below.
Get in touch