Facilitating a meeting means guiding the process to make sure everyone can participate and you meet your goals for the session. It’s all about asking good questions, creating shared thinking spaces and keeping conversations on track.

There’s a difference between chairing and facilitating meetings. Whilst a chair actively leads a meeting to reach certain conclusions, a facilitator creates the space for the meeting to reach its own conclusions. This is a vital shift in perspective for working in an agile way.

Facilitating good meetings is an agile skill

Effective collaboration is at the heart of agile and unsurprisingly, meetings are a big part of that. That’s true whether you’re using agile ceremonies like retros and backlog refinement, diving deep into big topics with design sprints, or taking a less formal approach to implementing agile. Facilitation skills help you get the most of those meetings.

More than that, both agile and facilitation draw on similar mindsets. Both recognise that empowered teams are more effective. Enabling people to make their own decisions gives them ownership and makes the best use of their knowledge. Doing this collectively draws on the wisdom of the whole group – and facilitation skills enable you to do just that.

Reflection and adapting as a team are also core to working in an agile way. It’s very difficult to do either of those things without talking about them. Good facilitation helps you create the psychological safety necessary to give feedback, admit mistakes, be open to trying things differently and generate new ideas.

In other words, facilitation gives you the tools to live out the agile mindsets.

Can you still use agile if you don’t have a facilitator?

Most tech teams using agile will have a formal facilitator-type role, whether that’s an Agile Lead, Delivery Manager or Scrum Master. But that’s rarely available outside of tech.

Teams without dedicated facilitators can absolutely still use agile though. Facilitation is a skill you can learn, and agile is an easy place to get started! Many agile techniques involve tried-and-tested approaches to recurring meetings, giving you a simple structure to follow. All you need to do is to follow the established pattern.

Not having a dedicated facilitator also has several advantages. I always encourage team to take it in turns to facilitate simple meetings like stand-ups. This helps distribute the power more evenly and gives everyone more ownership over the practice. It also stops there from being a single point of failure if your normal facilitator leaves or is unavailable.

Most agile practices are fairly straightforward. There’s lots of ways you can take it further once you grow in confidence as a facilitator, but it’s also fine if you want to stick to the basics.

How to get started with facilitation

I’m going to say it again because it’s very important: facilitation is a skill you can learn. There’s some basics you need to know about meeting structure, but beyond that it’s a skill that comes with practice. Over the next few weeks I’ll share practical tips on getting started, covering the fundamentals and some advice on maximising your learnings as you try things out. If you want to stay in the loop, subscribe to my newsletter for a monthly roundup.

But for now, I want to give you permission to think of yourself as a facilitator. And this means you have permission to not have the answers. Your role is to help people come up with their own answers together.

Here’s your challenge: in the next week, can you ask a question in a meeting where you truly don’t know the answer? Listen with curiosity to the responses and summarise what you hear. That’s step one to being a good facilitator!

Strategy and agile can seem at odds. Agile is all about working in short loops, learning and adapting as you go. That seems like the opposite of the long-term approach needed for strategy.

But many common problems with strategies could be addressed if they were approached in a more agile way. How often have you seen a 5-year strategy that’s no long relevant after 18 months? Or worse, you don’t know if it’s relevant because no one refers to it or remembers what it says?

A good strategy should be a live document. It should paint a picture of what you’re trying to achieve whilst still giving you space to adapt as you learn things along the way.

Agile mindsets for strategy

Agile mindsets changes how you approach strategy. Most importantly, they encourage you to learn and adapt as you go. The lesson here is similar to one we discussed about project plans: recognise you can’t predict the future. For planning, this means thinking big picture in the long run and only getting down to details in the short term.

For strategy, it means starting by thinking about the big picture outcomes you want to achieve, then identifying some strategic bets that might help you get there. Break these down so you are trying something small, building in reflection points so you can learn and adapt as you go. Be much more detailed about what you will do in the short term, and keep long-term plans at a high level.

In short, get clear about why and what you want to achieve, but work out how you’re going to get there as you go.

You should still be making clear choices in your strategy. This toolkit from the Charity Change Collective explains it well: strategic decisions are considered choices made after having considered your options. If there’s no possibility of failure, it’s not a strategic decision – that’s just business as usual.

This probably means that not everybody will agree with your strategy off the bat. But the other agile mindset that’s helpful here is about sharing power.

