Three ways to run better discoveries

Discovery is important because it sets direction by focusing our work on the right problems. We’ve all worked on things where we’re solving the wrong problems. Too many hours wasted on bad directions. People’s lives. Taxpayers’ money. Our careers.

Yet I see too many teams doing bad discoveries.

A big part of this is that we’re not clear enough about how to run good discoveries. This gets in the way of motivated teams and stops them doing better work. There are other reasons, of course, but this post is for motivated teams that want practical tips.

To come up with these tips I ran two discoveries to find out what works, and what doesn’t, from experience. These are my three stories about doing better discoveries:

• Better discoveries with the discovery block diagram
• Setting up a discovery to succeed with a small team
• Finishing off a discovery to do justice to your work

You won’t find much in these stories about how to do the investigative work of a discovery. There’s plenty of good stuff out there about that. Instead, these stories are about the invisible essentials of good discoveries - how you think about the work, how you plan your work together, and how you bring it all together at the end. 

Without better discoveries we can never bring the full power of user-centred design to our workplaces. Of course these stories don’t contain all the answers, but they're a good place to start if you’re running a discovery yourself. I know because we’ve used them to do better discoveries at GDS.

I hope they do the same for you and your workplace.

Let me know what you think on @myddelton.

Better discoveries with the discovery block diagram

This is the story of how a simple diagram changed how I think about discovery.

Late last year, one of our teams was finishing a discovery. The team had done loads of work and found out lots of good stuff. But their user needs were too enmeshed with the technical solutions being explored.

Nervously, I suggested that the discovery wasn’t finished. I offered to help them rework the output to reflect the quality of their work. But the truth was that I had no idea what a good discovery output looked like. 

I asked for help. Our head of user research, John Waterworth, drew something on the whiteboard that I’ll never forget. I call it the discovery block diagram:

This is a diagram of what your discovery output should look like. This diagram, more than anything else, has helped us do better discoveries on Government as a Platform.

Let me talk you through the diagram and explain why it works.

Context: outline the background

In the context you outline the background to your discovery. You might include: 

• Where the idea for the discovery came from
• Who the different user groups are in this space
• What’s going on with technology and social trends
• What other organisations are doing in this area
• What unresolved problems you think there might be

Include whatever makes sense to you. Keep it high level though. List things, don’t describe them in detail. The point is to acknowledge the broad context before you focus on a more specific problem. 

Starting with the context, rather than the specific problem, helps you be clear that you have chosen one specific problem over others. It helps decision makers outside your team ask sensible questions about what you are doing and why you’re doing it.

Problem: define your focus

In the problem you state clearly which bit of the context your discovery focused on.

For example, your context will often contain different user groups doing lots of tasks. Your problem might narrow this to one or two specific user groups doing a few named tasks. Without this narrower focus you won’t be able to understand the problem well enough to make the decision you need to make at the end of discovery.

Being clear about your problem shows that there were other problems you could have chosen instead. It removes the air of inevitability, which is rarely helpful, from your work. Again, it helps decision makers understand your choices so they can ask good questions later.

Areas of investigation: show what you learned

In the areas of investigation you divide up the problem into different workstreams and talk about what you found in each one. Separately.

Our work at GDS pretty much always has one area for users and needs, another for technology and data, and a final one on policy and legislation. Sometimes we have an area around design and content too. You might have more areas. Your areas might be different. It depends on the problem you're looking at.

Keep these areas separate though. Don’t mix what you know about users with technology or policy at this point. Give each area the space to tell its own story, and the freedom to come up with its own findings. 

This keeps you focused on what you found out. It leaves space for divergent opinions and contradictory facts. This is what a good discovery is all about.

Findings: bring it all together

In the findings you bring the most important things you’ve learned in one place. It’s not about making a huge list of everything you’ve learned. No one wants to see that.

• Don’t include too many findings. Any more than 15 will lose your audience. This is about the things that matter most to the problem you looked at. It’s important that your team has an opinion on this.
• Don’t go into too much detail. You’ve already gone through the detail in the areas of investigation. Your findings build on this. My advice is to express your findings as bold, standalone, single sentence statements.
• Don’t split by areas of investigation. The findings are powerful because they triangulate the things you found across your areas of investigation. You’ve already worked through the different areas.
• Don’t ignore your alpha ideas. Your findings are the link between the detailed work you have done and your speculative ideas for potential alphas. The link between the two should be clear.

