The Taps Model: A tool to explore cognitive overload

Introduction

As I explained in a recent post, leadership can be tough. Leaders can take on many responsibilities and, during challenging times, the weight of their role can cause significant stress. Leaders are apt to stoically struggle on in times like these and that can exacerbate the problem.

I’d recommend that leaders consider the extent of their responsibilities and the risk they take on by accumulating too many important tasks and interests. Following that exploration they should prioritise, schedule, delegate or dump threads of work, as they see fit.

To help coaches, managers or peers engage in these conversations I’ve come up with a tool that my team and I have used to explore the pressure exerted (self-exerted, in many cases) on some of our team leaders. We call it the Taps Model. In this post I’ll explain what it is and how to use it.

Background

A new technical team lead role was established at Redgate in mid-2016. Overall, we consider it to be a successful introduction and a key role. However, it can be a very challenging job and almost every technical lead has had to deal with stressful circumstances at some point. In fact, there have been a number of cases of people stepping away from the role. Sometimes this has been because of stressful situations and sometimes this has been because a technical lead has come to realise the shape of the role is not for them. In every case we have looked to support and guide our technical leads through these troubled waters but really we’d like to see these difficult times coming and take early action to avoid them if at all possible.

So, we examined the technical lead role in detail. We gathered feedback, explored the many pressures that are exerted and looked for patterns when difficulties emerged. We found that there was not one root cause to the issues experienced and no way to ensure the role is always comfortable. Every situation was unique. Issues ranged from specific people problems, unclear product direction, conflict issues and decision-making difficulties. In addition, the capabilities in each team were slightly different; some product teams have dedicated product managers, some have no product manager, some have senior engineers in their team to provide additional technical leadership, some do not. Each technical lead had different strengths and weaknesses too; some were well practiced agile enthusiasts and some were quite new to this area, some were keen to lead phone calls with our users and some had very low confidence when it came to interacting with customers.

This exploration highlighted a lack of training and support in certain areas that we needed to solve in the medium-term for the whole cohort of tech leads. More immediately we felt the right approach was to work with technical leads on a personal, individual basis to give them as much support as possible. To explore how they experienced the pressures of their unique set of circumstances, deciding where they find the role most taxing and where they need more help.

To help perform this exploration, I stumbled upon a metaphor that I think helps people examine the pressure of their role openly, allows them to be vulnerable and naturally point to areas where action can reduce the pressure they are feeling.

The Taps

The Taps Model: A tool to explore cognitive overload

The technical lead role has four distinct and broad duties that, unless we are careful, could end up resting entirely on the shoulders of the individual team leader:

• Team leadership — maintaining a healthy team dynamic, setting team processes and agreements, making direction and focus clear.
• People management — providing high quality line management, support and development for engineers. Handling people issues and caring for their people.
• Technical expertise — guiding the team’s product development, programming and architectural approach and practices. Performing expert perspective. Setting a great example through contributions to the team’s development effort.
• Product/User advocacy — helping set the direction for product development, managing what the team delivers, supporting users and performing research.

It’s useful to think of these responsibilities as taps over a bath that can be opened or closed, increasing or decreasing the flow. Opening a tap results in more cognitive load — responsibilities, tasks or self-perceived pressure — to surge down into the bath. Technical Leads have four distinct taps, Team, People, Technical and Product, any of which can be opened independently. Although the opening of one tap may only lead to a slightly increased flow with that duty, it needs to be considered in concert with the other three taps to understand the deluge as a whole. Too much flow, and the bath will spill over.

Like anyone, each technical lead has a finite capacity; a limited headspace, where increased cognitive load can eventually lead to them becoming full to the point of overflow. In the extreme, this overflow can be experienced as a complete loss of control, a collapse of confidence or crippling stress. We must do everything we can to avoid this.

Closing or partly closing a tap reduces the flow of work or burdens. This can be done in a number of ways and here are some examples:

• by reducing the number of tasks the technical lead commits to (e.g. cancel a bug triage meeting, postpone a workshop, drop out of an interview)
• by reducing the scope of a responsibility (e.g. hand over product owner responsibility to a designer, add constraints to an objective)
• by delegating a task to a team member or a superior (e.g. appoint a technical lead for a story, get a development lead to run the retro)
• by introducing a new supporting role (e.g. quality coach comes to work with a team, a product manager moves to spend more time with the team)
• by just accepting that it's ok if that thing does not get done!

Reducing the flow of one tap may be necessary to cope with the pressure being applied through another. For instance, a people problem that must be tackled immediately requires the technical lead to delegate a planning meeting.

The taps need to be set at a comfortable flow allowing cognitive load to rest at a reasonable level. This leaves people the head space to enjoy the nicer things in life (learning and development time, lunch with the team, foosball!) but also allows them to take advantage of serendipitous opportunities. It also means they are more likely to be able to handle black swan events — unforeseen and unforeseeable problems that pop-up and demand attention. These events can often be a tipping point into debilitating stress if the resting cognitive load on an individual is high.

Applying the model for any role

Although we developed this model for our technical lead role, we can apply it to explore where cognitive load may become too great in the context of any role.

I think this tool is best used during a 1 on 1 coaching discussion, where there should be a high level of safety and the person being coached (let’s call them the Coachee, from now on) should be able to openly discuss how they are feeling and why.

I recommend the following steps when exploring the Coachee’s specific role and the load they experience:

1. Call out the different strands of responsibility the Coachee is aware of. These might be anything, from programming duties to team leadership, budget management to stakeholder support, and so on. You may also choose to include sources of cognitive load from outside their role, either from within the company or at home, as these often have a significant effect.
2. Call out each of those sources of cognitive load as a tap over a bath and draw them on a flipchart or whiteboard. I like to draw the bath as the head of a person to emphasise the meaning of the metaphor.
3. Tap by tap, ask the Coachee to describe the amount of work and pressure they feel is being exerted on them. Ask them to visualize that by drawing the appropriate strength of flow from the tap.
4. Once current levels of flow for each tap have been explored and visualized. Ask the Coachee who, other than themselves, might be involved in controlling the flow from the tap, either by offering help, taking on individual tasks or taking on the responsibility altogether. This might be their line manager, their peers or the people they manage. Add their names to the diagram near the appropriate tap.
5. At this point, review the overall state of the visualisation. Ask questions to discover where the discomfort is and gauge the desire/commitment to change. Which taps are on more strongly than ideal? Which taps must be removed? Which taps would the Coachee like to focus on? Which taps have the right people available to control the flow?
6. Go through the key taps identified in the previous step and brainstorm with the Coachee concrete actions that would result in the tap flow to be reduced, ultimately making the overall load more comfortable.
7. Review the list of ideas and choose the most attractive and tractable. Create a small number of experiments to prove the effectiveness of these ideas.
8. Set-up a review point in a few weeks time, where the Coachee can reassess their taps and evaluate their experiments.

Further ideas

You could also try combining a scaling technique to help the Coachee understand the relative strength of the flow of a tap, where they’d like to get to and a small step they could take to improve.

For personal development, the Coachee may well want to increase the flow from one of the taps. This must be considered in concert with the other taps and is likely to mean that the load from some other responsibility needs to be reduced.

References

Some of you probably think this all sounds rather familiar and/or have spotted that the Taps Model bares more than a passing resemblance to Brabban and Turkington’s Stress Bucket model (see this cool video for a run through of the model). Well spotted! Although I didn’t realise it at the time, I suspect the Taps were inspired subconsciously by the Bucket model, which I came across a number of years ago and was brought back to my attention in a stress & resilience workshop I attended recently.

We’re using the metaphor slightly differently here and, although the Bucket Model could work for our Tech Leads, the Taps break down the pressures coming from someone’s specific job more deliberately. I also like the extended visualization of a person’s head as a vessel straining to retain the flow being poured into it — and that aspect seems to resonate with people.

This post was first published on my personal blog, Leading Agile Teams.