Strategy shouldn’t be developed by a small group of senior leaders in isolation. Firstly, they will miss things. Hearing from diverse voices exposes you to more ideas and strengthens your thinking. And secondly, it’s much easier to get people on board with decisions that they had a hand in making, even if it’s not exactly what they would have chosen on their own. Collaborative decision making gives ownership to everyone involved, so think carefully about who you need to own your strategy and how you can get their input.

Tools for shaping strategy collectively

How do you do this in practice? I would always start by gathering insights. Again, you want to hear from diverse voices and a range of sources here. Make sure you are learning about your audience, your products and the market from different perspectives. Done well, some of this should surprise you. If you are only looking at insights that confirm what you already think, you’re probably not looking hard enough!

I’ve got two tools I like to use with groups who are exploring strategy once they have spent time reflecting on insights. The first is affinity mapping. That’s a fancy name for just theming. Start by asking people to individually add possible answers to a question like ‘What options could we consider?’, ‘What principles should guide our choices?’, ‘How should these insights change our approach?’. Use physical post-its or an online whiteboard for this, getting people to add one idea per post-it and setting a time limit of five minutes or so.

Once the time is up, ask them to cluster similar post-its together. Then go cluster by cluster, suggesting how you could summarise those ideas and asking the group to improve your wording. This gives you a set of clearly articulated thoughts that draw on the wisdom of the whole group.

The other tool I like to use is even-over statements. These help you make those concrete choices I discussed earlier. For this, give people pairs of conflicting choices. For example, would they choose long-term growth or short term income? Would they prioritise new audiences or existing ones? Get everyone to place a dot on a scale from one extreme to the other and use their votes to inform where you land on each decision. ‘We prioritise x even over y’ forces you to articulate what you are focusing on, rather than letting different people assume different things.

What have you seen work well in developing strategy? Do you have any tools you like to use?

Last week, I said that great project planning starts by collectively setting outcomes as a project team. But how exactly do you do that? And what else should you include in a project kick-off?

How to set outcomes together

Collectively deciding what you want to achieve from a project means that everyone involved has ownership of those goals. It gives you a north star you can refer back to throughout the project, which is very clarifying when tensions crop up. And people like being asked! Giving everyone a chance to share their personal goals for a project means they are more bought in to what you decide on together.

Setting outcomes collectively can be simple. It’s helpful to give people a chance to input individually so you aren’t led too much by the chattiest people in a discussion. This is easiest to do on on online whiteboard or with physical post-its, but you could adapt to do this in a shared document or in the meeting chat if necessary.

Give a little context to the project and then ask everyone to individually add what they are hoping to achieve together. Set a timer for about 5 minutes for this, allowing everyone to work in silence. When the timer is up, ask the group to theme similar answers together. Some clear themes should emerge!

Often, project managers avoid doing this because they are afraid that the goals the group decides on won’t match their desired outcomes for the project. But I have never seen this happen. The group might nuance what the project manager would have said (usually in helpful ways!), but it’s very unlikely to contradict it. And frankly, if your group does have very different goals, this is true whether or not you take the time to find this out. It’s always better to know – and given the thinking space, people will usually hone in on similar goals.

What else should a project kick-off include?

I’ve written about some things it probably shouldn’t include: complex RACIs or detailed long-term plans. But a project kick-off is an excellent chance to set the tone for the rest of your project and answer some big picture questions.

It’s helpful to start by thinking about the relational aspects: do the project team already know each other? Do they have established ways of working together? If not, I recommend dedicating time to a get-to-know you style icebreaker. You might also find it helpful to run something like a team charter, identifying the values and behaviours you want to live out as a group.

What’s different about an agile project kick-off?

There’s no one agreed formula for kick-offs in agile. But kick-offs are a key moment to start embedding some mindsets, especially things like empowered teams. By deciding on your outcomes and maybe a team charter together, you are already modelling that you aren’t going to work in a top-down way.

In an agile approach, it’s important to start by getting clear about your outcomes. This means the difference you want your work to make, rather than the tasks you’re going to do to get there. For example, a mailing or an email series are both examples of outputs. Inspiring people to take action is an outcome. Spending time on this in your kick-off helps make sure those outcomes are at the centre of your project.

Finally, your project group might explicitly decide to use some agile tools like stand-ups or retrospectives. Your kick-off is a great moment to agree how to approach things like keeping each other updated. Remember, you don’t have to use a particular tool to approach things in an agile way. The mindsets (like empowerment and outcomes focus) are more important.

