I first learnt the power of mulling at university. Something magic would happen if I made a start on assignments and then left them alone for a couple of days. There was no obvious connection between my life and the maths problems I was wrestling with, but somehow the solutions would just seem to emerge when I stopped thinking about them and went about my day.

If you’re like me, you might find that your best ideas crop up in the shower, or while walking the dog, or while doing something completely unrelated to your actual work. Even if you don’t get a sudden brainwave, leaving a gap between starting work and finishing it means you see it in a whole new light.

It’s not just that you’ve got enough distance think critically about it. Often you’ll find that your subconscious has been working away in the background, giving you new insights and new perspectives.

Harnessing this effect is a way to write more compellingly, to have better ideas, to think more clearly. And it’s often a way to work more efficiently too.

I use mulling in writing these blog posts. Spending five minutes outlining a post a week or so before I actually want to write it means the writing just flows when I come to draft it. It saves me much more than those initial five minutes! It’s also more enjoyable, because I spend less time feeling stuck and wondering what to say next.

Give your subconscious enough to get started

To maximise the benefits of mulling, start by feeding your mind with interesting problems. You want to get enough into the question that you start thinking about it properly, without actually sitting down and hammering out an answer. Remembering that you have that massive project on your to do list is probably not going to be enough for this. But spending ten minutes breaking it down into smaller steps might just be.

You need to properly engage with your material before stepping away. This means being willing to start rough first drafts of things early. Just get some thoughts on paper and see what happens.

One way I take this further is to spend time on questions that aren’t formal pieces of work. I have a running list of ten questions I’d like answers to. At the moment it includes things like:

• How can I get more buy-in for my biggest project from so-and-so?
• How can I make my team more approachable for ad hoc bits of innovation advice?
• How can I engage better when listening to webinars?

None of these are things that I would expect to share formally with anyone. I don’t expect any of these to turn into a report or presentation or anything like that. But I will do better work if I figure them out! And so, when I have a spare ten minutes between meetings, I will throw some thoughts into a notes file. When I return to them a week later, I almost always find I’ve got a lot clearer in the interim.

Give your subconscious space to work

Once you’ve got into your interesting problems, you need to give your mind enough time to work on them in the background. Of course, to do this you need to structure what you are doing so you aren’t working on things last minute.

How does mulling relate to agile?

Mulling isn’t strictly an agile skill, but you’ll find that many agile practices can support mulling. The focus in agile on capturing work visually and sharing it transparently gives your subconscious enough information to begin mulling it over. We detail out the tasks we’re doing in stand-ups, or name the problems we’re facing in retros partly because just naming them starts the thinking process.

Have you found mulling helps your work? What practices support you in your best thinking?

This is the second in a series on good thinking. Last week, we looked at three tools for clarity and focus. Subscribe to my newsletter to receive a monthly round-up of posts and more agile tips.

When your work has a clear focus, you achieve much more. You’re less distracted, more intentional, more centred on the right things. And it feels better. If you have one clear goal for the present moment, you’re much more likely to achieve flow.

I’ve written a lot about how backlog refinement can give teams that level of focus. But we can increase our focus on an individual level too. Here are three of my favourite practices for doing that.

Set intentions for meetings

Being focused is about having clear intentions. And one place where having a deliberate intention really helps is in meetings.

I don’t mean just having a meeting agenda (hopefully you don’t need me to tell you to do that!). But often what we really want out of meetings is a bit subtle. Maybe you want a meeting to make a decision, but your real goal is to make sure a particular complexity is considered, or that everybody feels heard, or that the two people with likely disagreements are able to hear each other’s point of view. Knowing that going in makes it much easier to make it happen.

Take a moment before your next meeting and work out what you really want out of it. You’ll find it’s much easier to stay on track if you’ve actually thought about this.

The rule of three

Another place intentionality can help is in having clear goals for your day. I’ve taken the idea of the rule of three from Chris Bailey. At the start of each workday I choose three things I want to achieve that day. Not four or five, only three.

Choosing that morning is flexible enough to allow me to respond to new things that come up, whilst still giving me enough structure to have a clear focus through the day. It means I focus on the most important things, rather than just reacting to what pops up in my inbox.