The best way to think about this is to imagine you’re presenting your work to your chief executive. She doesn’t have time to hear the detail. She barely has time to hear 15 single-sentence findings. Make it count.

Alpha ideas: show the way forward

In the alpha ideas you sell solutions to the problems evident in your findings. You’ve taken your audience on the journey from context to problem to investigation to findings and now they’re ready for ideas.

You might have one big alpha idea you want to pursue. Paint a compelling vision for it and show how it addresses findings. Remember it doesn’t have to address them all. Or you might have a bunch of smaller alpha ideas and want help in deciding which one to do. Outline each idea, show which findings it addresses, talk about tradeoffs.

Whatever your approach, you should probably cost your alphas and model their benefits. People are going to ask those questions. Be ready. 

But...discovery is still messy underneath

The discovery block diagram makes discovery look straightforward. This is, of course, a lie. Discoveries are messy and full of ambiguities. 

• Choosing the right problem is messy. Your team won’t agree on which parts of the context matter. You’ll want to change the problem once you’ve started. It’s OK. You’re allowed to refine your problem all the way through your discovery.
• Getting the team to agree findings is messy. It’s hard to boil the things you’ve found into the 15 most important findings. You’ll need time and space to do this. It helps if you’ve been working together throughout.
• Defining alphas is messy. Most of the team have secret ideas about how to solve the problems. Some will be deeply attached to these. You need a design process to surface these ideas and resolve them into coherent, practical alphas.
• Ending the discovery is messy. John Waterworth says that a discovery is done only when the team agrees it’s done. That’s a challenge when you have an external deadline but it’s this that you should be aiming for. 

So, yes, discoveries are messy and full of ambiguity. The discovery block model doesn’t change that. It just gives us a clear idea of what we need to end up with. It’s always helpful to start with the end in mind.

This diagram helps us think about discovery

I wanted to tell you about the discovery block diagram because the best diagrams help us think more clearly about complex things. That’s what the discovery block diagram does for teams doing discovery.

It helps you turn your discovery into a compelling story with a beginning, a middle, and an end. It helps you plan your work without telling you how to do the work. It opens your messy, chaotic, ambiguous discovery work to inspection and critique from your colleagues and decision makers. 

Since John drew the discovery block diagram on that whiteboard we’ve done four discoveries on Government as a Platform. Each one started with a conversation about how to get to this output. We’ve seen the quality of our discovery work improve dramatically as a result. Give it a go.

This post is one of three posts about how to run better discoveries. The other two are setting up a discovery to succeed with a small team and finishing off a discovery to do justice to your work. Let me know what you think on @myddelton.

Setting up a discovery to succeed with a small team

Starting a discovery isn’t easy because you’re going into the unknown. If you’re not careful you can dive into the discovery work before you’ve properly set yourself up. This can lead to people heading off in different directions and wasting precious time.

I learned this on a discovery earlier this year. We were looking at whether GDS could do something to help service teams collect information from their users. It took us two and a half weeks to set our team up properly. This was much longer than I expected.

Let me talk you through what I learned about setting up a discovery.

Choose the right goal

For years I thought that the goal of a discovery was to explore a problem. So I asked our team to explore the problem of “how do services without access to a development team collect information from their users?”. 

We went around in circles for two weeks. We couldn’t get a grip on what we were aiming to achieve. We didn’t know what work to do. Eventually my colleague Pete Herlihy suggested we had the wrong type of goal. Discovery isn’t about exploring a problem, he said, it’s about making a decision about what to do next.

We reframed our goal in terms of making a decision. “Decide if there is an opportunity for GDS to help services without access to development teams start collecting information from their users online”. We included why GDS was funding our discovery.

This focused our work. It grounded us in our organisational context. I worried this would feel too restrictive, but overnight we started talking about the problems we needed to explore to make that decision. Not every single problem we could imagine.

We should have started with a goal framed in terms of making a decision. We should have done this before the project kicked off.

Run an inception workshop

A couple of days after we’d set our new goal we took the whole team to the park, sat under a tree, and ran an inception workshop.

For 90 minutes we talked about our goal and how to achieve it. What did we need to know to make a decision? As we talked, we wrote post-its for each topic that came up and sorted them into these categories:

• Goals (things we wanted to achieve)
• Reckons (things we thought we already knew)
• Stuff to find out (things we wished we knew)
• Rabbit holes (things that would lead to lots of wasted time)
• Scope (things we’d do, things we wouldn’t do)
• This is not (things that seemed related but weren’t part of this)
• Icebox for alpha (ideas for later)