Sample agenda for a winning agile project kick-off

Let’s pull this all together. This is how I would spend the time in an hour-long kick-off meeting:

1. Check in (10 minutes). Ask everyone to answer a getting-to-know-you question (eg ‘please share your name, role, and a highlight from your week’).
2. Context (5 minutes). Introduce the project and any context people should be aware of. Keep this short – you want the bulk of the meeting to be interactive.
3. Outcomes (15 minutes). With that context, what outcomes do you each of you want from the project? Give people a few minutes to note ideas individually before theming and discussing.
4. Team charter (20 minutes). Give people three minutes to note down values you want to share, theme and summarise, then do the same thing for how  that translates to behaviours.
5. Check out (10 minutes). Summarise your conversation and explain next steps, including the pattern of any future project group meetings.

Are there other activities you find helpful in a project kick-off?

Like RACIs, project plans have a lot to answer for. Most project plans are hard to read, hard to update, and almost immediately out of date. I’m pretty sceptical of any project documentation that requires lots of time spent up-front to only approximate the reality of what you are doing, and project plans are often an example of just that.

With agile, instead of spending a lot of time developing a detailed plan at the start of your project, you take a more iterative approach.

That doesn’t mean you do no planning. But it does recognise the limitations of planning.

Why planning is difficult

It’s helpful to start by recognising why planning is so hard. The biggy is that things change. We have imperfect knowledge to start with about how long something will take, even before you take this into account. But inevitably, what’s true at the start of your project won’t be true six months in.

Someone will leave your organisation, or the priorities will shift for a team you rely on. Things change externally too – tech, legislation, public opinion, the economy… It’s increasingly true that unpredictable global events will impact what you are working on. And the further ahead you try to predict, the more unpredictable things are, both internally and externally.

More than this, things should change. You should be learning things as your project progresses that change your approach. A project plan that doesn’t allow for this is unhelpful!

Deadlines are difficult too. We tend to use them to keep projects on track, but when things change, deadlines change too. This causes two problems. Firstly, setting and adjusting deadlines is very time consuming. It’s easy to spend a ridiculous amount of time repeatedly updating dates on a Gantt chart.

Secondly, deadlines do funny things to your brain. We use them as a signal of importance, but urgency is not the same as importance, and most deadlines are somewhat arbitrary anyway. This leads to lots of stress trying to meet deadlines that probably weren’t realistic in the first place. And this isn’t necessarily the same as doing the things that are most important for your project.

An agile approach helps address these challenges.

Things change, so your plans should too

When you work in a more iterative way, you stop trying to plan the future in detail. Instead of nailing down every step you are going to take, you start by working out what outcomes you want to achieve and then consider what you can do now to help you get there. Only once you’ve done that do you consider your next iteration. In other words, you plan in detail for the short term, but stay much more light touch for the long term. There might be some big milestones you need to meet along the way, but beyond noting those you don’t spend much time planning an unknowable future.

This only works if your plan is a live document. This means it needs to be easy to update (a Kanban board is much better for this than an Excel document), and you need to have a regular structure for reviewing it so that you are maintaining your planning for the short term. This is where I sing the praises of stand-ups again. Using a similar structure (perhaps less frequently) for project plans at a regular cadence allows you to plan as you go and keep things on track.

Avoid deadlines where you can

This one is counter-intuitive. But it made a huge difference when I stopped trying to add deadlines to everything. And holding on to deadlines is one of the biggest blockers I see to teams trying to adopt stand-ups.

If you are truly reviewing your plans at regular intervals, you shouldn’t need the deadlines just to make sure you do the work on time. Instead, each time you review your project plan, you should be prioritising what work you want to do before your next review. This gives you the opportunity to spot if something is truly time-sensitive and needs to be done now. But it also allows you to take other factors into account in your prioritisation, so ultimately you make better informed choices.

My formula for an agile project plan

Ok, that’s a lot of theory. But what does this look like in practice? You still need to do some work up front. It’s just not as detailed as in a non-agile approach.