And limiting it to three things makes it achievable. If I tried to complete my whole to do list, I might never finish. But three things allows me to log off at the end of the day with a clear mind. I finish each day happy with what I have accomplished.

Time blocking

The whole day flows better when I plan it this way. Of course, sometimes something urgent crops up and I change my plans. But it’s much easier to change plans that consciously exist rather than just realise you’ve got to do something extra and hope you have enough time for it all.

What helps you focus in the middle of a busy workday?

This is a series on practices to help you think better. Next week: harnessing the power of mulling.

Sign up to my newsletter so you don’t miss a post.

What if your team wants to work in an agile way, but no one else you work with does? Welcome to wagile, the intersection between agile practices and a more traditional waterfall approach.

Wagile can get really messy, but that’s not to say it can’t work. You just have to be a bit more thoughtful about how you implement it.

Let’s start by looking at the tricky bits.

Why agile in a waterfall world is difficult

If everyone else around you is working in a more traditional style, you might be expected to submit plans well before you get to them. Perhaps your IT or Creative team want to be told about work a year in advance to make sure they have capacity. Perhaps you’re expected to produce detailed budgets 18 months ahead of the actual work. This can feel incredibly difficult – you want to learn and adapt as you go, but others expect you to know now what you’ll be doing in future. And you just don’t know yet!

Testing can also be particularly tricky. You want to be running regular quick and dirty experiments, but there’s six layers of sign-off and no one’s set up to try something for less than six months.

Perhaps you are learning to work in a really focused way, but you find that the others you rely on can’t keep the same pace. You’re trying to do things sequentially: a couple of big things this month, a couple of different big things next month. They are trying to do ten things simultaneously, and might not even have time for your priority this month.

All of this can feel disheartening. But there are things you can do – things within both your sphere of control and your sphere of influence.

What you can control when everyone else is waterfall

Remember that agile is not a binary on/ off state. If you find that you have to adjust some of your working practices to adjust to the wider environment, that doesn’t mean you have to throw the baby out with the bathwater and abandon agile entirely. There are many ways in which agile can still help you.

One small example: tracking work that you are waiting on. I mentioned earlier that your current priority might not be someone else’s priority just yet. That doesn’t mean you should forget about it. Keeping a shared record of work you are waiting on from other teams is helpful for several reasons. Firstly, it means that the whole team is on the same page about why something isn’t moving forward and can adjust. Secondly, it’s easy to spot when you should nudge someone for something you are waiting for. Thirdly, it’s easier to spot patterns when you are keeping track. If there’s a particular team or process that’s holding you up, can you work together to address that?

Consider what processes you need for testing. I’ve often been able to negotiate a different approach for marketing tests specifically. When the spend is very small, or a very limited number of people will see it, it’s reasonable to ask for some of the normal processes like sign-off to be relaxed. Work out what the non-negotiables are. For example, if you need some wording about data protection, could you agree one that works in general and only need to check specific statements if they need to be different for some reason? Are there branded templates that you could use to speed up the design of testing assets?

You don’t have to establish a perfect process straight away! Often it gets easier to get buy-in for these sorts of approaches as you get more evidence of how they help. Make sure you are sharing the results of your testing and thanking people who helped make them happen. This will help you iterate on how you work together.

When you are expected to share plans and budgets way in advance, consider what you do know. For example, I need to submit five-year budgets for the innovation team I manage (ugh!). I’ve no idea what projects we’ll be working on in five years’ time. But I do know we’ll be working on something!

Rather than deciding the details now, I choose some broad buckets and allocate expenditure to each of them. This might include budgeting a certain amount for new product development. I don’t know what kind of products we’ll be focusing on, but I do know roughly how many rounds of new product development we’re likely to do each year, and roughly what each round costs. That’s what goes into my budget.

I also recognise that good enough is good enough. For people with predictable work, precise budgets can be very helpful. But if that’s not the case for you, spending hours agonising over exacting budget figures probably isn’t all that helpful. Preciseness is not the same as accuracy.

Your sphere of influence with wagile

