Internet-era ways of working

Tom Loosemore (@tomskitomski)

October 12, 2018

From public.digital

An earlier draft of this list, stuck to the PD office door

Our definition of digital says: "Applying the culture, processes, business models & technologies of the internet-era to respond to people's raised expectations."

Once they've heard that, the next thing people always ask us is: "OK. But how? How do I make that happen in my organisation?"

Good question.

We've spent a lot of time thinking about the answer to that. Between us, we've collectively made a lot of mistakes over the last 20+ years of digital delivery, and learned from every one of them. We think the answer looks something like this: a todo list for putting internet-era ways of working into action.

Some of this will sound familiar to those of you who know the UK government design principles. You could think of those as an earlier iteration of this list. Now we've moved beyond the UK government and started working internationally, and with non-government institutions, we're noticing how many people understand the design principles, but want help on how to put them into practice.

So we don’t intend this list to be a replacement for the design principles. It's more like a new branch of the repository. Clearly, there's further iteration to come.

Internet-era ways of working

1. Design for user needs, not organisational convenience

• Use insights from ongoing, embedded user research as your guide; make user research a team sport.
• Trust data over intuition. But trust insights from user research over both.
• Develop awareness about how emerging technology may alter or create behaviours by observing early adopters.

2. Test your riskiest assumptions with actual users

• Identify and test assumptions about the operating model and the technology, as well as the business model or the service design.
• At the start, one of your riskiest assumptions is often whether your team can work well together at all. Make this explicit; another assumption to be tested.
• Create a culture where teams feel they can talk about assumptions and risks, not hide them away; false certainty is enticing, but dangerous.

3. The unit of delivery is the empowered, multidisciplinary team

• Hire specialists for attitude as well as aptitude. No rockstars.
• Bring in people from operations from the start and make subject matter experts like legal and security part of the team.
• The team should own their process; don’t let any process own them.
• Scale by adding teams, not by making a bigger team. Do this organically and incrementally, not by guessing upfront.
• Teams won't always map onto existing organisational structure and that's OK, in fact it's probably a good thing.
• Design for, practice and learn from failure.
• Ensure final say on prioritisation is the clear responsibility of a single product owner within each team.
• Give teams the tools and physical environment they need to do their job.

4. Do the hard work to make things simple

• Teams should obsess about making their services simple to use, simple to understand and simple to change.
• Sometimes that means starting again and redesigning everything from your desired outcome backwards.
• For existing services, go back to first principles and challenge every rule, custom and practice that creates complexity or confusion for users.
• Be suspicious of the latest technology "innovation". Fix all the broken things, first. Measure, then reduce failure demand.

5. Staying secure means building for resilience

• You can no longer stay secure by standing still. Agility and threat awareness are your friends.
• Bake security awareness into the mindset of your teams, and the design of your service, operations and technology.
• Understand potential threats, notably how data might be misused, and then make life as hard as possible for those who seek to do damage to you or your users.
• Your obligations don't end at the edge of your network. Understand, assess and manage the risks in your software and data supply chain, not just the infrastructure you control.

6. Recognise the duty of care you have to users, and to the data you hold about them

• Minimise risk by minimising the data you hold about users. Practice privacy by design.
• Explain to users what data you hold about them, how it is being used and who is responsible.
• Put users in control of the data you hold about them, this helps to respect their rights against misuse, and protect them from fraud.
• Design for minimum viable data access, not bulk data sharing.
• Give users easy ways to get their problems fixed.

7. Start small and optimise for iteration. Iterate, increment and repeat

• Changes need to be live in hours not months, so make changing software easy and safe. Continuous delivery of code is a non-negotiable essential. Continuous deployment is even better.
• Feedback loops are best informed by observing real users.
• If code doesn’t have tests, it doesn’t work.
• Don't fixate on one potential solution to a problem – explore the possibility space through research and prototyping.
• Iteration needs to apply to internal policies and practices as much as it does to software.

8. Make things open; it makes things better

• Show the thing. Practice agile communication.
• Early on, use prototypes to tell a story, set a vision and build a shared understanding. Then throw the prototypes away.
• Use the tools of the open internet, and be open to open source.
• Adopting open standards helps avoid getting locked-in by proprietary software vendors.
• Value shipping products to real users over documentation, ‘target operating models' or RAG statuses.
• Use openness, regular show-and-tells and assessment via peer-review to demonstrate progress, and to know how to change the direction of a product or shut it down all together.
• Effective governance means going and seeing the thing for yourself, regularly.

9. Fund product teams, not projects

• Projects and programmes are often the engine of legacy creation. So provide ongoing funding to product teams instead.
• Beware your business case, finance processes or contracts dictating how, or even what you deliver. A "lean/agile friendly" business case process is vital in the medium-term.
• Budget for continuous improvement. The mix of skills you need and the size of the team will change over time. Help your finance team adapt to this.
• Don't be afraid to stop funding something if it isn't working (agile business cases should make it easier to call a halt earlier).

10. Display a bias towards small pieces of technology, loosely joined

• Recognise that technology never stands still, so design your systems to allow for constant evolution, as once cutting edge technology gets commoditised
• Develop the institutional capability to spot potential shared capabilities, and invest in teams producing common components and platforms.
• Think critically about what you build, what you extend and what you buy (but remember, you can't outsource risk)
• Build capacity to understand how technologies and practices are evolving; and capacity for creative experimentation with new opportunities. That'll mean using techniques like Wardley mapping, while also giving your teams space to explore.

11. Treat data as infrastructure

• Good quality data with clear responsibility, not sloshing about in data lakes.
• Make custodianship of data clear and put incentives in place to ensure it is a shared resource for the whole organisation.
• Use agreed, standardised identifiers whenever possible.
• Favour the real-time over the batch.

12. Digital is not just the online channel

• Apply these approaches to the whole service, including the non-online parts – the letters, the face to-face meetings, the physical spaces and the packaging.
• Design the whole service as one, not an app or a website or separate channels in isolation.
• Offline parts of a service should use exactly same underlying data and and tools as the online parts. It's one service.

Finally: break any of these rules sooner than do anything barbaric. It's better to be pragmatic and make some progress, than wait for perfect circumstances that will never come, and not make any progress at all.

This list isn't set in stone. It gives you plenty of starting points, but don't be tempted to try implementing all of them, everywhere, all at once. As always, start small, pick your first project carefully, and focus on the stuff that feels most relevant to your organisation. Iterate the bits that help your teams deliver, in your organisation. Allow time and space to make your own mistakes, so you'll have your own additions to the list in future.

The internet era is still young; there's time for all of us to get better at working in it.