1. Start by spending time working out what outcomes you want from the project. If you can do this collectively as a project group, even better – it helps give them buy-in and ownership for the final results.
2. Break the work down into areas (eg marketing, website development, internal comms). List any activities you are already aware of under each area (eg develop marketing assets, chose marketing channels etc).
3. Plot activities on to a high-level roadmap. For some projects, there will be natural phases you can split things into, but if not, keep it simple! A Kanban board with columns for ‘now’, ‘next’ and ‘later’ should do the trick. You should have just a few things in the ‘now’ column and lots more in ‘later’, to help you plan in detail for the short-term whilst keeping the long-term light touch.
4. Review your roadmap regularly. The frequency will depend on the type of project, but make sure you have a regular, predictable pattern to review. This probably needs to be at least once a month, and possibly as often as weekly. Each time you review, plan in detail for what you will do between now and the next review. If you think of something that needs to happen later on, capture it so it’s not floating round your head. But you won’t plan that in detail until you get to that point.

How do you approach project planning? Do you have a rhythm that works for you?

When we think about accountability, we default to thinking about managers. Managers keep people accountable by telling them what to do, and creating consequences if they don’t do those things.

But people aren’t dogs waiting to be biffed on the nose with a rolled up newspaper for peeing on the carpet. When someone fails to do something they were accountable for (or that their manager thought they were accountable for!), this is almost always down to a lack of clarity, skill or motivation. Clarity is the big one: they didn’t fully understand the task or their role in it, or they weren’t clear on how to prioritise it over other things. Lack of skill is straightforward: perhaps they just aren’t able to do what they’ve been asked to do.

Motivation is more subtle. It’s usually not that people lack any motivation to do their jobs and are continually looking for opportunities to goof off. But often we lack motivation for tasks that are ambiguous or where we don’t understand the purpose. Both of these come back to a lack of clarity again, and more importantly, to a lack of ownership.

Whatever the reason, relying solely on managers telling people what to do isn’t the solution for accountability. We often expect managers to give full clarity about responsibilities in a single conversation, but this is a big ask!

Managers don’t know everything. They don’t know what their report doesn’t know. And they often don’t know what their report does know, the things the report is aware of that will impact on the task. Managers shouldn’t try to be experts in everything their report does – that limits what the team can achieve to just the things the manager knows about in detail. It’s good for a team when different people develop different expertise!

Teams perform best when each person has clear ownership for their responsibilities, and can develop their expertise in those areas. Just telling people what to do isn’t going to achieve this.

What does work for accountability?

Clarity and ownership are the essential ingredients for accountability. And agile can help with both of these.

I talked a couple of weeks ago about how stand-ups can bring much greater clarity on responsibilities. Having quick, regular and structured conversations about what people are working on makes it clear what the expectations are and reveals blockers early. If someone doesn’t understand a task, or doesn’t have the skills to complete it, that should quickly become obvious in your stand-ups. And this shouldn’t be threatening – stand-ups are not a space for managers to catch their teams out. Instead, stand-ups should be a safe space for team members themselves to raise questions and concerns and get support if they need it.

One of the surprising shifts you make in stand-ups is that it stops being just the manager holding people accountable. Instead, the whole team is setting expectations about what’s needed, observing whether people have completed tasks they have committed to or not. And it goes both ways – the team gets to keep the manager accountable to their commitments too.

Stand-ups are my number one tool for creating clarity. But agile can help with ownership too. The shift I just mentioned is part of this, as it gives the whole team a clearer collective responsibility for their goals.

The other big shift is involving people in the decisions that affect their work. Being a more empowering manager gives people the opportunity to affect direction, which in turn gives them more ownership. This works even better if there’s space to create a shared vision for the work, perhaps using one of my favourite meeting formats to get input from the whole team about what you are trying to achieve.

The manager’s role in agile accountability

This might sound like the manager has no role in creating accountability in an agile approach, but that’s just not true. Instead the manager’s focus shifts to creating the structures that create shared accountability. Managers have an important role in modelling behaviour – for example, sharing when they are stuck and need help; or committing to work and sticking to those commitments. They can also use a coaching style to increase accountability, either by making observations (‘I notice we haven’t made any progress with this task for a while now’), or by asking questions (‘What’s realistic here?’, ‘What would you need to finish this by our next meeting?’).

Working in an agile way doesn’t abdicate responsibility for managers. It just helps them shift from a top-down model to a more shared approach to accountability. And ultimately, that’s more effective.

How do you create accountability? Have you found ways to do this collectively?

This is the first in a series looking at the agile approach to areas of our work we often don’t think about enough. Next week, project planning!

