Using a game to foster safe and engaging conversations about responsibilities within teams.

In situations of change or stagnation, it can be helpful to have a safe way to discuss areas of ambiguity or disagreement. Here's a workshop that may assist.

Photo by Jordan Heath on Unsplash

When embarking on change in an organisation the focus inevitably shifts to who is doing what. What are each of our roles and what are the responsibilities of each role? How will we interact with each other and support each other for collective success?

Team-based product development using agile or lean approaches expects collective responsibilities but, in most organisations, distinct roles exist with a mix of explicit and presumed responsibilities associated. It can often seem straight-forward, we are merely the collection of responsibilities associated with our roles.

Of course, anyone who has worked in any form of organisation for some amount of time knows the reality of the collection of responsibilities an individual finds themselves with is more complicated than that. The responsibilities team members acquire can come from a variety of sources:

• the job description people were hired under,

• an individual’s personal history within the organisation,

• acquired through the continuous improvement decisions of the team,

• assumptions and expectations from their peers or managers,

• the expectations from the body of knowledge of their chosen practices.

When I was working at SEEK Asia, we had a mix of change and history to reconcile. We were looking for ways to enter into conversations where teams could discuss responsibilities in a fun, safe and engaging way.

I had grown a dislike of approaches such as RACI and RASCI, for while these approaches could in certain situations, serve a purpose I found that in most of my experience their use was often an indicator of distrust and a desire to ‘paint-by-numbers’ amongst a group of people.

I was looking for an approach that was more resonant with the complex interactions teams’ needed to navigate rather than creating a false impression that judgement could be put aside for a rule book. I had read a post (which I have spent hours trying to find again - if you know the one, I mean, please drop a link in the comments!) which suggested a simpler way to express responsibilities was simply to list which responsibilities were held by individuals and which were shared.

My colleague Tang Tze Chin took this kernel of an idea and added some brilliant ideas which became the core of the workshop I will describe in this post. The idea of using a game-like element for discovering as a group more about each responsibility and based on a group’s collective understanding, who was best to hold it.

Note: When expressing a responsibility, you can describe through the activity involved - ala how it might be expressed in a Job Description or similar document. Given my interest in the utility of describing things in terms of outcomes I’ve had a preference to experiment with expressing responsibilities in terms of the outcomes they exist to serve.

I found this way of expressing responsibilities to be quite an economical and accessible way to summarise a role or collection of roles in a goal tree. Each node in the tree is a ‘truth statement’ of what enacting the responsibility is seeking to ensure is true. Under a node maybe more specific truth statements which would need to be true for the parent statement to be true, normally with a focus on a collection of child statements which are sufficient together for the parent to be true. You can quickly crowd source a given role with a mindmap using this approach. You can flatten such a tree into a list of responsibilities.

Note 2: I have written this Workshop summary from memory. This is after a few years since the last time I was involved in running one of these so there maybe additional details, wrinkles and enhancements incoming from my ex-colleagues that address the fallibility of my recollection (I hope so! I’d like this to become a definitive documentation of this workshop for others to benefit from). I’ve run a session of this workshop again since writing this up with similar effectiveness for stimulating the sorts of discussion and clarification amongst a group I’ve associated with running these previously, giving me some confidence, I’ve captured the essence.

The Workshop

Purpose

To understand the responsibilities of key roles in product development - often focusing on a team (can be a delivery team, leadership team - I’ve applied this approach in various scenarios with similar success). We seek to understand what we are collectively responsible for and who will instigate the undertaking of each responsibility.

More importantly we wish to safely and engagingly enter into conversation about the responsibilities and unearth the expectations and assumptions each may hold. We undertake this with the knowledge that there is room and more importantly a preference to support each other in fulfilling the duties in a team environment.

Approach

This workshop consists of an activity prior to the workshop to identify responsibilities relevant to the roles of the participants and a game which can help clarify the most relevant role to hold the responsibility.

Resources and requirements

• 4-6 participants (8 Max as format adds time per participant)

• Meeting room - in-person preferred as it's discussion oriented.

• Digital or Physical board with stickies and pens. (Digital may be a bit quicker, time efficient)

• 1.5 hours

Detailed steps

There are two distinct components:

• Part 1 - Preparation: Identifying the responsibilities we collectively cover

• Part2 - The game: Engaging with the responsibilities to clarify and potentially redistribute

Part 1 - Map the responsibilities for the group - identifying the responsibilities we collectively cover

To identify the what we are collectively responsible for we can use a mindmap and brainstorm-style approach. This can be done as an offline activity although I suggest it can be an excellent workshop activity in its own right and this is what I have done most often.

If this has become a familiar practice in your organisation it is also possible to do this part as an offline activity where in the week prior to the game workshop (next

Book the meeting

I suggest block out a couple of hours. Plan to have short breaks every 45 mins to an hour - brainstorming activities in particular can be quite mentally taxing when done for sustained periods.

Avoid the temptation of trying to get it too perfect - the game mechanism will enable the responsibilities to be further elaborated and clarified.

You can do this as the facilitator however if you wish to be more involved in the discussion I suggest identify someone who could play the facilitation role. Ideally this is someone who is separate from the responsibilities that are being discussed or comfortable in their role that they can do this without needing to participate)

Prepare for the meeting

A collaborative white board with a mind map is a great mechanism for people to suggest areas of responsibility. A physical board with stickies can also work.

I usually start with some high-level outcomes that I the leader understand we are collectively responsible for.

By outcome I mean a statement about :

1. what is true now and we are are responsible to sustain.

2. what we want to be true in the future and we are responsible to change

These are not fixed in stone - you won’t have these perfect and they are the sort of model of how you collectively think about the organisation that you can evolve over time.

