Delivering digital service: this much I have learned

The year is 2000. I am a product manager. I’ve worked with designers and a usability specialist to specify a new feature for a consumer news service for a major telecoms operator. But what comes back from engineering is unrecognisable. It doesn’t work as we specified. Worse than that, the engineers have added all sorts of extra bells and whistles that go counter to what I thought was our vision for the product. And we’re already late launching it to users.

Of course the fault was mostly mine. I had not made my expectations clear enough.

I remember hammering out a lengthy email appealing for transparency, some sense of shared strategy, a way to bridge between the big picture and the details as delivered. What if, instead of all this paperwork and reporting, we worked together as one team?

It turns out that I wasn’t the only person who was frustrated, because over the years our industry has got much, much better at delivering digital services. I’ve been privileged to work with high-performing teams that have both the trust and the tooling to do their best work.

Sadly the good practice isn’t evenly distributed, and I sometimes find myself feeling the same frustration rising as it did that day almost 20 years ago.

I try not to take it out on people. This stuff isn’t complicated, but neither is it obvious. As a digital profession lead, I often find myself arguing for little bits of this model in isolation. In this post, I’m trying to draw together the threads of good practice as I see them.

20+ years in digital services delivery, this much I have learned…

1. Look after the water

Openness, user-centricity, mutual respect, and trust are all preconditions for good work at pace. Get them right, and they work as a virtuous circle of productivity. When the same forces go into reverse, delivery capacity drains away in a vicious downward spiral. As a family friend who runs an aquarium once told me, if you look after the water, the fish will take care of themselves.

When we put our trust in motivated people, they repay it many times over. If we fail to give them the freedom to act, we are wasting their human potential, not to mention the public money we pay them. I know from training hundreds of civil servants that most people already have it in them to work in a dramatically more productive way. We just have to change their context.

Trust and respect at work are reinforced when people have shared professional standards. For the work that we do in digital health, the core professional skills required are best captured in the community-led, open-government-licenced, Digital, Data and Technology (DDaT) Framework. A particular strength of this framework is that it defines a range of complementary roles proven to work well together. Two roles in particular – user research and content design – hardly existed in their current form before DDaT, and are now among the top 15 emerging roles in the UK, according to LinkedIn.

A couple of caveats: Shared norms must not come at the expense of diversity. If our teams looked more like our users, our products and services would be more likely to meet user needs. Neither is having a team of specialists a substitute for involving users directly in design and delivery. Engaging confidently with the people who use, deliver, and benefit from a service ought to be a core competency for all digital roles.

2. See the wood for the trees

People do their best work and collaborate most effectively when inspired by big, audacious goals. Luckily in health and care, we have no shortage of those. Five years of extra healthy life expectancy by 2035, anyone?

Starting work on anything without everyone having a shared understanding of the big picture is incredibly risky. It means we have to rely on a tiny number of over-stretched senior leaders to understand objectives and commitments. Then they run themselves ragged trying to task-manage everyone else to deliver. As a leader, prepare to stop giving instructions and start giving intent. Your people will work out what needs to happen next.

Even when working towards shared outcomes, a common mistake is “big design upfront” – trying to second-guess solutions when we know the least about the problem. No one at the centre can predict the perfect structure. No policy of sufficient complexity can be delivered by a single programme of change, chunked up into workstreams, milestones fixed and marched towards unthinkingly. On all but the very simplest delivery, responding to change always trumps following a plan.

We have to take an empirical approach, tightening the feedback loop of making, testing and learning. Benefits assumed without a constantly updated empirical basis are likely to prove expensively illusory.

3. Small pieces loosely joined

Empiricism becomes easier to execute if we learn from the architecture of the Internet: small pieces loosely joined. The flexibility afforded by this principle liberates people anywhere in the system to identify a user need, and stitch together multiple experiments to find the best way to meet it.

By getting really good at releasing little changes very frequently, and designing out dependencies between different services and teams, we enable continuous improvement and continuous learning. In a perpetually changing world, the most sensible sort of learning is learning by doing.

I reckon this feature of the modern digital operating model is the one that is hardest for people to understand if they haven’t experienced it. Having been with services that went from releasing in months to releasing in minutes, I never want to go back.

4. Trust in multidisciplinary teams

One of the most powerful ways to minimise risky handoffs and safely accelerate pace is to populate each team with all the skills needed to accomplish a task. Medicine already knows this; much of the literature about multidisciplinary teams comes from healthcare.

Point 6 of the Government Service Standard is: “Have a multidisciplinary team.” In digital service delivery, this means all the roles from research and design through to development and release.

But we shouldn’t stop at the digital, data, and technology roles. If your work comes with a high policy impact, put a policy person in the team. If the clinical risk is high, embed a clinician. Working with legal and regulatory constraints? Give the team frequent access to a lawyer!