Don’t underestimate the impact your team can have on the wider culture. You might find that others you work with respond really well to some agile practices, even if it’s not their normal way of working. For example, try setting some shared outcomes for your work together, or give them more opportunities for collaborative decision making.

As I said in the discussion on sneaky agile last week, you don’t have to explicitly call any of this agile! Often people find it easier to just go along with things if it doesn’t feel like some jargon-filled Big Thing.

On the other hand, I’ve also found others to be open to working in an agile way for short bursts. I regularly run design sprints with people who otherwise work in a completely waterfall way. Stepping away from that for a week is achievable – after all, we all regularly go on week-long holidays and the world doesn’t fall apart.

I’ve also been surprised to find Creative teams willing to use Scrum on specific big projects we work on together. Start by thinking about what your waterfall colleagues want (smoother processes, an answer for this big question, to get this project finished by the autumn…) and you’ll often find that agile is an easy sell.

This is the last in a series on how to overcome the barriers to agile – read earlier blogs about psychological safety, growth mindset, tolerance of discomfort and leadership buy-in. And sign up to my newsletter to get a monthly round-up and more agile tips.

Agile is not about leaders. But if leaders aren’t bought in to at least letting you give it a go, it will be much harder to make the shift to agile.

That’s not to say it’s impossible – and I’ll talk in a moment about some practices you can try if you can’t persuade the leaders above you – but it is a lot easier when they are on board. That’s why I often focus on managers first. You don’t need your manager to be driving the changes, but if your manager isn’t willing for the team to experiment, or if they’re not prepared to give up some of their power and make more decisions collaboratively, you won’t get very far.

What goes wrong when managers aren’t bought into agile

The most common problem I’ve seen when managers aren’t bought in is that they will ignore how the team prioritises. Struggles with focus and prioritisation is a major reason people try agile in the first place, but it’s no good establishing a prioritisation process if you keep getting additional unmanageable priorities added on top.

I’ve shared some suggestions before on what to do if that’s the case for you. If a leader is really pushing additional priorities it’s sometimes helpful to bring them into your process – eg by getting them to join a backlog refinement session. Showing them the volume of things you are juggling and that you have a robust decision-making process can help them be more realistic in what they ask for. Of course, that will only work if they are at least a little bit open to agile.

Sometimes leaders want to be overly involved in decisions and that can also make agile a lot harder, especially when the nature of their role means they are more hands-off. Recently, I was asked to work with a team that were struggling to make enough progress on a long-term project that was important but not time sensitive. The leaders gave me a list of work that they thought the team should do to support the project, and then left me to go “do agile” with the team. It was a good list on the face of it. But the more I talked to the team, the more I realised how much of it was impractical. The leaders just didn’t have the context that the team did about what might work, what had been tried before and what the barriers were.

If those leaders had been more bought into agile, they would have let the team work out how to deliver the project. It was fine for them to set the overall goals, the “what” they wanted the team to achieve. But the “how” should sit with the team. It’s another example of how often leaders just need to let some things go to allow their teams to shift to agile.

Sneaky agile

If you’re convinced it’s not worth talking to the leaders above you about agile, there’s still some scope for you to do things differently. Remember that agile is a spectrum, not a binary on/off state. You might not get as far as you would without your leaders on board. But that doesn’t mean agile has nothing to offer you at all.

Project managers in particular should have a huge amount of space for trying agile tools and mindsets. As a project manager, you are expected to set some norms around how your project group meet, plan and collaborate. Project planning and project kick-offs are great places to start sneaking in some more agile approaches.

Even if you’re not a project manager, you have some options available to you. Start getting really clear on the desired outcomes for your work, run a small experiment, use some collaborative decision making tools or shift up the format for your regular meetings (maybe trying a stand-up). Don’t feel like agile is all or nothing – pick some small things that might help you and give them a go.

Don’t feel you have to use agile jargon either, especially if you think people might feel it is off-putting. For a long time I regularly played what we called “the higher or lower game” with several teams to help them choose their priorities. They didn’t need to know that was really an agile practice called backlog refinement. They just needed to know that it was helpful in their particular circumstances.

