The epistemological tension
Programme management in the public sector - and in the NHS in particular - is structured around accountability, milestone delivery, and risk reduction. These are not arbitrary cultural preferences; they emerge from real institutional pressures that the public sector faces in ways that the private sector largely does not. Political accountability cycles require demonstrable progress at regular intervals. Treasury spending controls demand predictable cost profiles. Clinical safety obligations impose rigorous change management. Audit requirements necessitate documented decision trails. The culture that results from these pressures rewards certainty, predictability, and the ability to report upward with confidence; it does not reward exploration, ambiguity, or the patient holding-open of questions.
Designers, by contrast, are trained to treat uncertainty as a resource. The double diamond, whatever its limitations as a literal description of practice, captures something genuine about the epistemological orientation of design: that the problem space must be explored before the solution space can be meaningfully entered, and that this exploration will surface needs and possibilities that were not visible from the commissioning brief. Malmberg (2017) identifies this directly: the culture associated with design "differs in many ways from that of a public sector organization", and the social capabilities required to bridge these differences are not trivial.
This creates a genuine tension that cannot be resolved by simply explaining design to programme managers, or by designers learning to write better status reports. The tension is epistemological: programme managers need to know what will be delivered and when; designers need to discover what should be delivered at all and explore iteratively and often experimentally - when it involves exploring new creative possibilities - what might work better or deliver greater value. Both orientations are legitimate responses to real constraints. The programme manager is not being obtuse when they ask for a delivery date; they are managing genuine political and operational risk. The designer is not being evasive when they resist committing to a specification; they are trying to prevent the organisation from building the wrong thing, particularly when working to an arbitrary deadline or working with incomplete or inadequate information.
What programme management is optimised for
The temptation, for designers entering programme management cultures, is to frame the mismatch as a deficit on the programme management side. They do not understand design. They do not value research. They are too process-driven, too risk-averse, too focused on governance at the expense of outcomes. But this framing potentially misses what programme management is actually doing, and why it exists.
Programme management is an institutional response to coordination under political accountability. Large public sector initiatives involve multiple organisations, multiple funding streams, multiple ministerial interests, and multiple failure modes. The programme structure - with its boards, its gateway reviews, its RAG ratings, its highlight reports - is a coordination mechanism that allows senior leaders to maintain oversight without understanding every technical detail. It is, in Drummond's (2021) terms, an organising structure that shapes what can be seen, decided, and acted upon; and it has been shaped, over decades, by the specific failure modes that the public sector has experienced. The catastrophic failures of programmes like NPfIT taught the NHS that insufficient governance is more dangerous than excessive governance; the institutional response was, predictably, more governance.
Cooper (2019) frames this at a different scale: the job of governance is to "serve the larger, slower good for society" and to provide stability. This is not a trivial function. In healthcare, the consequences of getting it wrong are measured in patient harm, in public trust eroded, in billions of pounds of public money wasted. Programme management cultures are not hostile to good ideas; they are hostile to unmanaged risk, and design - with its insistence on exploration, iteration, and deferred commitment - looks, from the programme management perspective, like unmanaged risk. Strathern (2003) identifies a deeper structural feature of this orientation: in audit cultures, "what is being assured is the quality of control systems rather than the quality of first order operations". Accountability is discharged by demonstrating that systems of control exist - not by demonstrating good teaching, caring, or service delivery. Programme governance, understood this way, is not merely risk-averse; it is optimised for a different object of evaluation entirely. It checks whether the process was followed, not whether what the process produced is any good.
The designer's entry point
Drummond (2021) identifies a structural problem that compounds the cultural one: "By the time we turn our attention to the 'user experience' of the service we are designing, we are often limited in scope because of decisions that have already been made". This is the familiar pattern of design entering after the significant decisions - technology choice, scope definition, delivery timeline, organisational model - have already been taken. The designer arrives to improve the interface of something whose fundamental architecture was determined by people who were not thinking about users.
This late entry is not an accident; it reflects the programme management assumption that design is a downstream activity concerned with the surface of things. Requirements are gathered, architecture is defined, build begins, and then design "polishes" the output. In this model, design is a quality-assurance function applied to decisions made elsewhere, and the designer's value is measured by how well they can improve the usability of whatever the programme has already committed to building.
The difficulty is that this assumption is sometimes correct. Not every design intervention requires rethinking the problem space. Sometimes the technology choice was reasonable, the scope is appropriate, and what is genuinely needed is someone who can design a coherent interface. The designer who insists on reopening upstream decisions when the downstream work is what matters will rightly be seen as obstructive. The professional skill is distinguishing between cases where the upstream decisions need challenging and cases where they are adequate - and framing any challenge in terms that programme management can hear. As the previous work on deflecting up explores, the temptation to escalate every design concern into a strategic question is itself a form of avoidance.
There is a harder version of this problem, however, in which the upstream decisions are not merely already taken but architecturally locked in. The platform has been procured through a business case that preceded any design involvement; the interface layer is generated by tooling whose output the designer cannot reshape at a fundamental level. As the work on technomagic explores, much of the value realised from public sector technology spending is imagined, or pre-determined far in advance of the point of delivery, locked into contracts and procurement decisions before the design work that might have identified different forms of value, or fundamentally different solutions has been done. The later post on infrastructuring documents what this looks like in practice: a low-code platform that generates markup the designer cannot control, where the gap between what the platform produces and what a public sector accessibility standard requires is not a bug to be reported but a structural condition of the procurement. In these cases the designer's professional judgement about what the upstream decisions need is beside the point; the design material will not yield. The question becomes whether to build workarounds that the programme's governance may not recognise as necessary, or to accept that the design intervention available is genuinely limited to what the fixed material permits - and to be honest about that limitation rather than performing a broader influence that the platform forecloses.
The accountability asymmetry
There is a further structural issue that shapes how designers experience programme management cultures: accountability is asymmetric. The programme manager is accountable for delivery. If the programme is late, over budget, or fails to meet its milestones, the programme manager bears the consequences. The designer, by contrast, is rarely held accountable for delivery failure in the same direct way; their accountability is more diffuse, more qualitative, harder to measure. This asymmetry creates a rational basis for programme managers to resist design-driven changes that introduce uncertainty into the delivery timeline. The programme manager who agrees to "hold the problem space open" for another sprint cycle is taking on personal risk; the designer who advocates for it is not.
Shore and Wright (2024) document the longer trajectory of this dynamic: audit culture, which was nominally introduced to promote trust and accountability, has in practice "substituted managerialism and external scrutiny for professional autonomy", creating low-trust organisational environments in which professional judgement is systematically displaced by indicator compliance. The designer's experience of the accountability asymmetry is, in this reading, a specific instance of a broader pattern: the audit regime trusts the metric more than the professional.
Understanding this asymmetry is essential for designers who want to work effectively in programme management cultures. It means that advocacy for design-led approaches must be accompanied by a credible account of how design work will be managed within the programme's accountability structures - not as a separate activity with its own logic, but as a contribution to the programme's ability to deliver the right thing, on time, within the governance framework. Blomkamp (2021) identifies this as a recurring challenge in systemic design practice: ways of working that do not accommodate design-led approaches, combined with limited capacity and capability, create inconsistent and often frustrating conditions for designers.
The next post in this series examines what service design specifically offers programme management cultures that they cannot generate from within their own logic - the cross-cutting view, the ability to make invisible decisions visible, and the temporal perspective that extends beyond the programme's delivery horizon.
References
Blomkamp, E. (2021) Systemic design practice for participatory policymaking. Policy Design and Practice.
Cooper, S. (2019) Are We There Yet?: The Digital Transformation of Government and the Public Sector. Canberra: Department of the Prime Minister and Cabinet.
Drummond, S. (2021) Full Stack Service. Snook.
Malmberg, L. (2017) Building Design Capability in the Public Sector: Expanding the Horizons of Development. Linköping University.
Shore, C. and Wright, S. (2024) Audit Culture: How Indicators and Rankings Are Reshaping the World. London: Pluto Books.
Strathern, M. (2003) Audit Cultures: Anthropological Studies in Accountability, Ethics and the Academy. London: Routledge.