Start with something that is good enough and you will find even in a single session you will improve upon it.

Have the team start to identify things they are responsible for (again it helps to evolve these into outcome statements but if this is not yet a competency of your team, you can start by capturing in whatever form it comes up and refine later) and to add these onto the mindmap, either under one of the established branches or as its own branch should they be struggling to relate it to what is existing.

Don’t worry about identifying which role does which responsibility - add it all together on the mindmap.

You will notice the granularity of items will differ a lot across everyone’s contributions - there will be ‘here is a task I am responsible for’ through to here is a strategy I am responsible for. You and the facilitator can arrange into the mindmap hierarchy as you go - doing so in a conversational way - ‘this task is part of achieving this outcome, do we agree?’.

Try to avoid categorical relationships - ‘ah this is security related, put it under the security branch’.

Instead try to find causal relationships. i.e. ‘For this higher level outcome to be true we need these lower order outcomes to be true’. For instance, ‘to reduce the chance of a data breach’ we may need to ‘increase the awareness of our staff of cybersecurity risks’ which in turn might mean someone is responsible for the activity of ‘conduct the regular cybersecurity awareness training’.

You might find some responsibilities ladder up to contribute to multiple outcomes - that’s okay, most digital whiteboards will enable you to add a visual relationship beyond the limitations of the tree hierarchy that the mindmap provides. If its germaine you can mark these relationships rather than get bogged down trying to work out under which branch a leaf might ‘live’.

Again, avoid the temptation to over-engineer or get too perfect. Use the meeting duration as the time constraint. As long as you have a reasonable rough summation of the responsibilities you are all responsible for, that’s more than adequate. The next workshop will refine it further and resolve areas that maybe missed or less clear.

Part 2 - The game - engaging with the responsibilities to clarify and potentially redistribute

Book the meeting

2-3 hours is an appropriate amount of time. Plan to have breaks every 45 mins to an hour - the potential for social interaction and some negotiation can be taxing as can be trying to imagine various contexts across the team or organisation. Breaks will help the group not lose steam as quickly later in the session and the quality of contributions.

Setup your physical or virtual board. For virtual make sure you have setup the appropriate access for all participants. Better to have this working ahead of time than to lose time trouble-shooting in the meeting.

Create a table in your preferred digital or physical white board following the layout in the figure below.

As detailed in Part 1 we start with a list consisting of the range of responsibilities found across the roles in the team. We can take the mindmap we produced and flatten the leaves and branches of the mindmap into a list which we can add to the table I’ve featured in the figure below.

If you already had these as stickies you can place these down the first column of the table. You can usually convert the mindmap figure into other shapes such as virtual stickies so consult the documentation of your tool to work out how to do this most efficiently.

Note: Along the top of the table you can either:

1. List the names of the individuals amongst who we are looking to resolve the responsibilities across (this can be good for leadership teams where the responsibilities may be less about what is tied to their roles but how they are otherwise contributing as leaders).
   
   OR

2. List the roles across which you are looking to address friction around responsibilities for (this can be particularly good for software product development teams)

For this example I have chosen the the latter option and used Roles as the column headings. These could be roles such as Product Owner, Product Manager, Team Lead, Quality Assurance Lead etc.

The main activity of the workshop is a gamified approach for identifying and resolving who will do what, most of the time.

The value is more in the conversations had in the workshops than it is in the output from the workshops.

That said, the output can be cleaned up and leveraged as a reference to what was agreed. In practice I have found the memory of the conversations stickier and more resilient than the digital artifact that is produced. This is more a property of how relationships work and the sheer preponderance of digital artifacts which are better as memory aides should the memory of the interaction have faded.

The game

A round consists of each participant taking turns. The round ends after each participant has had a turn.

The game will complete as many rounds as there are responsibilities or as time permits. If you covered only a portion of the responsibilities and felt it valuable you might regroup and conduct another session.

Remember though, the goal is not completing the map of the responsibilities, its to address confusion or other friction around responsibilities. You might choose to wait and first see how any adjustments were playing out in the day to day work. It may have addressed the major frictions to a degree its no longer your biggest issue and its safe for the group to turn its attention to something else.

We can experiment with pre-filling some of the responsibilities we understand to be less contentious - these can still be challenged in the later steps. You can use these examples of how the game will work.

Each turn participant is invited to do one of the following:

1. nominate a responsibility for themselves from the list OR

2. to ‘steal’ an existing responsibility that has already been allocated to a role along with an explanation and discussion/clarification follows. It's common for any of the following to occur:

   1. Clarify that the understanding of the responsibilities is unclear and improve.

   2. Identifying a responsibility as described actually represents multiple responsibilities which can be broken down into more specific and meaningful responsibilities.

   3. Identify where ambiguity may exist, but which is beyond the scope of the workshop and book time to follow up and resolve.

Note: Other participants can ask clarifying questions to understand their choices. It’s not uncommon for there to be mention of other responsibilities which we did not have in our initial list. Its allowable to add these to the responsibilities list available for participants to choose from.

We can use a physical or digital board for this activity. The stickies usually start listed under the responsibility column and each turn one is allocated under a role (we’ve also used this amongst small teams and replaced the role columns with the names of the individuals).

We use a ‘parking lot’ for larger topics which may need more focus than the momentum of the game format allows for, or which may prove to be a distraction and deserves its own time and attention for resolution.

The game ends when the time is exhausted, or the responsibilities have all been allocated and all participants have completed their final opportunity to steal.

How do you approach similar challenges? Do you have a different approach, or did you do something similar to what I have described? If you try this workshop format, let me know how it went in the comments.