The conversation went all over the place. From users to technology to policy to data to cost savings. Discussions about whether something was a reckon or something to find out, whether something was in or out of scope. Everyone contributed.

There was something magic about having a free-flowing conversation that turned into a bunch of structured notes as we talked. Try this for yourself.

Set “discovery is done when” objectives

We took the notes from the inception workshop and turned these into 20 outcome-focused objectives. Here’s our list of ‘discovery is done when’ objectives:

1. We understand types of users for end users and service teams
2. We understand problems end-users have with paper forms
3. We understand problems service teams have with paper forms
4. We understand when/where end-users need paper forms
5. We understand when/where service teams need paper forms
6. We understand the appetite for process change in service teams
7. We understand how paper forms are created/updated
8. We have a picture of the range of complexity across paper forms
9. We know what proportion of paper forms require evidence
10. We know the different types of supporting evidence
11. We understand why signatures are required on paper forms
12. We have a list of important design patterns used in paper forms
13. We have a list of important fields/data types used in paper forms
14. We understand how information collected gets into databases
15. We understand error rates and their impact on data quality
16. We understand how and why departments are using form builders
17. We understand commercial form builders and their benefits/costs
18. We have a cost model for paper forms
19. We have an estimate of the number of paper forms in government
20. We have a prioritised list of alphas, including benefits/costs

Look at this process. We started with a simple team conversation about our goal, and ended with a list of outcome-focused objectives. A list that described where we needed to get to without telling us what we had to do. Perfect for a self-organising team to pick up and run with.

This is my secret to setting up a discovery. Take a clear goal, discuss it as a team, and agree “discovery is done when” objectives.

Divide up the work

We divided our work into four areas of investigation in keeping with the discovery block diagram. This worked surprisingly well. We split the 20 objectives into four areas led by four different people:

• Users and their needs - user researcher (objectives 1-6)
• Content and design - service designer (objectives 7-12)
• Data and technology - technical architect (objectives 13-17)
• Cost models - delivery manager (objectives 18-20)

The team worried this meant going off in four different directions. That’s not how we worked. We did things together, whether visiting service teams, analysing data, documenting designs or coming up with cost models. Discovery is a team sport.

Why divide the work then? It made it clear who in the team was responsible for each of the 20 objectives. When we got into the barely-controlled madness of discovering things it was useful to have this to keep us on track. We knew we needed good enough answers to all 20 objectives rather than perfect answers for a few of them.

This gave each person space to develop their own way of telling the story of their bit of the discovery. It preserved the diversity of viewpoints that we brought to the work as individuals. Each of us ended up owning a major slice of the story.

Plan the work against the time you have

Finally, we planned the work. We mapped the 10 weeks down the left hand side, the 4 areas of investigation across the top, and the activities on post-its in the middle.

We didn’t expect to stick to this plan. Instead, we used it to come face-to-face with how little time we had. It’s easy to underestimate the time you have available to do things. This leads to avoidable compromises at the end.

Here’s what we ended up planning:

• Weeks 1-2: form as a team, work out goals, and plan the work we’re going to do
• Weeks 3-8: do the exploratory work to answer the objectives
• Week 9: bring together everything we learn into clear findings
• Week 10: come up with alphas and present our work to decision makers

After realising that we had only 6 weeks to do the investigative work, we were able to make better decisions about how many interviews to do, how many services to visit, and how many different systems to assess. You always have less time than you think.

Sit back and watch the team go

Setting up in this way meant that the whole team knew what we were trying to do, and without being told how to do it. This shared understanding about direction is what enables a team to perform as more than the sum of its parts. Watching the team go off and do the work was one of the most amazing experiences of my working life.

This is now my standard advice to teams who are setting up discoveries:

1. Choose the right goal
2. Run an inception workshop
3. Set “discovery is done when” objectives
4. Divide up the work
5. Plan the work against the time you have

One final word of warning. This works because it’s a shared process which involves the whole team. The critical ingredient for setting up better discoveries is making sure that the whole team is ready to start on day one. That’s (much) harder than it sounds.

This post is one of three posts about how to run better discoveries. The other two are better discoveries with the discovery block diagram and finishing off a discovery to do justice to your work. Let me know what you think on @myddelton.

Finishing off a discovery to do justice to your work

Finishing a discovery is harder than it looks. It’s easy to fall into the trap of discovering new things right up until the last minute. This means we don’t leave enough time for bringing findings together, designing alpha ideas, or persuading our decision makers.