Getting your manager on board with agile

If you want to convince your manager that agile is a good idea, start by thinking what they might want to be different with your team’s ways of working. Perhaps they wish the team had more thinking time, or space to work on longer-term projects, or they want to improve communication or reduce duplication. These are all things agile could help with. Start there and suggest trying an agile approach to those as an experiment.

Make it as easy as possible for them. Maybe they’re not averse to trying something like a stand-up, but they don’t have the time to get the team started with them. Could you set it up yourself to demonstrate it’s easier for them?

Recently, I’ve been rolling out of agile for my department. One of the things that’s helped me get buy-in is working with senior leaders on the things that matter to them. Once I’d shown a few leadership teams how backlog refinement could help them make a lot more progress on bigger projects, they were much more open to me using practices like that with their teams on smaller pieces of work. So don’t assume that agile is only helpful for certain people, or that more senior people would never try it. Often the most powerful way to persuade people of agile’s value is to get them to try it themselves.

This is the fourth in a series of blogs about the barriers to agile. Next week, we’ll look at using agile when no one else around you is.

Subscribe to my monthly newsletter to get a regular round-up of posts.

There’s a theme you might spot in my earlier blogs on psychological safety and growth mindset. Both concepts involve tolerating the discomfort of risk taking. The risks might be interpersonal ones, or they might be about trying something in the name of learning, but both require you to stick with things that might feel a bit icky. That’s why my third barrier to agile is an inability to tolerate discomfort.

That’s not to say that agile is all doom and gloom or inherently unpleasant. One of the big draws of agile for me is that it helps you collaborate more closely with others, which should make work more enjoyable. But in order to get there, you need to push through some discomfort.

Trying new things is uncomfortable. So is continually experimenting and questioning your assumptions. So is giving and receiving feedback. So is dealing with uncertainty. But all of these are worthwhile, and all of these are necessary to work in an agile way.

If you’re a leader, one of the most uncomfortable things about agile might be giving up some of your power. A core agile principle is that decisions should be made by those closest to the work, and that isn’t necessarily you! Of course, it can be very freeing not to be expected to have the answers to everything all the time, but if you’ve defaulted to that dynamic for a long time, agile can take some getting used to.

How to get better at tolerating discomfort

Firstly, I think it’s helpful to acknowledge when something is uncomfortable. It feels better personally when you can say that something is stretching you out of your comfort zone. You’ll also often find that sharing about your discomfort has social benefits. People are more likely to know you might need a bit of support, or grace whilst you work out the kinks with something.

We like people who can be appropriately vulnerable! The people you work with are only human, after all. Being open and honest about your discomfort can strengthen relationships.

Even just acknowledging the discomfort internally is helpful. If we don’t recognise what’s going on with us, often it plays out in unexpected ways, like avoidance or irritability. Saying to yourself that you are feeling apprehensive, or stretched, or whatever it might be, means that you can be more thoughtful about your behaviour.

It’s much easier to tolerate discomfort in psychologically safe environments, so anything you can do to build a culture where it is ok to take risks helps. Leaders in particular can do a lot by modelling feedback and learning, sharing where they have got things wrong or otherwise found something difficult.

Your framing also matters. See setbacks as learning opportunities, not failures. If you look back over your history, you’ll probably realise that the times you grew the most were also the times which felt most unsettling. Keep that in mind as you consider the things that are uncomfortable in the present.

My last piece of advice is to set a time limit. It’s much easier to endure something if it’s only for a limited period of time. Of course, by the end of that you might find that you are no longer uncomfortable – you’ve got used to whatever it was you were previously tolerating, and might even have moved on to enjoying it. But sometimes we try things that aren’t right for us. Make sure you give things a decent try, but also give yourself permission to move on if it still isn’t working in a few months time.

Next week, we’ll look at how resistance from leaders can be a barrier to agile, and how to overcome it. Subscribe to my newsletter for a monthly roundup of posts.

A growth mindset is the belief that our skills and abilities can be improved through effort. It’s a concept developed by Stanford psychologist Carol Deck, who demonstrated that it’s core to enabling people to take on new challenges. We need to believe we can learn in order to learn.

