How to work out: What do you Do?
A follow up to "What do You Do?" a guide for teams and team coaches.
TLDR
If the answer to “What do you do?” is the most powerful test of an organisation's abilities, then working it out must be a vital skill.
As a team member or a coach, the foundation of working this out is to enable the whole team to examine what they do in detail, add metrics to that, and expand their view to the edges of their organisation.
Once they have this, crafting and testing the answer gives them this powerful tool.
However, as a team coach, look out; knowledge is power, and the team will rightly challenge and question things that get in the way of them being effective, which is what we want from an empowered team.
Introduction
This article follows up on “What do you do?” (If you like, this is the How? to the previous article that asked Why?). In that article, we explored the vital insight that the answer to this question gives into the health of an organisation and its people. Put simply, it immediately shows the person and their team's demeanour, pride in, and outcome of what they do. Teams that know this driver have better results.
In this article, we look at the tools available to you as a team member or coach to enable teams to work this out. We’ll also examine how you respond to the team's answers as a coach.
Note that I refer to a coach throughout this. Depending on your organisational structure, you may be a line manager for a team or a line manager for specific team members. In either case, here I want you to act as someone other than the team's boss; I want you to be a coach, helping that team exceed what it thought it was capable of.
The Psychology
We must start with some basic psychology; this is about trusting the team. The team's job is figuring out what they do, how to articulate this, and how to say this confidently. People can coach and support, but ultimately, the team needs to create and own this.
You need to trust your team. As a team member, you must trust that the whole team has a role to play here, and everyone should play a part. As a coach, you need to trust your team to do this.
Suppose your team doesn’t trust one another, or you don’t trust the team you coach. In that case, this will likely fail because there is no psychologically safe space for people to be honest: honest about their lack of knowledge, honest that there may be two views on what something is, honest that there may be things that the team lacks or an appendage that holds them back.
If there isn’t this safe space, pause this process here, and I recommend you check this article A PM’s Role in Promoting Psychological Safety in their Team by my friend and colleague Ekaete Inyang to help you build this. But when you are ready, come back. This is powerful stuff.
If you have the basics in place, please proceed, but note that your team will discover things that challenge their thinking, so be supportive through this and afterwards as they use this to help them achieve more.
Begin with the end in mind.
Beginning with the end in mind might be challenging for agile product people, but bear with me. We aren’t going to pre-judge the answer but remind ourselves of the crucial features that any description of what a team does must have at the end.
It takes time to get to this.
It has to communicate well.
It has to be relevant to the audience
Everyone in the team should know it
Everyone in the team should understand it
So don’t rush this process; take your time to work it out. The team needs to create the artefacts so that they can know it by understanding it. When you do, what you come up with won’t be perfect. It also needs to be tested and evolved.
Working it out
Getting the team together
Mapping what you do is a team activity. Ask yourself how often your department, division or company has decided to change how it describes what it does, and you have found that the result could be more consistent with your experience. Whether right or wrong, that process did not take you on the journey. At the company level, this doesn’t mean that thousands of people take part in every step, but they should help you feel like you are part of this. There is no excuse at a team level, with 5-9 people, for example - you all need and must be involved.
Find a way to get the team together for a couple of hours. I strongly encourage doing this in person, with a facilitator from outside the team. This way, everyone can be involved in determining what the team does. If you have to do this virtually, use Miro or something similar, have everyone with cameras on, organise it so everyone can contribute, and facilitate it so they do contribute.
A facilitator can ask those questions the team has forgotten and tease out the details from “Oh, there’s a few steps in there, but”.
Getting the basics down
Step one is to write down all the details of the team's work today on the page/wall/board. I am a fan of visual representation, but let the team decide what works best. Remember, this map will live on, so an easy-to-digest format is useful and avoids rework.
Some form of process flow diagram for most teams showing what they do and how they do it is a good starting point.
However, different team styles might benefit from other approaches:
A standard product team looking after a single product/service: A flow of how the product operates up and downstream of their ownership area is a good start. However, remember to make note of the process they follow to support this product, too.
A feature team that develops features for a range of products: A view of the products they support is needed. However, the development process is likely longer and more complex because they serve multiple stakeholders and have a more complex engagement process.
A platform team's customers are internal, not external; otherwise, the flow is similar to those above.
A support or sales team's role is to manage tasks to resolution, so they likely operate processes and specific tools that enable this. Map out both.
Here is an example map to illustrate what one might look like.
How much detail
If the map stays the same all year, it is too high-level. If you change the map every time you have a retro, it needs to be higher. Think of a flow/view that works for you and the team, one that you likely update quarterly.
One last tip: ask the team to show the information/mi/data flows that help them understand if their process works. These are often left out and are just as vital.
Two Answers?
A common issue that you will find during this process is the 2-answers problem. There will be parts of your process or product with two different answers to what it does / how it works. Embrace the difference, get the individuals to find the correct answer and help them represent this on the map. This is a decisive moment for a team; it is now more wise than it was, and no one has won or lost. Celebrate it. But be aware of how to prepare the team for these moments.
Zoom Out
Too many teams have a narrow and almost parochial view of the world. This can be by design or, more likely, because they are not in control of how their team supports the organisation's objectives they are supposed to focus on.
To counter this, you need to zoom out right to the customers of your product/service and show them the journey in which you are involved. This might be from creation to consumption or from need to purchase. Broaden out your process flow to include the steps upstream of your team as the essential starting point and downstream to consumption.
We do this to give the team references that the rest of the organisation will understand. These are connections that everyone understands, and then you can centre in from there.
Metrics
So now we have a view of the flow that the team is responsible for and what they use to do this, but we need to add some business/organisational colour to this. Are you a team that responds daily to crises or processes two million search requests an hour?
Some tips for choosing metrics: find something people can understand, like a weekly or monthly average. If the variability is high, say so. Choose a representative month or week to show the data, not your quietest or busiest. You have to feel confident in these numbers; they speak for themselves.
Here are some examples:
The product handles between 600k and 900k customer enquiries in an average week, with peaks at financial year and quarter end hitting 1.5M
We manage and fix 2-3 priority one service issues daily within 30 minutes and 50 priority two issues within 6 hours.
We use these to give people a scale to what you do; the adage know numbers, know business, no numbers, no business is well-worn but true.
Getting to a testable answer
The last piece for the team is to describe better what the team does. Now, the team has a broader picture of where their work fits in the organisation. They have a clear view of this, along with metrics and crucial end-to-end points relating to the rest of the organisation's goals.
Using this, we can test this with examples describing what the team does in the organisation's context.
Testing it out
The next step is to road-test your answer to “What do you do?”. Do this in small, safe spaces, the newly brave team testing the waters outside their team. As a coach, support them by letting other teams know they are doing this and want their help.
After a few of these, come back and iterate; joint problems are:
It’s hard to say: Sometimes, this requires practice, but if it is hard to say, it is likely hard to hear. It's time for some re-work.
It isn’t me: If your team truly created this, it may be you; you haven’t yet gotten comfortable with your new outfit.
People didn’t understand: This is a challenge. Don’t lose hope, but ask them what they didn’t understand. You might need to tweak your answer a little, or maybe you didn’t zoom out to find common ground with a colleague.
Try also saying this out loud, not just writing it down, “We’re the Peter Piper team that picks a peck of pickled peppers periodically”, which is fun but not easy to say confidently. Find words that you can say out loud and write down, too.
All done?
Well, not quite. Well done for getting to this stage as a team or a coach. It is a milestone. But as you start to make use of this new superpower, you will likely uncover one of four issues:
The team has to use another team/service/system to make a difference.
The team has a system/process they “own” that gets in the way of them efficiently managing their work.
The team's high cognitive load makes it difficult to focus on driving results in a specific area.
In time, the team's responsibilities may need to shift.
One or more of these will exist. But now you are getting to the core of the issue in enabling every team in your organisation to drive results. You must support them in taking their performance to the next level.
Summary
A strong, clear, and understandable answer for an individual or a team to the question “What do you do? It is a powerful thing. However, getting to this team development stage is not immediate or fast. But get it right, and the team will boost their self-confidence and relationship with their leader(s). Make sure to do this work as a team in a safe space, and as a leader, support the team with this newfound knowledge to challenge decisions to help them best deliver value and meet the company's needs.