I learned this on a discovery earlier this year. We were looking at whether GDS could do something to help service teams collect information from their users. Even though we left two weeks to finish our discovery we still struggled to do everything in time.

Let me talk you through what I learned about finishing a discovery.

Wrap up the areas of investigation

We’d been working on four areas of investigation in keeping with the discovery block diagram. Users and needs led by a user researcher, technology and data led by a technical architect, content and design led by a service designer, and cost models led by a delivery manager. 

With two weeks to we needed to bring all the different things we’d learned together. Without a shared understanding we knew we’d struggle to agree a direction.

We stopped work, cleared our calendars for a week, booked out a meeting room, and tackled one area each day. Monday was users and needs. Tuesday was content and design. Wednesday was technology and data. Thursday was cost models.

Each afternoon, we did a three hour workshop with the whole team. The goal was to end with a list of findings we agreed on. How we did this was up to the person running it. We ended up with workshops full of lively disagreements and resolutions.

I worried that a week was overkill. It wasn’t. It takes time to build a shared understanding across the whole team. It takes time to re-form as a team after six weeks dashing around the country to find things out.

Agree one set of discovery findings

On the final day of this week - the Friday - we created a single set of discovery findings. This was also in keeping with the discovery block diagram. 

We gathered together as a team. Each person wrote the 10 findings they thought were most important and then we turned them into this list:

1. Forms are hard to find
2. Too many forms don’t work for people with access needs
3. Bad guidance makes people call before a form is submitted
4. Forms are wrappers for evidence (and evidence is complicated)
5. Users have to fill in unnecessary and duplicated information
6. Too many forms handle offline payments in a horribly insecure way
7. Data submitted ends up in a huge variety of systems
8. Error rates are very high
9. Eligibility is determined too late
10. Bad forms are expensive
11. Problems and costs of forms are not being measured well
12. Forms are not easily changed (legislation and policy can block)
13. Operations and caseworkers are removed from improving forms
14. Digital forms alone cannot kill old systems

It was easy to create these 14 findings because we’d already worked through each area of investigation in detail. This meant that each finding was backed up by a rich web of stories, diagrams and data.

We didn’t split these findings by area of investigation. Each finding brought together things we’d learned across the whole discovery. We had seen the same things cropping up in our user research, design analysis and technical investigation. The findings were a powerful triangulation of all the important things we’d learned.

These findings were the backbone of our work. They helped us brief people in our design workshops. They helped us generate our ideas for alpha. They helped us communicate with decision makers. They helped us tell the story over and over again.

Generate ideas for alphas

In the final week of our discovery we moved to ideas for alphas. This meant switching from talking about problems to talking about solutions. We found this hard because we’d avoided talking about solutions up to this point (as all discovery teams should).

We had two plans to come up with alpha ideas. Neither went smoothly. 

The first plan was to run design workshops with multi-disciplinary people from across GDS. The workshops were great at forcing us to finish off our findings. They worked well at promoting our work across GDS. They fell down in coming up with alpha ideas because I didn’t spend time enough time preparing though. More attention next time.

The second plan was for the team to hunker down in a room and come up with a final set of alpha ideas ourselves. This worked beautifully in that our team came up with a huge variety of alpha ideas. But then I ruined this by clumsily fitting these into my own pre-conceived framework. This was the lowest point for me in the discovery. We recovered by organising our ideas into a roadmap as a team.

I learned, painfully, that you need to allow enough time to come up with alpha ideas. There’s a whole design process hidden in this final part of a discovery that I’d never properly noticed before. I’ll respect that in future.

Persuade your decision makers

Finally we had to communicate what we’d found and persuade decision makers to fund alpha ideas. Luckily the way that we had run the final two weeks of our discovery prepared us beautifully for these presentations.

• We had a convincing backstory. Each person had been practicing the story of their area since the findings week. As we stood in front of our decision makers, each of us had powerful things to say about users and needs, design and content, technology and data, and cost models.
• We had a compelling summary. By using the findings to frame design workshops we’d found ways to make them stand alone. This made them punchy for decision makers who didn’t have time or inclination to hear the details.
• We had a believable future. Our roadmap of alpha ideas painted a vision for public beta. Yes, I worried about showing a roadmap and a vision, but decision makers aren’t comfortable with ambiguity. Sometimes you have to play the game.