The opposite is called a fixed mindset. If you’ve ever heard someone say ‘oh, I’m just not good at maths’, or ‘that’s just the way I am’, that’s a fixed mindset at play! Assuming our abilities are set parts of our personalities means we don’t really try to change them. And that makes it impossible to grow.

People with a growth mindset are happy to learn from failure. They are open to feedback, resilient and actively embrace challenges. They see effort as the key to success rather than innate ability.

You might see some parallels to last week’s discussion of psychological safety. Both are about making it ok to take risks. We have to take risks in order to learn, to keep going through the uncomfortable phase of not knowing and deal with the possibility of being wrong.

Whilst psychological safety is about the organisation or team dynamic, growth mindset works at the level of individuals. An individual can have a growth mindset in a psychologically unsafe culture (although that’s much more difficult).

Like a lack of psychological safety, a fixed mindset can be a barrier to adopting agile. Let’s look at why.

Why you need growth mindset to work in an agile way

Firstly, you need to believe that your ways of working can improve in order for it to be worth changing them. Challenging the status quo is inherently difficult. If you feel hopeless that you and the others you are working with can get better at collaboration and focus, you won’t give agile a fair shot.

Secondly, agile is all about experimentation. When working in this way, you should be learning your way forward, working in short loops where you deliberately test things to learn what your audience needs, before stopping and reflecting on what to do next. Some of these experiments will fail – that’s how you know they were true experiments! A growth mindset allows you to embrace these failures as long as they are contributing to your learning.

How to grow a growth mindset

Regular reflection and experimentation are at the heart of agile, and these can help reinforce a growth mindset. Pay attention to the fact that you are learning and changing both individually and as a team. Acknowledge that it’s ok to make mistakes along the way.

This is easier to do if you start small. Pick one thing you could experiment with and see how it goes. If it succeeds, brilliant! If not, notice what happens. The world doesn’t end because you tried something that didn’t pan out. Try lots of small experiments to build your confidence over time.

Reframe how you see challenges. People with a growth mindset welcome challenges as new and interesting ways to learn. It’s what Oliver Burkeman calls developing a taste for having problems.

The language we use can also help shift our mindset. Instead of telling yourself ‘I’m not good at xyz’, try expressing it as ‘I’m not good at this yet‘. If you are giving people positive feedback, focus on the effort they made or things they learned, rather than describing them as inherently good at the task they completed.

This is part of a series on possible barriers to agile. Subscribe to my newsletter for a monthly agile tip and a round-up of posts.

My blog is called agile for everyone, but is agile really for everyone?

Some workplace cultures aren’t (yet) set up for this way of working. I think more could adapt to agile than you might think, but there are a few pre-requisites. Over the next few weeks, we’ll explore how to spot if there’s more work to do before you are ready for agile.

The most obvious pre-condition for agile is psychological safety – having an environment where people feel comfortable taking interpersonal risks like speaking up with questions and concerns. In psychologically safe settings, people can try new things which might or might not work out, without feeling like they might be punished if it goes wrong. This doesn’t mean you don’t set yourselves high standards, but recognises that some failure is a necessary part of learning.

Extensive research by Google has found that psychological safety is the biggest predictor of team performance. It’s also an essential condition for agile working.

Why do agile teams need psychological safety?

If agile is new to your team, or you are implementing it in a different way, trying it will feel inherently risky. Not only are you doing things differently, but you’re doing it in a way that requires a lot of transparency and openness.

It can feel surprisingly vulnerable to share more of the details of your work – for example, in a stand-up. When we work in silos, it’s easier to cover up when things don’t go to plan, or when you’re not sure what you’re doing. But agile normalises sharing those things regularly as they happen, because if the team knows they are happening they can try and address them together and adapt their approach as necessary.

Agile should also involve more feedback to everyone in the group. Retros are one way to do this in a structured and hopefully non-threatening manner, but even so it’s a shift from most feedback coming from managers to their line reports. You need some psychological safety in order to be able to raise what’s not working in the work you are doing as a team.