Last week, we discussed why the RACI model sucks. Planning out responsibilities in detail at the start of the project can prevent you from learning and adapting as you go. A much better approach to divvying up responsibilities is to have a regular, structured conversation about them.

That’s the “R” in RACI, but what about the other letters?

Most people find “consulted” the trickiest bit – involving everyone who needs to input into a decision, without a massive, unwieldy process. How can agile help with this?

Reduce how much input you need

Perhaps unexpectedly, I’m going to advocate for involving fewer people than you think in making decisions. This is despite what I say about the importance of empowering people through collective decision making. The critical distinction here is that decisions should be made by the people doing the work, rather than a long list of senior stakeholders or others who are peripherally involved.

If there are a dozen people you need to consult every time you make a minor decision, nothing will get done. But you can avoid this by spending more time upstream.

Invest time in collectively agreeing some bigger picture outcomes you want to achieve together. Then use these as the basis for your individual bits of work. Most people prefer to be consulted this way, as it allows them meaningful input without commenting on endless drafts. It also means you can move much more quickly once you’ve got started.

How do you do this in practice? It could be as simple as spending some time in a project kick-off meeting individually capturing what outcomes you would each like to see. Theme the answers and use these to set your overall goals for the work.

You can reduce other consultation needed further by giving people tools to help empower them to work independently. Perhaps you want everyone to draw on similar messaging, reference some key facts or use certain layouts in the design of their work. If so, give them a toolkit explaining all that.

Get feedback efficiently

Of course, there will still be times when you need to get feedback. How can you make the process as smooth as possible?

Perhaps you can get all the input you need in a single meeting discussing a concrete proposal, using the silent meeting format I’ve talked about before. Or maybe you just need to make a collective decision and some agile decision making tools might help you.

Where you do need to lots of people to comment on something, give then a clear and transparent process. This could be a live document where everyone can see other people’s comments, accompanied by some clear deadlines. Make it clear that if you don’t receive feedback by a certain date, you aren’t able to include it.

One person should own the process and resolve any competing feedback. Approach this with the mindset of being an informed captain – you are ultimately responsible for the decision, but you will take time to listen to input along the way. Netflix use this approach and says it allows them to be ‘highly aligned and loosely coupled’, which is a great way of putting it!

What about you – how do you manage who gets to input into decisions?

Working out who should be Responsible, Accountable, Consulted and Informed on a project should make roles much clearer, right?

Wrong.

Every time someone asks me for a RACI, my heart sinks. I have spent so much time agonising over so many RACIs that only a few people have even skim read. There must be dozens of massive spreadsheets I’ve written over the years to try and answer some basic questions about roles and responsibilities. Yet every time questions pop up, it seems unclear. A RACI might be a helpful starting point, but as soon as your project starts you will think of things you haven’t covered, or discover nuances in things you have covered.

If I’m honest, my RACIs have been expectation setting of the worst kind. It’s me saying ‘I’m not going to consult you about an important decision, and I’ll use this spreadsheet you won’t read to justify this to you in a few months time’. And that’s… not great?

I’m not saying that we shouldn’t set expectations, or that we should involve an unmanageable number of people in every tiny decision. But we use RACIs as the decision making equivalent of security theatre. It’s a bureaucratic piece of admin we spend a disproportionate amount of time on, given how little they help in day to day work.

What does help instead of RACIs?

The goal of RACIs is laudable. We want to be clearer about two things: firstly, who is responsible for tasks, and secondly, how decisions work – who gets to make or input on the decision and who is just informed. One spreadsheet can’t do all of this. But agile tools can be a significant help.

Let’s look at responsibilities first. Next week, we will dig into how to get input into decisions.

Use stand-ups to get clearer on responsibilities

The only way to get clearer on responsibilities is to have regular conversations about them. We’re rubbish at predicting the future and it’s next to impossible to outline all the tasks involved in a project at the outset. So don’t try to do that!

Taking an agile approach means planning in detail for the short term, and keeping it very top-line for the longer term. This is both much more realistic, and much simpler and easier to do.

One tool lots of teams I work with have found really helpful for this is a stand-up. Stand-ups are short, frequent meetings to streamline team communication and quickly address concerns. They take 10-15 minutes and are traditionally held daily, though I’ve found that weekly or twice-weekly can work well depending on the type of work.