Having these things prepared us for the final presentation. Luckily for us. When you’ve been wrapped up in discovery it’s easy to underestimate how difficult it is to communicate what you found out and persuade people to make a decision.

It's important to plan the end (before the end)

Finishing our discovery in this way meant we did justice to our earlier hard work. This is now my standard advice to teams who are finishing discoveries:

1. Wrap up the areas of investigation
2. Agree one set of discovery findings
3. Generate ideas for alphas
4. Persuade your decision makers

This means planning in advance. Booking your meeting rooms weeks out. Inviting people to design workshops before they have other commitments. Lining up decision makers for the right place at the right time. Being clear that your team will stop work.

One more thing. This is a story about finishing a discovery as one team. We had to leave time to share things, argue about things, make things clear, and resolve things. Yes, it can be quicker to do these things as individuals. But this is a false economy. 

Taking the time to finish as one team gave our findings greater depth through resolving multiple perspectives. It meant that every team member was able to tell the story of what we learned and where we’re going. These are important things.

This post is one of three posts about how to run better discoveries. The other two are better discoveries with the discovery block diagram and setting up a discovery to succeed with a small team. Let me know what you think on @myddelton.

Books versus people

Recently I've realised that I'm not spending enough time talking through the problems I face at work. This has been a hard-won realisation for me.

I used to be able to solve work problems by reading things in books and articles and then practicing them on my own. This is how I learned to be a designer and a researcher. I learned how to interview people, make prototypes, do usability testing, give presentations, run workshops, and many other things like this. It felt like a superpower.

But as my work changed - from working on my own to leading teams - this superpower stopped working.

This showed up in a series of personal crises at work:

• when I was designing an online supermarket and burned out because I couldn't work out how to share work with my team
• when I jumped from managing no one to managing four people and struggled to do my job because I couldn't figure out how to let go of enough control
• when I became paralysed at the thought of doing a product manager role on top of my role as lead user researcher because I didn't realise I could negotiate with my own managers to put some aspects of both roles on hold for a while.

I didn't get through these crises by reading books (although god knows I tried). I got through them by talking things through with other people.

I think this is because these crises were not about how to do specific things on my own. They were about how to act and behave in complex situations that involved many other actors and their own motives. Books can't ask questions to clarify context before they give advice. People can, and do, ask questions (or at least the best ones do). And it's this back and forth about the context that makes their advice so powerful.

I noticed something else too. The people that helped me most were not the kinds of people I'd talked to up to that point in my career. 

Previously, I would talk with other researchers and designers because the problems I was facing were practical problems about how to do specific things. But researchers and designers were often as clueless as I was about how to deal with this new class of problems. 

I had to find new people to talk to.

I solved the three crises using a mixture of counselling and coaching. It turns out that counsellors and coaches are experts at asking the right kinds of questions and then giving powerful, contextual advice.

But this is too expensive in the long run.

Now I talk through these problems with people I know at work who face similar problems themselves. These people are not just researchers and designers - they include product managers, content designers, delivery managers, and technologists. There are only two qualifications. Do I trust this person enough to share my problems? Does this person have experience of facing similar problems themselves?

These conversations are amazing. In the last two weeks alone I've realised that I'm not sharing enough of my work with my senior colleagues, that I'm sometimes too focused on building consensus and not making a decision myself, and that my work satisfaction doesn't depend on simply getting stuff done but also on the working culture.

These are wise things that I hadn't realised on my own. They're difficult to answer using books because they're specific to me and my personal work context. 

So that's what I am doing now. Or trying to, because it's a new thing for me and I keep forgetting to do it. My deep-grained habit is to go back to reading a book and shutting myself away to solve it on my own. But although it's taken me about three years to realise this, I'm finally clear that books don't hold all the answers for me.

If you are facing these kinds of problems then you should give this a go too...

Let me know what you think on @myddelton. Thank you to the people who have given up their time to talk things through with me. 

Facing things as they are

“Not everything that is faced can be changed, but nothing can be changed until it is faced.” James Baldwin

I love this quote. For what it tells us about how to approach the world. For what it tells us about how to have relationships with others. And for how it gets at the root of what people struggle most with when it comes to user research.

User research is about starting by facing things as they are.

People worry that the things we learn might be impossible to do anything about. They worry that understanding these things is a waste of time. They worry that these things will mean rejecting the fundamentals behind the things we are working on.

Let’s be honest. All of these things can be true. Are often true.

Facing things as they are turns up things that we can’t do anything to solve. The problems we find are beyond our power. This happens all the time. That’s life.

