This week I attended a meeting to talk about plans to procure a service – it revealed a truth so obvious that I feel like a real dummy for not figuring it out sooner. ‘Transformation’ is only tangentially about agile vs waterfall, tech and user centred design. It’s really about who takes responsibility for how services are delivered.
This is your captain
The meeting was about plans for a health service pilot. This involves delivering a complex service at national scale, with multiple stakeholders including clinical commissioners, GPs, pharmacies, and behavioural support providers.
The team plan to procure a supplier to run a pilot that combines medical treatment with behavioural support. The plan is to digitise the existing user journey using digital services to reduce capacity burden on the NHS – a sensible approach given the scale of demand they’re facing.
It was a big meeting with experienced people from policy, procurement, clinical and assurance backgrounds, and me representing the digital and user‑centred design perspective. The team are focused on shipping value quickly and not getting mired in rounds of approvals and governance – an urgency I admire and fully support.
As we talked through the approach, I found myself thinking about different aspects of the challenge. The conversation focused on practical delivery questions – technical requirements, procurement timelines, operational constraints. Important considerations for a pilot of this complexity. But I kept coming back to a question that wasn’t being discussed – who owns the whole?
We are about to attempt a crash landing
Later that day, I happened to read this article – Why ‘build vs buy’ is not about tech – it makes the point that ‘build vs buy’ is a proxy for questions about what type of organisation you are and what you’re prepared to take responsibility for. This was a light bulb moment for me.
Everything about the culture of transformation in the public sector comes down to this question of responsibility. How did I not see this before?
Place your tray tables in their upright, locked position
This pilot involves implementing complex services that span multiple domains – clinical, technical, and operational. The team are proposing to outsource the solution to a supplier, rather than owning the complexity of how different parts work together.
I see the allure of outsourcing. It offers speed, certainty and offloads risk. We routinely have meetings where people with slick looking software promise to solve all our problems. If you’ve never been responsible for delivering services, it would of course be better to hand over delivery to experts.
But I suspect this approach will create another siloed journey based around a single condition and treatment. Health conditions aren’t simple or isolated – they connect to multiple other issues and services. Users often need coordinated care across different specialities and providers.
I don’t propose everything is built in‑house. It’s the value chain mapping of it all, what’s important to you and what’s a commodity. Outsource specific capabilities while maintaining accountability for how the parts work together. We need to own the user journey across multiple touch‑points and iterate as we learn.
Put your hands on your head
Taking responsibility for something as large as rolling out a drug that will be used by millions is overwhelming. And maybe too expensive. Maybe it can’t be that government increasingly takes on more and more things.
But what happens when we don’t? Do we keep adding complexity without ever paying it down? New fragments layered on top of old fragments?
In the meeting, everyone brought deep expertise and legitimate concerns about delivery at scale. They understood the risks well, and clinical risk better than I do. We discussed how people were already accessing these drugs through private suppliers and these companies were able to manage risk.
Their perspective is grounded in years of experience navigating the realities of the health system. I felt a bit naive pushing questions about research and iteration when they were focused on the practical challenges of getting something launched.
It was only later, when I read that article about ‘buy vs build’ that I understood my blind spot. How my assumptions made it hard for me to even articulate my biggest concern. This realisation about responsibility versus methodology will fundamentally change how I approach these conversations – not the mechanics of delivery, but who takes responsibility.
Transformation is – how do we meet needs in a way that builds our organisation’s ability to learn, integrate, and own the outcomes for the people we serve?