Straight talk.
Service design & team taxonomy.
I love languages. Learning languages, understanding nuances, getting under the skin of other cultures, unpacking structures of meaning and mental models. I dabbled in a few lingos, starting with my mother tongue Swedish, working in English for 30 years, and various attempts at French, German, Russian, Italian, Japanese and Mandarin Chinese.
My personal benchmark if you can claim to really know another language is not just speaking and reading, or even working day-to-day - can you crack a joke on the go that a native speaker finds funny…?
On the practical service design activist front, I tend to emphasise how important language is when getting on with stuff collectively. So the team can actually understand each other, by meaning the same thing when using the same words.
Sounds so simple. We don’t always speak the same language though, do we…
You may know that the answer to everything is 42. The people asking for meaning just didn’t quite get the question right, and you need to truly understand and fall in love with your problem first before you can solve it.
More interestingly, and above all usefully, the little funny yellow fellow above is introduced in the that same book, The Hitchhiker’s Guide to the Galaxy. Talk nicely to me and I may even lend you the CDs with the recording of the original radio series from 1978…
The babel fish. For those of you with more of an engineering inclination, there is also the schematic…
How is this useful (one of my core guiding principles for everything I do)?
Well, the babel fish was inserted into your ear and immediately allowed you to understand any spoken language from any inter galactical species, handy when you’re travelling through space as the main character in the book finds himself doing.
But back to planet Earth, and more immediate journeys.
Here’s the situation. You’re starting a project and the new team gets together for the first time. It’s kick-off time. Chances are you’re agile (or in quite a few large organisations at least pretending to be), and you have gathered a diverse group of people from across the business from several departments with multiple skillsets, eager to get cracking solving that Big Problem or delivering that Important Transformational Change.
So you all come from various backgrounds (good thing), likely with varied mental models and preconceptions of why, what, how, whereto, and so on. This is likely good to provide more than one point of view and generate creative tension (all positive) but it also poses some challenges. And you just want to get on with it. Cause people like your sponsors are waiting for results.
To get (and keep) going you’ll need to talk, and figure things out together. Also known as communicate. Communication is tricky, cross culturally and within cultures (national or corporate), between departments and teams with disparate pre-conceived notions of the world and how to manage it, between individuals with mixed backgrounds and knowledge. If you add to this things like misalignment on where across the Cynefin framework you believe you are operating, which I touched on in an earlier post, it’s a miracle we can get along well and clearly enough to get anything coherent done at all.
My point to the team at this stage is; if you don’t speak the same language, how are you ever going to even understand the right problem you are trying to solve…? Cause solving the wrong problem really quickly and efficiently isn’t really such a great idea.
To start with, we need a common language, a shared frame of reference and an at least internally and informally agreed taxonomy, a definition of meaning.
This is as much about the connections between the different words, ideas and concepts; what do they mean together and in relation to each other. In systems thinking terms, thinking-system-performance, how are we thinking about the system for which we’re about to attempt to transform the performance.
So on day one of the new team gathering, preferably right after team introductions, I like to run a little session I have called ‘the Babel Fish exercise’.
It’s a good warm-up and serves a dual purpose.
Firstly getting people a little bit stretched and out of their immediate comfort zone as well as smiling. Apart from this one product owner I had who really didn’t see the point, the data engineers on the other hand loved it.
Secondly to start to establish that shared taxonomy for the collective problem definition as well as the collaborative problem solving that we’re about to embark on.
As introduction I go through a variant of the ‘love and importance of language’ above. Then I suggest we see how well versed the room is linguistically (occasionally insert joke about cunning linguists from audience…).
First quick exercise; I will mention a few languages, if you speak it really well hold up two hands, if you have some knowledge one hand, and if no clue then keep both hands down.
‘English…?’ Two hands all around the table.
‘Swedish…?’ Usually just two hands from me (or the occasional one hand from the guy with the Swedish ex-girlfriend).
‘French? Spanish?’ Scattered hands, and tales of summer holidays in foreign countries.
‘Hebrew…?’ Two hands from my service design mate Ilan when he is in the room.
‘Anyone have a language they’d like to try on the room?’ This one can get quite serendipitously interesting…
Then I ask, since I work in the Risk Design team and we’re likely there to start a new Risk related project;
‘How many speak Risk…?’
Slight confusion in the room.
I put up one hand. I dabble in speaking Risk, after more than two years doing change, service & business design, and story telling across Risk. But I’m still far from fluent. And there is definitely a risk insider language.
A few colleagues from Risk would put up their hands, a couple from the broader change team put up one hand.
‘And how many speak ‘data’? Or ‘technical architecture’…?’
‘Do we think this potential misalignment is important? Why would it matter? What could we do about it?’
As the second mini exercise we then discuss a bunch of 15–20 post-its that I’ve prepared (I mean what is a service design session without post-its after all), each with a core concept or keyword from each domain of knowledge represented on the team. They are as basic (or complex) as ‘risk’ and ‘control’, or ‘data’ and ‘environment’.
The discussion is facilitated and the emerging definitions of the key concepts as well as the connections between are captured on more post-its. Importantly, anyone can and should suggest additional ideas they feel are needed to complete the knowledge web from their point of view, and take us through why.
First time I ran this I figured we’d spend about 20 minutes chatting about it all. Two hours later we were still exchanging ideas, sharing knowledge, and generating insights and opportunities to link up the different domains. And people were starting to step into each others mind space.
We did produce a draft documented taxonomy, which we later referred back to e.g. when onboarding new team members, but as with many of these exercises the most important outcome wasn’t a piece of documentation.
The most valuable take-away was the alignment of the team’s thought processes and an emerging shared sense making of the problem area, and a foundation for the subsequent shaping of solutions. A living team taxonomy.
I really can’t over emphasise how useful that is. Think about the ROI of 1–2 hours invested in this way.
I suspect there are plenty of similar topics or wicked problems where you need to help teams get into a shared state of mind, something like climate say, and hopefully something like this might prove useful to get you going.
Godspeed, and may the babel fish be with you.