Because they have the skills they need, and fewer interdependencies, multidisciplinary teams can be given freedom to choose their tools and how they get things done. Each team will develop ways of working that make it more productive at the type of tasks it takes on. Some of these habits remain unique to one team, others emerge as de facto standards that other teams can pick up and integrate into their own working practices.

Teams that work together, with aligned autonomy, are accountable together. They take pride in their work, use testing to drive their development, and deliver a consistently high quality product or service day-in-day-out. When working in health and care, technical excellence and clinical safety go hand-in-hand.

Customers, suppliers and other third parties have much to gain by participating in this way too. Even the largest organisation relies on others to get stuff done. The suppliers who can’t yet work like this may need some support. The ones who won’t work like this represent a risk to themselves and others; they must be managed closely.

5. Connective tissue

So how to bridge the divide between those big audacious goals and the small pieces loosely joined? That’s where service design and product management come in.

By mapping user journeys, we start to understand the shapes of the whole services that we deliver – not just the digital bits – and the contexts in which they take place. These probably don’t map to any of our organisational silos, so every team needs to be aware of them and contribute to making them better. As Lou Downe says, good services are verbs – time to bin all those acronyms.

Product managers are the central nervous system, connecting the big ambitions, and system-level outcomes, to the myriad little decisions taken in and around each multidisciplinary team. What should we work on next? What do we need to learn? What can we release now that will help us to start learning and delivering value to our users more quickly?

Product visions, strategies, missions, roadmaps, and backlogs become the shared artefacts around which decisions can be made. The continuous process of updating these artefacts can be tapped into to steer work in the right direction, and assure leaders that teams are making progress.

Product managers whose teams have a track record of delivery are also powerfully placed to shape higher-level strategies and propose user needs-based public commitments that they can show to be both valuable and achievable.

A product is for life. The team that builds a product should expect to stick around, and be properly funded, to maintain it. That’s one of the most important differences between the product and project mindsets.

When they release any element of a service to users, the team must make sure it is well instrumented to measure and report its own performance. They will use this to inform continuous improvements, and to make sure that they are achieving the system-level outcomes they hoped for.

Finally, budgets, costs, and financial controls can only be meaningful if they are reviewed and refreshed frequently in response to product management artefacts and actual performance. (I lost several months to a 5-year multi-country business case for mobile apps, repeatedly torturing a tottering tower of assumptions until it gave my vice president the fictitious answer he wanted. I’m never doing that again.)

6. Scaling out

Each person working in a multidisciplinary team needs professional supervision and support to develop in their chosen role. As digital delivery expands, a common pattern is for several multidisciplinary teams to report into a multidisciplinary leadership team. In an echo of the self-sufficiency of the teams they manage, multidisciplinary leadership teams should have all the skills needed to assure the work.

Communities of practice give us added resilience, building professional collaborations and working relationships that will likely outlast many corporate reorganisations. Reporting lines are ephemeral, community ties more enduring.

Sooner or later, after iterating on a product for a while, many teams reach the point where it would be more valuable for them to work on something else. Instead of disbanding the team and writing off all that social capital, we should keep teams together and let them gravitate, guided by their product managers, to the work that has the most value.

All the above adds up to a coherent model of governance and control – not by predicting everything upfront, but by working together in a disciplined manner, to achieve shared objectives, based on a growing body of evidence. After everything I’ve learned, I wouldn’t risk doing digital service delivery any other way.

7. I Am Not Making This Up

Maybe you’re reading this and saying it’ll never work. It’s true that much of this way of working seems counter-intuitive. When things are going wrong, there’s a powerful instinct to close down, take back control, and revert to old habits.

Here’s the thing: all the stuff I’m talking about is already happening, across the public sector, in start-ups and enlightened corporations around the world.

• Read Steve Messer on blogging and working in the open
• Watch Dan Pink on the science of intrinsic motivation
• Check out LinkedIn’s list of the top 15 emerging roles in the UK
• Read Kit Collingwood on Why civil servants should become experts in empathy
• Watch David Marquet tell the story of how he and his crew turned the ship around
• Dig into this treasure trove of posts about user research by Leisa Reichelt
• Read the NHS Long Term Plan aspiration for a new service model for the 21st century
• Watch Henrik Kniberg’s 2-part video on Spotify engineering culture
• Read Iain Maxwell’s blog post Is Test Driven Development Right for You?
• Read this interview with NHS Business Services Authority Chief Digital Officer Darren Curry
• Look up the Government Service Manual guidance on the team
• Watch Christina Wodtke’s Mind the Product Keynote on Teams
• Get yourself a copy of Lou Downe’s Good Services
• Compare service mapping at the Department for Education and Tero’s approach in health and care
• Browse the Digital Urgent and Emergency Care discovery weeknotes
• Refer to Scott Colfer’s Product Management Handbook for Digital Government
• Download a host of product management tools from Roman Pichler
• Consider the Beyond Budgeting principles
• Look up Emily Webber’s research on successful communities of practice
• Find out how Defra Digital is funding product teams not projects
• And please tell me what I’m missing.