I’ve written extensively about how challenging our conventional power norms is core to agile. When you work in an agile way, decisions about what you work on and how you’re going to do it should be made by the group, rather than just coming top-down from the manager. But this relies on the group feeling comfortable speaking up and not just leaving it to the most senior person.

Finally, learning is at the core of agile. We should be experimenting and learning our way forwards. But the nature of experiments means some things will go right and some… won’t. That needs to be ok for agile to work.

How agile helps build psychological safety

Ironically, although a lack of psychological safety is a barrier to agile, agile itself can help grow psychological safety further. All the things we’ve just talked about (transparency, feedback, distributed power and learning) are both essential to agile and strengthened by it.

Think of trying agile as like joining a running club. If you can’t go more than three steps without getting out of breath and giving up, you’re not yet ready to join a group running 5k every week. But if you can just about manage a slow 5k, joining the club will help you get faster.

So, if you’re working somewhere truly toxic, agile probably isn’t for you. But if that’s not the case, you should be fine giving agile a go – just as you would be fine joining that running club even if you can’t run a marathon yet.

In fact, when you look at some of the advice on fostering psychological safety, lots of it might seem familiar to you if you’re aware of some agile mindsets and tools. Many agile practices are just structured ways of making sure everyone has a chance to speak up. At it’s heart, agile should mean teams can experiment, are listened to and have more decision-making power. This is all very helpful for psychological safety!

If you are still a bit nervous about getting started with agile, I strongly recommend starting small. Reduce the risk until it feels comfortable by just picking one tool or one area to try something different. That might mean just trying something like a regular retro, and using that as a way in to creating some space to reflect together. If that works, you can try something else and build your practices over time.

This month, we’ll be exploring more potential barriers to working in an agile way. Subscribe to my email newsletter to get a round-up of posts and more tips on agile working.

The best managers ask more questions.

The Leader Lab cites a study which found that great managers ask five times more questions than average ones: 10 questions in a 15 minute conversation. You might know the benefit of questions from your own experience. Managers who default to asking questions rather than telling you what to do help you unlock your best thinking.

Why coaching is better for managers

Hopefully by now, you are convinced that coaching is good for the coachee. It gives them space to think more deeply, using the knowledge and context they have from being closest to the problem. It also stretches their skills and thinking in a way that is great for their development. And most people find it really motivating to have their own perspectives and insights taken more seriously.

A coaching approach to management also benefits the manager directly. It’s a huge relief not to need all the answers all the time.

The more people you manage, the more true this is, especially if your team represents a wide range of disciplines. Early on in management, you might just be able to get away with knowing enough about your report’s roles to have an opinion on any question they might bring to you. But the more senior you are, the more likely it is that their problems will be out of your range of expertise.

Your team should also have a broader set of relationships than any one person, even you. And frankly, your organisation probably has a whole range of systems that it’s not worth your time learning. Let each of your team be an expert in their own individual area. You don’t need to be an expert in it all!

Taking more of a coaching approach equips your team to act without as much input from you, freeing you up to concentrate on other things.

Using coaching skills in one-to-ones

You might feel a little weird changing your approach to your conversations with your line reports. If so, tell them! Managers who demonstrate that they are continuing to learn and take risks make it easier for their teams to do the same. Explicitly saying that you are learning about coaching and you will be trying to ask more questions will make it easier for both of you to act differently.

You also might find you need to slow down a bit in order to not immediately jump in with the answers. I find it helpful to have some go-to questions ready to draw on if someone comes to me with a problem – the questions I wrote about in my last blog work great for this.

Occasionally you’ll find that your reports come up with an answer that you disagree with. This really will be occasional – it’s happened maybe once for me in many years of coaching teams. Even then, once I asked more questions I understood where my report was coming from better and could see some merits in her approach.

If this happens to you, resist the urge to immediately bat the idea down. Ask more questions, making sure your report has a clear idea of their goal and the options before them. If you still disagree and it’s important, ask if you can give your own perspective. Getting permission before giving your own answer signals that you still value the other person’s thinking, you just have some additional insights to consider.

