We need to start a conversation on how we lead during a crisis. It starts by being honest. Only by reflecting will we be able to better equip the leaders of tomorrow. I wrote this blog post to start that conversation.
In the space of 7 months, I led on four high-profile COVID projects in the NHS:
-
Part of the NHSX team leading the digital design of the national COVID-19 vaccination programme.
-
As a joint NHSD/X team, we set out to consider how we might increase access to GP records for care providers so they can get critical health information on their clients.
-
For four weeks, I was on the medicines work stream to understand whether there was a need to provide digital support to enable vulnerable patients to request, receive, and take their medicines in a safe, timely and clinically appropriate manner.
-
I helped to lead the mental health team to explore how digital technology can be used to support the mental health needs of vulnerable groups of citizens.
At the beginning, I struggled with the complexity of these projects. As the months progressed, I grew in confidence as I started to spot common patterns.
Lesson 1: do not reinvent the wheel
More often than not, someone has built what you want to build or something similar. Speak to them. Learn how they designed their service. Tap into wider networks focused on digital delivery. For example, in government, there are cross government communities. Make connections with key contacts using social media (Twitter, Facebook, LinkedIn). For the mental health project, we spoke to Mind and ReThink.
The beauty of the NHS and GDS design system means we were able to spin out prototypes using reusable patterns in a few days. Leverage these design systems and common components.
For the COVID-19 vaccination programme, we spent time with the NHS Test and Trace team to understand how they went about designing their service. They were honest about where they had made mistakes. For example, they had created a form that allowed employers to refer their staff for tests. At first, they had high uptake but this tailed off once self-selection was allowed. This insight helped us to convince senior stakeholders a separate employer referral system was not needed.
Lesson 2: user research can de-risk your project
User research is not a validation exercise. It is about understanding how users behave, their emotions and pain points. By speaking to users, you are tackling your assumptions.
For the digital adoption of GP records project, we had major assumptions about how GPs would share records with care workers. We spoke to 6 GPs to help us understand how they went about sharing information and what blockers they encountered. We realised we needed to do more to reassure GPs around sharing information. This paved the way for an online portal that aims to provide up to date information on national information governance (IG) guidance for frontline staff, IG professionals and the public.
Further reading: getting started with user research
If you don’t do user research, how do you know you need to build something?
Lesson 3: you need to know how your product fits into the whole context
Your product does not exist in isolation. Service design helps you understand how different pieces fit together. In the image below, you can see a theatre. The audience can see the set, actors and musicians (front stage). Behind the curtain (backstage), the audience cannot see the costume designers, runners and make-up artists. The backstage is crucial in ensuring the audience’s expectations are met.
Image by Nielsen Norman
Now, apply this thinking to a digital service. The act of mapping out the journey from beginning to end helps you to see the big picture. It brings visibility to what the user does and does not see. I did this for every project I worked on. We highlighted our assumptions and biggest unknowns. We then unpicked this through research.
I once led on a project where we looked at introducing a new way to certify the cause of death in England and Wales. This example service map shows what happens when a death occurs in a hospital setting. It demonstrates what the user will see (frontstage) and what the user doesn’t see (backstage). The second example service map is more high level. It depicts the end-to-end journey of when a death occurs in the UK. It demonstrates how important it is to understand the wider context you operate in. It shows how the data we collect at the beginning of the journey is important for other processes further along the journey. Credit to Mat J for his amazing work on producing these maps.
When we first presented our service map to senior stakeholders, they loved it. It was the first time they saw how all the complex services fit together in one view. Unfortunately, it was assumed that these maps could be done in 1 day! It takes time.
Lesson 4: we need to design for everyone
You can’t leave people behind. We have a moral (and legal) duty to ensure people can access our services. That’s why we can’t think about accessibility and off-line requirements later. They need to be an active part of your design process from the beginning.
Micol Artom, a user researcher on the coronavirus testing team wrote about how important it is to speak to a diverse group of people. When conducting user research with people with disabilities, she wasn’t prepared to find as many barriers as she did. It’s critical to ensure we give power to voices rarely heard to prevent users from having a poor experience.
Further reading: resources to help you make your service accessible
Via Lesson 5: define roles and responsibilities early
When you first embark on a project, you often start with a small team. Yet, depending on the need to deliver, the size of your team will grow fast.
This will lead to people being unsure about their role. When you have many organisations working on a project, things can get even more confusing!
One of the best things you can do when you first start a project is to create an organogram of who owns what. Label who the key decision makers are. If you don’t have this, then run a roles and responsibilities session.
You must protect your team and yourself from doing too much. When I first started, I found myself fulfilling many roles because I wanted to prove I could do a good job. In the end, this was mentally draining and unsustainable. I burnt out and had to take a break.
Photo by Pixabay https://www.pexels.com/photo/blur-brainstorming-business-close-up-269448/
Lesson 6: have one source of truth
When you work on complex projects, you’ll have to read many documents. This may overwhelm you.
Rosie Noto, a fellow Product Manager (and my colleague), grew exasperated at the number of documents to read. She decided to create a slide deck simplifying what the project was about. We started to include everything in it e.g. the problem we were trying to solve, our team structure and links to key documents to read. It helped our team to have one common, shared understanding.
In the future, I would include a decision log and weeknotes in the ‘one source of truth’.
Lesson 7: the gap between digital and policy is too wide
In some respects, policy and digital professionals are similar. Both, want to deliver something that meets user needs. The difference I’ve found is the culture and ways of working. Policy professionals don’t always understand what digital professionals bring to the table. Digital professionals don’t always understand the policy making process.
A change in policy has huge ramifications for the digital solution you are building. Last minute changes can impact the wider service. Digital professionals need to better communicate the impact of those choices.
Policy professionals have more direct access to the minister. Ministers and policy professionals crave certainty so that they can show that things will be delivered on time. We found that policy professionals would gravitate towards using the Waterfall methodology because it gave them more confidence that something would be delivered by a certain date.
We advocated for an agile way of working. We know that for digital development, starting small, and building incrementally was the way forward. The teams we worked with were not used to agile ways of working. When we talked about not delivering everything for day 1, it caused panic. The policy team thought we would be releasing a half finished product into the wild.
Spend the time at the beginning to structure the project. On the mental health project, both the policy and digital team shared how they liked to work. We then agreed on a structure that worked for both of us.
When doing this, think about things like:
-
break down the work (will you organise in sprints? use a project management tool like Trello to track progress?)
-
run daily stand ups
Lesson 8: communication, communication and communication
With everyone working remote, communication between teams has changed. It’s now Microsoft Teams, Google Meet or Slack that most of us communicate through. Having many platforms made it challenging to communicate.
We eventually decided to use Slack as the majority of our team members were already using this. So we chose the path of least resistance. Slack might not be the best choice for you, but it worked for us. For the first time, we had visibility of what was happening across projects.
We are no longer bound by meeting room availability in the office, anyone and everyone can join a meeting. Whenever I created an invite to a workshop, it was forwarded to endless people. This led to my meetings becoming sidetracked. Always, have a clear agenda and be strict on who needs to be there. You usually don’t need your whole team at each meeting. Write readouts to keep everyone in the loop. A colleague of mine, created a one page document, highlighting key meetings of the week. This is helpful to decide who should go to what meeting.
Weeknotes are a great tool to help you keep track of weekly progress. It’s useful for your team to show how far you’ve come.
Visualising progress on a project is key. It helps people to understand what needs to be done and when. A gantt chart can be helpful in doing this but can be hard to maintain. When presenting this to senior stakeholders they found the level of detail too much. They cared more about whether we had achieved our goals rather than how we completed each task. In the future, I would spend more time creating a high level roadmap. A one page view of your timelines, dependencies and key milestones is an invaluable communication tool.
Photo by Moose Photos https://www.pexels.com/photo/man-wearing-brown-suit-jacket-mocking-on-white-telephone-1587014/
Lesson 9: simple is best
Sometimes I think product management is just asking this…
Product Management key questions:
— Eli Montgomery (They/Them) 🏳️🌈 (@Intentionaut) September 21, 2020
What the fuck is it?
What the fuck have we learned?
Why the fuck should we do it?
Who the fuck are we doing it for?
Why the fuck do they matter?
What the fuck are we proposing to do about it?
How the fuck do we know that's the right thing?
We can’t deliver everything for Day 1. We need to be realistic. If you try and do everything then something will break.
You aren’t always going to know what to do next. The worst thing you can do is pretend that you do.
Keeping asking: what’s the simplest thing we can do to meet user needs?
Lesson 10: our data landscape is fragmented
We need to have an honest conversation about the data we have and don’t have. For example, we can easily contact healthcare professionals but not social care workers. This has real world implications. It means we have to design a new method to contact social care workers or rely on social care providers to communicate with their staff. This adds complexity to our services. What if we don’t reach all social care workers? What is the the impact of that?
What could we do about the gaps in our data? Should we for example, build a database detailing who is a social care worker in this country? I don’t claim to have the answer for this. I do think it’s high time we debate it though. We need to be clear about the benefits and drawbacks of such an option. Only then can we make an informed choice about what we do with data in this country.
As a team, you should define measures of success early. How will you capture data to know your service is meeting user needs? What plan do you have in place to improve? This is an afterthought when designing your service. Setting clear Key Performance Indicators, gives your service something to aim for.
Further reading: evaluating digital health products
Photo by Kevin Ku https://www.pexels.com/photo/coding-computer-data-depth-of-field-577585/
Lesson 11: what do YOU think should happen next?
Your senior leaders won’t always have the answer to problems you encounter. Senior leaders are dealing with pressures of their own. They might be working across many things or working long hours on the weekends.
If you encounter a problem, discuss it as a team first. Try and come to common view by talking through your options. Your team should have a view, based on evidence, on the direction they want to head. Trust yourself and your team, as you have most the detail of the project. Pitch your view to a senior leader in a succinct manner. Present options, along with the implications of your choices. Recommend an option. Seniors leaders want to know what you think.
One of the hardest things I’ve had to do, is stop a project. I felt passionate about the work we were doing but I knew it wasn’t the right time for us to explore it. We were afraid of what our senior leader would say, but we pitched why we thought we should pause. We felt like we could add more value by prioritising elsewhere.
Lesson 12: be kind
Photo by Lisa Fotios https://www.pexels.com/photo/stay-safe-be-kind-inscription-on-stone-4021358/
The pandemic has been hard on everyone. Some people love working from home, others have struggled.
It’s okay if:
-
your kid interrupts a video call
-
if you need to take a break
-
you need to stagger your working hours
I loved having virtual coffees with my team. Sometimes, I’d put on a pub quiz to lighten the mood after a heavy week. It doesn’t have to be about work all the time. People should always come first.
One of the best leaders I know, Nayeema, wrote these general orders (see below). I find myself referring to it all the time.
Image by Nayeema Chowdhury https://twitter.com/NayeemaC/status/1252869752759873540/photo/1]
Remember, it cannot be on you alone to save the world. It takes a community.
Writing this blog was a cathartic experience. It showed me how much I had learnt over the past seven months. When you are in the thick of a project, you don’t always see the progress you’ve made. Not all my projects were successful. But, I was successful in creating relationships that will last a lifetime.
My most important takeaways:
-
Document any assumptions you have. Challenge these assumptions through user research, data and desk research.
-
Create a single source of truth early on. Use this as the backbone of your project to store your most important documents.
-
Don’t be afraid to put your view through to senior leaders. Your view matters.
-
If working with many teams, agree together what tools you will use at the beginning of the project.
-
Define key measures of success early. Never stop having this conversation. You need to be able to answer ‘what does good look like?’.
-
Have empathy for others.
-
You are going to have good days and bad days.
-
Never stop asking questions.
Finally, I would like to thank all the people who helped me: Tracey, Nayeema, Hilary, Alice, Nick, Hayley, Rosie, Katie, Isaac, Laurence, Tula, Suzanne, Emma P, Sophie, Ria, Hannah, Zuz, Colin, Sam, Conor, Jess, Iain, Emma B, Sam S, Nicola, Simon, Rob, Emma S, Fred, Nicky and Mehnaz.