Facing things as they are requires that we invest time in understanding things. Given that there will be things we can’t do anything to solve, with hindsight it can seem like what we did was a waste of time. Hindsight is a trickster though.

Facing things as they are often leads to a dawning realisation that the things we are working on are the wrong things. You can avoid this truth for a while. But in the long run there is no hiding from this. The things you poured your heart into don’t lead to changes in the world. If you care about change this kills you.

There's a final worry about facing things as they are. This one isn't true though.

People fear that facing things as they are means designing for things as they are, not designing for things as they could be. This is not how research works. It's not how design works. It's not how humans work. Once we face things as they are we are free to imagine new futures. This is our job. As Dan Saffer says, empathy is not enough.

I understand how difficult it is to face things as they are. I struggle with this on all sorts of levels. It’s easier, in the short term at least, to avoid facing things as they are in all areas of our lives. Our work. Our friends. Our selves. Our deaths. 

But, like James Baldwin said, nothing can be changed until it is faced.

I heard this quote on an episode of The Long Now called What the dying teach the living. Many of the things in that episode ring true for me and lessons I've learned in my life. Have a listen. And let me know what you think on @myddelton.

My problem with leadership

I am scared of talking about being a leader and I need to get over it. 
 
There's something inside me that says, when I talk about leadership, that I am getting too big for my boots. That I'm putting myself above other people. That this is not the kind of behaviour that is appropriate for a proper human being. 
 
The thing is, I know that good leadership is essential. I deeply value good leadership. The places where I have enjoyed working the most have been those with brilliant leaders. It transforms the feeling of what it means to be at work. It makes everything better. It's a brilliant thing to want to do and to want to provide.
 
Yet there's something inside me that winces at the thought of calling myself a leader.

I love working with groups of people

I started being in bands at 16. Writing and playing music together. I tried to lead those bands. Although I was a good leader in some ways, I was pretty awful in others. At worst I tried to lead by command and control. I didn't listen much to others or work on things as a group. I had some really painful experiences when those bands broke up. I learned some hard lessons about myself.
 
At 28 I stopped being in bands and moved back to London. Since then I've done a succession of jobs. Recently I've noticed a pattern in these jobs. I keep doing new roles where I expect to be going back to doing solo work. But as soon as I join I end up working with groups of people to do things together.
 
In 2008 I joined an organisation as a web manager where I thought I'd just be sitting doing solo coding and editing tasks. I ended up working with the whole organisation to redesign and migrate a website. 
 
In 2011 I switched to being a user experience designer where I thought I'd be sitting making self-contained designs. Instead I ended up working with my clients' organisations to design and build digital products. 
 
In 2015 I joined GDS as a user researcher with the intention of focusing on the craft of being a user researcher. I wanted to stop worrying about managing people and leading teams. I was dismayed to find, when I arrived, that Leisa and Tara had marked me out to lead the user research on the Government as a Platform programme. I now lead a team of 9 user researchers working across 4 products. I am even leading a multidisciplinary product team through the discovery phase as a product owner.
 
Even though I struggle to say the word leadership out loud, I love this work. This is the work that I am drawn to. It is impossible to drop me in a situation - any situation - and expect me to focus on a single bounded task that doesn't involve other people.

It's just not how I work.

Instead, I look up. I work out what is going on that makes the task not quite right. I meet and talk to the people around me. I start to have ideas about the task, and the task behind that, and all the tasks behind that, and all the people working on all the tasks. I start to have ideas about how all that could be better. And then I'm out there, talking about these ideas, building a consensus that lets us make things better.

I’m uncomfortable with the word leader

It might sound to you that all this angst around the word leadership is ridiculous. I agree. This is why I'm trying to move past it. Like I said at the start, I think it's something inside me that is holding me back.
 
It reminds me of when I became a designer. At one point Andrew Travers took me aside and told me that I was a designer, that I should call myself a designer, and that I would easily get a job as a designer (he was right on all three counts). Up until that point I would have never, ever used the word designer to describe myself. There was something in him saying it that switched what I thought about myself. It made it OK.
 
I wish someone could just flick the switch for the word leadership like Andrew did with the word designer. 
 
People are trying. I was talking about how I feel about this to my colleague Holly. I was saying that my fear is that if I start writing about leadership then people will think I'm arrogant and too big for my boots, and she laughed and said Will, literally no one will think that. And it’s not just her. Leisa and Tara expected me to lead a group of user researchers when I joined GDS. My programme have trusted me with a product team to lead. Close, honest friends are encouraging me to get out there and do it.

