debugging your team

A good leadership team thinks of their role as managers of a system, rather than individuals.

It can be easy to spot dysfunction in a team, and it can be equally easy to identify quick wins to recover and get the team back on to a healthier track.

However by only focussing on the individuals and trying to change behaviours through feedback/coaching there is a potential you’re not really solving the actual issue. People’s behaviour is influenced and constrained by the system that surrounds them.

For example a bug-ridden feature from a team could be a sign of lazy or under-skilled developers, or it could be a sign of unreasonable pressure, or a lack of clear direction and vision or a hundred other things. focussing only on the skills of the individuals in the team will not get you the outcome you desire.

What follows is a process that I have used here at carwow to help us debug our product leadership team. Have a read; if you find it useful give it a go and let me know how it works out for you :)

Step 0: defining your objective

We ran the whole process over a 1/2 day offsite. In order to do that, it’s essential to first define an objective so everyone is aware of what we’re trying to achieve. In the case of this specific example I was running this for our product leadership team, and so our objective was:

“To build a Product leadership team with: an aligned long-term vision and a set of shared principles and processes to achieve it. With Product Management, Engineering, Design & Data Science balanced and working in harmony.”

Define your own objective by talking to your team, and consolidating what you gather.

Step 1: building your foundation

Ask every attendee to come prepared with a short 5 minute summary of their thoughts and the outcomes they hoped to achieve from the day. In our case this meant product development at carwow.

In advance of this, request everyone to speak to and collect feedback from as many people as they can from people involved on the system you’re trying to debug.

Spend the first hour with everyone sharing their thoughts as a way to establish a foundation for the day, to ensure everyone understands each other’s perspectives.

Step 2 — Alignment

0. aim

Follow this with a session designed to uncover:

i) what you know/hear is going on and ii) how you feel about this.

The idea is to develop a shared reality; to give you all a chance to understand exactly what the reality looks like. For us, this meant digging into the challenges faced by our 8 product teams.

1. fact (what do we know?)

Do this by asking everyone to note down observations onto coloured post-its:

• on Green stickies — what do you know? — i.e. facts
• on Orange stickies — what have you heard? i.e. anecdotes

Ensure everyone has the agenda/plan well in advance of the off-site so they can come prepared with this information already. Prime your team to be candid as possible about the reality to allow you to get as honest an appraisal as you can.

The idea is to collect a snapshot of both objective (e.g. statistics about delivery processes, business impact etc) and subjective data (team sentiment, stress levels, anecdotes etc).

2. emotion (how do we feel about it?)

Once you had laid out bare what your current reality is, the next step is to figure out how you feel about it.

In silence ask the team to assign 1 of 4 emotions to each observation — Happy :-) , Neutral :-|, Sad :-(, Angry :-#

Keep any stickies that have mixed emotions to one side and discuss until an agreement is reached.

Step 3 - Digging deep

It’s a fair to assume that most of what is going to come out step 2 are more likely to be symptoms of underlying/deeper issues and not the core issues themselves. To make sure you focus your energy appropriately, go through an exercise to uncover the roots of these issues.

Give the team some space, and allow them free reign to arrange all the observations into groups that they think seem related.

Step 4- Resolution

From here it’s kind of down to the skills of the facilitator as I can’t predict what will come out of the previous step. Pay attention to the patterns that are detected from the root cause analysis, discuss, prioritise and define actions as appropriate.

Step 5- Communication and accountability

Whatever comes out of this, communicate it openly with the rest of the organisation and publicise your actions and commitments.

I published a full write up our sessions on an internal blog at carwow, with every post-it and every note fully visible and explorable and I’d recommend you do the same.

If you’re interested in hearing more about such topics and learning from other engineering leaders, you should totally come along to the completely free Engineering Leadership Unconference that we’ll be hosting later this month. It’s an open space we’re creating for engineering leaders to gather and share ideas and learn from each other, and everyone’s welcome :) https://www.meetup.com/Engineering-leadership-Unconference/events/255161123/