High Context: The secret sauce
In recent months, I’ve explored Principles over Processes as a baseline to creating high functioning teams:
- Principles over Processes (2 March 2022) — The basics of the concepts behind this way of thinking.
- Principles over Processes revisited ( 24 Feb 2023) — Where I tried giving some more practical examples
In this newsletter, I want to look at one of the forcing functions that makes Principles over Processes viable as an operating model which is building high context teams.
What do I mean about High Context teams:
This concept is actually inspired by Erin Meyer and the book, The Culture Map. In it, Erin describes how interactions in teams can change depending on Geography, because certain countries, based on their history and evolution have more or less context, which in turn means more or less explanation is needed.
For example, in the US, that has many different ethnicities with very different background, we are talking about a low context society, which means that many concepts need to be explained in detail to make sure all have the same understanding.
In contrast, a country like Japan, which has less diversity and has traditionally been a bit more secluded from external influence may have higher context and so with fewer words they are able to convey meaning or understanding.
These examples are greatly simplified and Erin explains it much better than I, and how it also can vary depending on certain topics or certain areas of social interactions.
We can also see the potential for great confusion for anyone from a low context country visiting a high context country or vice versa.
High context in product teams
When we move into the world of product development, we hear many words like alignment or consistency. Which to an extent is trying to create that high context, but often taking the wrong approach.
Adding another meeting, document, ritual, discussion or tool to try and force that alignment will usually reap minimal results, creating frustration or confusion.
What we want to build is the level of context of the people involved to the right level, but without overloading them.
We need to create a culture of transparency and openness, but only to an extent. Too much of the wrong transparency can also create uncertainty and confusion.
Yes, but how?
I’m going to describe a practical example that I have been part of and seen to be highly successful.
Firstly, you need to define who is the nucleus of people that will be part of each. For example, a product team might be one example, but equally all the product managers might be another group, the product leadership another etc.
Each of those groups needs to build high context for their needs as a group (or multiple groups they are part of).
#1 — Start with scope
In all of the cases, we need to define the following as a group:
- Clear definition of their mission and objectives as a group (ex. To lead the organisation or to evolve a function or to work on their domain space)
- The level of context they are operating in (ex. The leadership group probably doesn’t need to know about every little thing built in every squad at all times. Only in specific circumstances)
- Where that group starts and where it ends (scope of context).
#2 — Empower the people
In order to build really high context, we also need to empower the people at different levels to both control and decide what makes sense to be part of their context, or be spotlighted in other groups or levels.
A great example are product leaders. In their group, they have high context at a strategic level and they have to be empowered to relay the right things down to their teams.
Equally they have to know what to absorb from the teams without being overloaded and identifying what needs to be scaled up to the rest of the leadership group.
#3 — Create the right amount of interactions
This is the hard one, but if you get the next part right, you’ll find that you don’t need as many interactions as you think you need. But you do need some.
As a baseline to start things off, I suggest having at least 1 check-in a week (30–60 min) and then get together as a group hash out more complex issues at least once a month, but not leave it more than a quarter.
Weekly = For a sense check about things and to spotlight any issues needing attention
Monthly to Quarterly = To really deep dive on topics that need to be solved or improved
Depending on the level that your group is functioning at, you may find you need to have many more interactions to get work done. That’s okay, but the interactions I’m suggesting are beyond day-to-day interactions.
One of the things we forget when being bogged down in the day-to-day is about ways of working and how we could approach problems differently. These interactions are great for that.
#4 — Open conversations
This one for me is the clincher and that I suggest above all the rest.
Whether you use Slack or some other form of async communication, share openly about things. Get people used to threads and discussing topics and going into various directions if need be.
Create a document where you throw your thoughts and ask others for their input.
The advantage of doing this is that subconsciously we are sharing context with others so that they are aware of the same things we are aware of and opening those discussions expands on your thinking.
It also makes for asynchronous work that can be done at the best time for each, instead of trying to have all in a meeting at the same time.
#5 — Know about everything, but don’t know everything
This is an important one.
Building context isn’t about knowing every little detail about every subject across the board. It’s more about knowing that it exists and potentially having a light notion of what it is and who owns it.
It’s about knowing that someone is working on something but if we ever need details, we can reach out to them. They are the “expert” and that’s okay.
And yes, sometimes we may need to ask a question about a topic that has been shared previously, but that will happen less often and be less confusing than if you try to know everything.
Closing thoughts
It’s funny, but the actual AHA! moment for me only happened a couple of months ago, but looking back, I can describe every situation where this happened and was successful.
I just hope I’ve been able to explain it well enough for others to try out. Please do reach out if something needs clarification.
Equally, we also need to create the right conditions where this will work and the group involved is as important as the mechanics we setup and I’m seeing that more and more.
Marty Cagan was right when he said that Product Leaders have a huge responsibility and they are the drivers behind the success or not of many operational improvements, but more on that in the next newsletter (Yes, it’s already in the works), but equally, others in the team can help build that culture.
Please share your own thoughts!
P.S. Right now, there is something I remembered when re-reading this edition and it slipped my mind again… Will try and remember, because I feel it was important.
This Newsletter is a passion project and I will always keep the content free for my readers. If you find it useful and would like to support the content, please donate with any amount Donate
Originally published at https://hugofroes.substack.com.
