It can be tempting to wish that meetings weren’t a thing, or at least that all of them were expertly facilitated by someone who has put the time into preparation and the has the skills. Sadly this isn’t the case. You’re going to have to work out how to cope in meetings, and many of them won’t be run as well as you might hope.

From my experience as you become more ‘senior’ you’re also more likely to get invited to different kinds of meetings where you might be being asked to represent your team or department rather than necessarily provide your expert opinion on a topic you know lots about.

What I’ve observed about meetings:

• Generally people don’t book enough time for meetings, especially with senior people. It’s a combination of people being too busy, and a desire to use time limits to make decisions. Unfortunately my experience has shown that it mostly results in needing another meeting.
• You will almost certainly get asked about something you don’t know about, or feel confident responding to in detail.
• Things like tracking actions are a very mixed bag. A standing meeting (e.g. a working group) might have established terms of reference, and someone responsible for tracking actions, but most are ad-hoc and everyone attending is generally too busy to track them properly.
• Meetings very often get put in/forwarded at short notice, maybe with documents to read or to respond to.

Obviously not a lot of this is ideal, especially if you’re used to working in a digital/product team that includes roles for facilitating sessions, tracking plans and a culture where it is OK to say that you don’t know, but can find out.

Coping mechanisms I’ve developed:

• If I’m not facilitating or leading a meeting, I try to split the session in half in my head. For the first half I mostly listen, and then save my contributions for the second half. In my head this means that even if I start with very little context, I’m able to contribute more informed thoughts by the end. It also helps me get a read of the personalities and priorities in the room before deciding what to say, and how to communicate it best.
• If I’ve been forwarded on an invite, or asked to attend something I’m not familiar with, ask for some notes of context before I join. This could be to find out what has been discussed before, any actions that someone might be expecting me to report back on or even just to get a handle on the personalities in the meeting and any existing dynamics.
• Acknowledging and being willing to accept criticism or question. Starting from the perspective of everyone wanting to make something (a design, an organisation, a process whatever) better is helpful. If you feel that the critique isn’t focused on your goal, take the opportunity to share what your priority is. It might be that you have very different priorities, and surfacing that is helpful.
• Writing notes of the meeting either live (if possible) or immediately after the meeting (again if possible) and sharing them with my immediate team. For me this means slack, but your platform may vary of course. I find this helpful when others do it, because it helps me build context about conversations I’m not in, and helps demystify some of the meetings that might appear ‘behind closed doors’. It can also help to highlight urgent actions that need picking up.
• Asking questions that focus on what evidence we have to make decisions, and whether there are ways we can get better information quickly before making decisions. I’ve captured some generic examples below.

If none of this sounds groundbreaking, it’s because it isn’t. I’m not an expert, and I don’t reliably get it right. But these are some of the ways I survive and have hopefully contributed to meetings as I’ve become more senior and moved away from ‘design’ on an everyday basis. 


Examples of questions:

These are some of the standard questions I often fall back on in meetings. They’re generally focused on being more ‘user-centred’ and de-risking by prototyping and testing early.

It’s hard to write generic questions, because they sound quite…generic. But these are examples that have worked for me:

Questions to encourage user research:

• What is the riskiest assumption we’re making here, that could undermine anything we do next?
• What is stopping us getting this into the hands of someone who might use it?
• How confident are we that the evidence we have also applies to this situation (i.e. is something that we ‘know’ actually true in this situation?)
• Is there anyone outside of this conversation who would have strong views on this? What would be the best way to include them?

Questions to encourage prototyping:

• Is there something we could create to help us answer that question?
• What’s the simplest way we could make this feel real for people who might actually use it?
• How could we mock this up, even if it’s only part of it?
• What could we do now to increase our confidence that this is a good idea?
• Could we use any off the shelf tools to the test the concept before we go any further?

Questions to encourage a test and learn approach:

• How can we break the problem/solution down into smaller chunks, and which of these is the most important?
• If we could only do one of these things, which one would have the biggest impact based on what we know?
• Can we make the commitment (contract, trial, plan etc) shorter term, and make sure it is reviewed after that time?
• How are we going to decide if it’s being successful and what will we do if it isn’t?
• What’s the risk if we just tried this? And is that an acceptable risk?

I think it’s important to point out, that people generally do ask these questions (or similar) about things that are very ‘customer facing’ i.e. a new website or app. I’m particularly interested in asking these questions about stuff that doesn’t usually get that level of attention. This could be anything from an intranet, a new training program, communications, or internal processes.

Hopefully some of this is useful for you, feel free to let me know!