The signals are there. But for some reason that's not been enough for me.
 
Honestly, and slightly weirdly, it goes deeper than that. I've been talking about it on and off in counselling. I've had some 1:1 coaching from someone that I trust where this was pretty much all we talked about over two sessions. It's definitely a hangup.

But...I am a leader

It's come to the point where I am spending too much energy on this hangup. I could be spending this on more useful things. So I'm making a choice to move past this. 
 
I am a leader. My job is to lead groups of people to make great things together.
 
There. I said it. Now perhaps I can stop agonising over the bloody word and start sharing some of the interesting and painful lessons that I’m learning about this new part of my life. Because, believe me, I have plenty to say...

Let me know what you think on @myddelton

Thinking, talking, writing

Ideas take different shapes when you are thinking about them, talking about them, and writing about them. These shapes, and their transformations, are a useful tool.

This came to my attention at a counselling session. I've been doing this on and off for the last couple of years. In December, on my way out of the door, I remarked off-handedly that I always leave the sessions feeling lighter and more resolved.

The counsellor asked what I thought was behind that.

I paused. I considered what we'd just been talking about. How those things had been going around in my head for ages. How speaking these things out loud had made those same, familiar thoughts feel somehow different. 

My answer to the counsellor was this. Taking things I am thinking about and saying them out loud transforms my thoughts from seeming real into somehow being real. And when thoughts are real I end up having a different relationship to them. This transformation from thinking to talking helps me see things differently. It's helpful.

Talking makes ideas more real

I was shocked at the simplicity of this realisation. What is going on here?

Although things in my head often feel linear, logical, coherent and true, in reality I'm not convinced they are at all. When I say them out loud - forcing them into a linear format where they mean one thing and not another - the coherence often evaporates. I spot gaps and inconsistencies as soon as I start talking.

My ears come into play too because I hear myself talking. The words that were rattling around inside my brain are now in the air as sound waves. My ears can’t help but hear these sound waves as human speech, and I think I perceive human speech differently to how I perceive thoughts in my head. If you've ever struggled with a crossword clue in your head, only to have the answer materialise as soon as you speak the clue out loud, you know this feeling. This difference in perception makes me aware of the contradictions and absurdities in what I am saying. 

Talking out loud - even without the counsellor saying anything in return - allows me to reflect on my thoughts in a different way than when they're in my head. This reflection allows me to resolve thoughts have been looping around for hours, days or weeks. 

That's where the lightness comes from. The resolution of stuck thoughts.

Writing makes ideas more useful

So talking my thoughts out loud lets me resolve my thinking about into something more concrete. But there's another step that pushes this process even further for me.

Writing.

Writing is to talking as talking is to thinking. 

Yes, talking is more linear and more concrete than thinking. But writing is even more linear and concrete than that. Writing has a beginning, a middle and an end. Sentence after sentence. Page after page.

Talking allows others to critique my ideas, in the moment, as I utter the words. Writing is not just about those others or that moment. Writing is available to more people in more locations. Writing can travel into the future in a way that talking can't.

I said that talking lets me spot contradictions and absurdities in my thoughts. Writing forces me go beyond this and confront the technical and logical gaps in the things I’m saying. Anyone who writes knows that it’s much less forgiving than talking.

And talking isn’t just about the words I use. I can use body language, try being charismatic, or simply wave my hands around a bit. These things aren't as misleading as the tricks my brain uses to make me think my thoughts are coherent. But writing removes these physical props entirely. My thoughts are laid bare. Self-supporting. Which means being more truthful and more accurate than when I talk.

Writing is hard. It’s hard to capture ideas that seem coherent in my head. It’s hard to write explanations that I have no trouble explaining when I talk to you. It's another level of discipline and clarity entirely.

Thinking, talking and writing all matter

None of this is to say that any one of thinking, talking or writing is better or worse than any other. They are simply different modes for working through ideas. What happens when you switch between modes is useful and worthy of attention.

For example, I use these different modes to filter out good ideas from bad ones. The first time I talk about an idea out loud is a bold (and necessary) step in questioning whether the idea has merit. Later, trying to commit that idea to writing is an even bolder step in understanding whether the idea is strong enough to live on its own. 

It’s not just about words...

Quick pause.