One of the biggest benefits of coaching is that saying our thoughts out loud makes them more concrete. This allows us to make connections and find unexpected insights. The manager as coach can help with this by summarising where it seems useful:

• ‘To recap, such and such has happened and you need to decide what to do next.’
• ‘It sounds like you’re torn between x and y, is that right?’
• ‘You’ve spoken about a, b and c – what’s the biggest problem here?’

Often when we’re facing a problem, our thoughts about it can be quite muddled. If you notice someone going off in lots of different directions, getting distracted by less relevant points, summarising can be really helpful. It’s particularly useful when someone’s talked about several options they could consider but not looked at them side by side yet. Recapping that they’ve mentioned a, b and c makes it much easier for them to choose between them, or to realise they need to look at other approaches.

One of the advantages you have as a manager is that you have an ongoing relationship with your reports. This means you can help them make connections with things they’ve said previously, in a way that a more formal, less frequent coach might not be able to do. So if you’ve noticed they keep bringing the same problem to your 121s, or they keep wishing they had learned a particular skill, share what you have observed.

Do you take a coaching approach to management? What works for you?

Subscribe to my newsletter to get a regular round up of posts and agile tips.

So, you’ve gotten started with coaching and perhaps are starting to leave some of the basic models behind. What’s next? How can you get better at coaching?

Growing your core coaching skills

With practice, you will find that new questions occur to you without you needing to fret about it whilst the other person speaks. If they don’t immediately, that’s where silence comes in again! You will often find that a short pause encourages the person to say more, so don’t worry if there’s a little break between them speaking and you chipping in again.

There’s a few other skills that make up an important part of coaching:

• Noticing. When you are really listening, you will notice things about your coachee’s reactions. Perhaps they say something that links to a point they made five minutes ago, or flat out contradicts it. Perhaps they seem surprisingly frustrated or angry about something. It can be helpful to gently point this out to them. Remember that they are the expert in their experiences, not you, so allow for the possibility that you might be wrong. For example, “I’m noticing x – is that right?”, “Does y resonate? What’s behind that?”.
• Summarising. It can be really clarifying to hear someone reflect back what you’ve just said in a summarised form. This is also a good tool to use when you aren’t sure where to go next in your conversation – summarise what you have heard so far and ask what your coachee would like to explore further.
• Being present. All of this relies on you being as present as possible in the conversation. Consider what you need in your physical set up to make this possible – make sure you’re in a quiet place with your phone on do not disturb. Don’t rush into coaching straight from another meeting. Take a few moments to take some grounded breaths and really settle into the space before you start.

Expanding your questions bank

One way you can improve your coaching is by having a deeper well of questions to draw on. But I’m reluctant to give you a long list of possibilities. Starting your coaching practice using something like the GROW model can be really helpful, but after a while it can become limiting. There are no questions you have to ask, and if you are really listening, you should be asking question based on the conversation, rather than some set list. Having a model or a long list of questions to think about can actually be unhelpful at that stage.

But the right question can unlock something unexpected, and it can be helpful to have more options to draw on. Over time, you’ll find the questions that work for you. You’ll probably find you have some go-tos that are helpful in lots of different settings. Here’s mine:

• ‘What would a good outcome look like?’ It’s surprising how frequently people haven’t really considered this, and having a clear picture of success can really help guide your conversation.
• ‘What are some options you could explore?’ ‘Tell me more.’ ‘What else?’ Very often, we think of one option for how we could approach something, and then we stop. But your first thought it not necessarily the best one! Prompt people to keep thinking until their ideas really do dry up. You’ll also find that if you ask them to tell you more about what’s going on for them, they will dig beneath the surface and see more of what’s really going on.
• ‘What are you learning?’ Again, we often need a little prompting to consider this.
• ‘What do you need?’ This is particularly helpful to ask with line reports – do they need advice, or permission, or an extra resource, or…? It can also help someone unblock whatever has been holding them back.

A note on structure. In an earlier blog, we looked at how you should use divergent and convergent thinking to shape workshops, appreciating that coming up with possibilities and ideas should be distinct from analysing and prioritising. That’s a helpful lens to use for coaching too. In the middle of your conversation, you want to encourage your coachee to think about many different avenues (divergent thinking). Towards the end you should help them narrow down to one or two routes to pursue (convergent thinking). Make sure you capture any actions or things they will do differently before you close.