For a stand-up to work well, you need a visual record of your work. You can use Microsoft Planner, Trello, monday.com or a similar alternative for this. The tool isn’t important, but how you use it is. All you need to do is make sure you’re capturing all the tasks for your piece of work under either “work in progress” for things you are working on now, “blocked” where you are waiting for something outside your control, and “to do” for anything you haven’t got to yet.

In a stand-up, each person should run through the tasks with their name on that are in progress. They should do this very quickly, just flagging if there’s anything unclear or where they might need some help. They should briefly check what’s blocked or still to do to work out whether they want to move anything to “in progress”, before passing to the next person.

This is a very simple format that you should be able to get through quickly. And there’s lots of benefits to holding stand-ups. They help you keep track of lots of moving pieces and they are an efficient way to make sure you are collaborating effectively. They also mean you are having regular conversations about workload so it’s easier to split this more evenly across the team.

But an underrated side effect of stand-ups is they quickly surface unclear responsibilities. You should spot immediately if there’s a task with no one assigned to it, or if someone is struggling with a task that’s bigger than they can handle. There’s no more mystery, no more hoping someone else will jump in. Having a regular, structured conversation means you will achieve clarity much more quickly.

That’s one way agile helps with clarifying responsibilities. Next week, we’ll look at the other important element of RACI and consider how you should involve people in your decision making.

In the meantime, I’d love to hear what you make of RACIs. Am I the only one who hates them? How do you approach clarifying responsibilities?

I think silence is an underrated agile skill.

That may sound odd, but fundamentally agile is a set of tools to help people collaborate and reflect. And you can’t do either of those things without silence.

Silence helps you pause, slow down and spot what’s happening. If all your meetings are non-stop talking, no one has a chance to think. It’s also harder for the quieter members of the group to speak up. Silence makes for much better meetings.

How silence feels to the facilitator

It might be incredibly valuable, but at first, silence in a meeting you are leading is so uncomfortable. Very often it induces mild panic. ‘Why is no one speaking? Argh, what do I do now?’ But once you get used to it, it can actually start to feel freeing. You know that thinking is happening, and if you just give it a moment, something unexpected will emerge.

Imagine gazing into a still pool of water. It might look like nothing is happening, but fish are swimming round below the surface. If you wait, one might emerge. But if you plunge your hand into the pool, you’ll never see them!

Thoughts are like fishes. Don’t scare them away by speaking too early.

How to tell if it’s a good silence

There’s two kinds of valuable silence in meetings. One is the silence of people working together individually. Maybe you’re getting them to note down thoughts on post-its separately, or you are using something like the silent meeting format we talked about last week.

If you can see people writing, the silence is working and you can leave them be. If you’re not sure, it’s a good idea to set a time limit for activities like this. It’s much more comfortable to be silent for a limited period, and no one will mind if it’s a minute or two longer than they actually think they need.

The other valuable silence is thinking time in response to questions in group discussion. This is harder to judge. How long should you wait before you should break the silence yourself with another comment or prompt?

It’s probably longer than you think. Silence feels much worse for the facilitator than for other participants, because you feel responsible for it. What seems like eons for you probably isn’t that long for the other people involved. And it can actually be a good thing if it starts to feel a little awkward – it gives an extra push for others to start talking.

So in general, hold your nerve and err on the side of more silence than you think. As long as you asked a good, open question that people could potentially answer, allow them the time they need to respond. Keep your questions simple and broad to make them easier to answer. ‘What stands out here?’ is my favourite for getting a conversation going after a bit of individual thinking.

How to get comfortable with silence

The best way to get comfortable with silence is to practice. Try holding a slightly longer pause in your next meeting and see what happens. Or watch what other experienced facilitators do, and notice what makes it easier for you to give good answers.

If you’re nervous about using silence, tell people! Explain at the beginning of the meeting that you’re trying to create more space for thinking and this might mean you go quiet after questions to allow people to process. Ask for feedback after your meeting to see how people found it. Chances are it will have been a lot easier on them than it felt for you.

Do you use silence in your meetings? How did you get used to doing that?

We’ve talked about empowering the team as part of working in an agile way, and how to make collective decisions as part of that. But what if you need to dig into a problem as a group before you make a decision? Here are three of my favourite tools to do just that.

Lean coffee

Lean coffee is a super simple, low-effort technique. It’s great when you have something you want to unpick but you don’t know where to start. It also works well as a way for attendees to build their own agenda in regular team meetings. And it requires very little prep!