If you’re a designer you’ll have noticed this is a radical, reductive simplification of what's going on. That’s the thing about writing. Sometimes you need to open with an incomplete idea to lead to a bigger one.

I’m discussing talking and writing because that's my dominant mode of doing things. I’m a words person at heart. If you’re a visual thinker you’ll be doing this same process by going from thinking to sketching to designing. If you’re a maker type you’ll be going from thinking to prototyping to building. 

In fact even that’s a simplification. We all flip between all of these modes - thinking, talking, sketching, prototyping, designing, building - as we go.

What I'm really discussing here are the stages of things going from being in your head (where they seem to make sense but are inaccessible to anyone), to emerging into the world (where they can escape your mind’s trickery and be exposed to critique), to being permanently in the world (where they are laid bare for others to make use of). 

It’s just that I’m telling that story through my own lens of thinking, talking and writing.

...but it's definitely about balance

Thinking, talking and writing are all important. But given that we all have limited time available, how do you balance the three of them? 

I can’t say what’s right for you. But I can talk what works (and doesn't work) for me. 

Thinking

A big part of thinking is making sure that I have plenty of diverse inputs. I read books, listen to podcasts, interact with other people and get exposed to a huge variety of ideas at work. I’m a curious person and I'm naturally drawn to this part. I love it.

But I've learned, the hard way, that having lots of raw material is not enough. I need to have the time and space and inclination and willpower to do the thinking. When I was working long hours in a high-pressure job my thinking suffered. I burned out. I wasn’t thinking much about either my professional life or my personal life. That's why these days I work my hours and I work a four day week. This is less money but more time away from pressure to think about things. It helps with thinking a lot.

I’ve realised there is something else that's important. I need my mind to be capable of being peaceful and focused. I need to escape those thought loops that consume it all too easily. I found, to my utter surprise, that 10 minutes of meditation each morning works for me. This was after accidentally reading the beautifully-illustrated Quiet the Mind in a bookshop while escaping an unexpected storm in Fishguard.

Talking

OK, I say talking, but in the wider sense this is about bringing my ideas into the world for first critique. I am slowly getting better at doing this but it's been a long road.

At work, everyone knows I’m someone who talks ideas into existence. I endlessly try out new thoughts on people, as much as to see what it feels to say it out loud as to get their feedback (both matter to me). I spend time sketching things for people as a way to bring ideas into a place where we can both look at them. I don't prototype much any more, which is a shame.

In my personal life I have two things that help. 

I write 750 words every morning of whatever is on my mind. This is loosely based on Morning Pages (although I don't do longhand writing!). Although it's technically writing, it's more akin to talking because it puts things I’m thinking into a place where I can reflect on them. It's a conversation with myself. You would not believe how many stuck thought loops I have resolved by simply putting them onto a page as a stream-of-consciousness. It’s like magic.

I also go to counselling these days. Or talking therapy. A lot of the benefit for me is simply verbalising things to someone else and then looking at them together. Turning a chaotic invisible thought process into a linear string of sentences. Again, you wouldn't believe how much clearer things become during this process.

Writing

The thing I'm not paying enough attention to is writing. Or, more widely, putting things I know permanently into the world. I’m not good enough either at work or at home.

At work, I know more about how to do my job than I am able to transmit to the wider community of people that I work with. People who would benefit from me being able to write things down properly. My team get the benefit because we work together and I can talk about things. But that's where it ends. So much knowledge transfer in organisations breaks down at the point where tacit knowledge held by teams through talking isn’t captured in a way that can scale to other teams or future situations. This is my challenge over the next year. It’s in my objectives. Hold me to it if you see me.

At home I kind of feel the same. All this stuff - the meditation, the 750 words, the counselling - is changing my understanding of what it is to be human. To live in the world. But I never write this down, which means no one else can read it. This is a shame given how much I’ve learned from others who have written about their lives.

Feeling lighter is a feeling worth chasing

Like I said at the top, my counsellor asked me about this whole feeling lighter thing.

I told her that going from thinking about things to talking about things made me feel lighter. And I speculated that this might extend further into writing about things.

And she said, good, why don't you try writing about some of the things you are learning about yourself and the world?

So that's what this post is. Even though it's difficult. Even though it makes me feel exposed. Even though I’m basically terrified to tell you these things about myself. Even though there's a little voice telling me that all of this is banal and obvious stuff. 

I’m intrigued to see whether this writing will make me feel lighter. And whether or not sharing these things about myself is useful or helpful for you.

Let me know what you think on @myddelton.