Taking notes whilst coaching

I always take notes whilst coaching. It helps me concentrate on what I’m hearing and allows me to refer back to things later on in the conversation, or reflect back using the coachee’s own words. I do this on an online whiteboard because it helps me be less linear, and because it’s easier to group similar ideas together.

Once I got more comfortable coaching, I started sharing my screen so the coachee could see what I was writing. This is helpful for a few reasons. Just seeing the notes made the coachee’s thinking more concrete to them. It also made it easier for both of us to make links with things said earlier in the conversation. And it gives the coachee a record of what was said that they can look at later.

This technique probably won’t work for everyone – if you are a slow typist or self-conscious about your spelling mistakes, this might not be for you! But it’s worth experimenting with to help you take your practice further.

This is the third in a series on using coaching as an agile skill. Subscribe to my newsletter to get a regular round-up of posts.

As I wrote last week, creating space for others to think without creating answers for them results in much better quality outcomes. But this is difficult to do at first. That’s why I recommend starting coaching with a basic model that provides enough structure to make it easier to focus on listening rather than responding.

In a moment, I’ll share the model I use to teach coaching. But at the heart of any coaching is two basic tenants: ask good questions and welcome good silence.

Questions and silence

Of course, there’s a difference between an awkward silence where the coachee is confused by the question or waiting for you to say something, and a good silence where they are thinking. But if you pay attention, you should be able to tell the difference.  Remember that silence will feel a lot more uncomfortable to you than it does to them, and allow more silence than you might instinctually aim for.

A basic model: GROW

A simple framework to use whilst you are getting started is the GROW model. This stands for Goal, Reality, Options and Way forward. You structure your conversation around those four areas, asking questions like:

• Goal
  • What do you want to get out of this session?
  • What’s your overall aim for this area of work?
• Reality
  • How are things going at the moment?
  • What’s going well?
  • What’s going less well?
  • What resources are available to you?
• Options
  • What are some ways you could approach this?
  • What’s the pros and cons for each option?
  • What option do you feel most drawn to?
• Way forward
  • What will you do differently as a result of our conversation?
  • What actions are you going to take?
  • What will you do first?

Aim to spend most of the session on Reality and Options, with at least five minutes to explore the Goal and Way forward.

When to abandon the model

The list of questions is not a fixed set of things you must ask, but some suggestions you might find helpful. If the conversation goes in a different direction, feel free to follow it. Just make sure you are asking good questions that relate to what they have said.

It can be really helpful to summarise at regular intervals what you’ve heard and check your understanding. Doing this forces you to really listen and helps clarify for your coachee what they’ve been saying. It will also often prompt you to ask new questions based on your summary.

Starting a coaching session by asking about goals and finishing by asking about actions is almost always helpful. In between, you just need to ask questions to help explore their situation. If the GROW model helps with that, brilliant. If not, ignore it!

As you get more comfortable with coaching you will find some of your skills become automatic. You’ll feel more in the moment and able to ask questions as they occur to you, without worrying about structuring the conversation or what you’re going to say next. The model is like training wheels. Once your skills are more embedded, you won’t need the model any more.

Practices for getting started

One thing that’s really helped me grow my coaching skills is getting coached myself. It’s much easier to understand why you should let the person come up with their own answers when you’ve experienced this yourself.

But if you don’t have access to a professional coach, don’t worry. I often teach whole teams the GROW model, getting them to pair up and coach each other before swapping. My current team loves doing this and has instigated a regular coaching slot to practice regularly.

You don’t have to be brilliant at coaching to be helpful. I’ve been lucky enough to have professional coaching several times over my career, and each time it has been eye-opening. But I’ve also appreciated sessions with novice coaches who are trying out their skills for the first time.

Coaching is a skill you can learn, and learning it together reduces some of the pressure. Next week, I’ll talk more about how to take this further – how to become a better coach once you’ve mastered the basics. Subscribe to my monthly newsletter so that you don’t miss a post.