All you need to do is introduce a topic and get people to tell you what they want to talk about. I usually give people three minutes to write down questions or ideas to discuss relating to your topic. Then we share and theme answers, before each using three votes to prioritise between them. We discuss the areas with the most votes, capturing notes and actions, continuing until we run out of time.

It’s easy, flexible, and makes sure you are actually talking about what people most care about.

Innovator’s compass

My next format is based on asking powerful questions. There’s more about how to do this here, but again it’s very simple. All you need to do is ask in turn about:

1. Observations: what’s happening and why?
2. Principles: what’s most important here?
3. Ideas: what could you try?
4. Experiments: what’s one thing you will do?

I suggest giving people 3-5 minutes to make notes on the first three areas individually, before sharing and discussing as a group. Then use dot voting to prioritise your ideas and flesh those out in the experiments stage.

Starting with observations and principles gets people thinking and leads to rich ideas for the third question. And ending with experiments helps you turn your ideas into practical actions.

Silent meetings

This works well when you want to discuss an existing idea in principle – perhaps someone has a proposal or a straw man that you want to get input on. The Silent Meeting Manifesto has lots of great tips for writing a good proposal for this.

Once you’ve got something concrete in writing, you meet to discuss, but you spend the first half of your meeting in silence. Everyone reads the document individually, adding comments and responding to others in writing. You only talk after everyone has finished reading and commenting, discussing any questions highlighted in comments that still need resolving.

I love this format. It’s much more efficient because everyone reading and writing at once is much faster than talking one by one. You end up having richer discussions, as the process of commenting means everyone has to really engage with the material so you start with a much clearer shared understanding of the issue. (No more endless recapping for people who didn’t do the pre-reading or who lost the thread during a boring presentation).

It’s also a good way to ensure more people participate, firstly because inputting in writing is more efficient, and secondly because lots of people find it easier to contribute that way than speaking up verbally in a potentially contentious discussion.

Those are three of my favourite group problem solving techniques. Do you have any others you would add?

Last week, we touched on the need for leaders to share power as a necessary criteria for working in an agile way. Flatter power dynamics have all sorts of benefits. Working in a less hierarchal way reduces the pressure on you as a manager. It uses the wisdom of the whole team, including those closest to the work who are likely to have the greatest understanding of the possible consequences of any decision. It’s great for getting your team to buy into the decisions and understand them on a practical level. And it’s good for your team’s development and critical thinking.

But how do you actually empower your team as a manager in practice?

Leaders go last

Who gets the most speaking time in your team? If power is well balanced, share of voice should be well balanced too.

For this to work you need to account for style differences. Whatever their preferences, level of introversion or neurodiversity, you need to make it easy for everyone in your team to contribute.

This means you need different ways they can give their input. If you always lean on group discussion and find you just hear from the same people, that’s a warning sign. Think about capturing written contributions, or asking people to chat in pairs before asking them to share idea. And don’t knock an icebreaker. Even for well established teams who know each other well, a good icebreaker can make it easier to contribute risky ideas later on in the conversation.

Remember that people tend to listen to you more when you are the manager, even when you’re not the best placed for an informed opinion. That’s why it’s a good idea to go last in a group discussion. Give everyone else a chance to share their views before you air yours. That way, you reduce the chance of influencing the conversation so that everybody agrees with you.

Sharing decision making

Hearing equally from the whole team is a great start. But it’s not enough if you still make all the decisions.

Practically, it’s much easier to make collective decisions than most people think it is. Spend time mapping out your options together, then use something like a dot vote to choose which one you want to go with as a team.

There’s lots more collaborative decision making tools in my guide to making better decisions with agile. But the important thing is to open your decisions up. Yes, there are some HR type decisions that only you as the manager can decide on. But if you start looking, there’s lots of scope to include the whole team in deciding what you’ll work on and how you’ll do it.

Go where your team tells you

If you make decisions as a team, you aren’t going to agree with all of them. And that’s ok. A helpful question to ask yourself is “is this safe to try?”. If trying something is hugely risky, that’s a good reason not to do it. But most things aren’t. And the benefits you get from empowering the team outweigh the downsides, especially if you are reflecting regularly together so can course-correct if something isn’t working out.

So if you hear your team telling you they want to go in a certain direction, listen to them. If someone gives you constructive feedback, visibly demonstrate that you are taking it on board. If someone wants to try something, work out what needs to be in place to make that safe to try.

What practices help you be an empowering manager?