Uninclusive Conversations

I've recently been thinking about how I explain myself when talking to others, both those I do and do not work with. This has come out of some reflections on how we've been onboarding a new Technical Programme Manager and Engineering Manager, as well as two engineers on secondment, a new development engineer, a new quality engineer and intern.

With new engineers on the team, we needed to download a wealth of technical knowledge on the Identity Service - not only how we build + deploy it (which is convoluted due to the design decisions chosen by the commercial off-the-shelf product we're using) which requires some understanding of the identity product, Maven, Vagrant and Chef, but we also needed to share a lot of the technical terminology around the product and how interactions with the service would work. We then had to spend time building up the underlying knowledge of OAuth2 flows, which are quite key to our work, but for many teams is an alien concept they don't need to interact with often.

I realised that while we were downloading these pieces of knowledge to our new team members, we were often using terminology that was technically correct (the best kind of correct!) but that wasn't as well known outside of the three of us who'd been working on Identity over the last few years. This would especially not help when we were in refinement sessions, and the more knowledgable of us would be talking about what did and didn't need to be done on a story, and we'd be getting blank stares from the rest of the room. As a team, we're great at communicating when we're using a common vocabulary, but that falls apart when there are those with us who aren't fully comfortable using that vocabulary, such as the new team members, or people external to the team who don't have the same depth of knowledge.

There is also a fair bit of assumed knowledge in our conversations, which I've noticed when I speak to our senior engineer when he's thinking ahead to all sorts of awesome things, as well as at our daily team standups. We'll be discussing stories amongst ourselves, and our TPM or manager will need to ask for clarification, as even though engineers on the team are aware what is being talked about, it's not high-level enough for those without the technical expertise.

These issues make our conversations inadvertently uninclusive, which isn't the idea, so I'm looking at ways that we can combat this by changing approach to conversations. It's made me more aware about the manner in which I explain myself, taking care to provide a bit more of the context as to why something is relevant, as well as the what.

Fortunately I've found that it's not just our team having this issue - around April we joined the PSD2 / Open Banking compliance Goal Team internally and started interacting with teams who had already been working on the solution for over a year. They too were using terminology that for them and the project was technically correct, but for us as outsiders, we were having difficulty keeping up (which isn't helped by the many confusingly acronyms like AISP, PISP and ASPSP). Although in the previous months the two core engineers had been looking into the regulations and had been involved in some planning meetings around it, it wasn't the nearly the same level of depth of knowledge that can be gleamed by working on it full time.

How I'm Improving

Since realising this is an issue, one of the key questions I've been keeping in mind is:

"What would I want to know if I'd just walked into the room and had no context?"

This has helped me change my approach and I've now adopted the practice of giving more background when speaking to others, especially those outside of the core engineers within our team. I've found this works in two great ways:

• in the case that not everyone already knows what we're talking about, they'll be given the right level of knowledge to follow the rest of the conversation
• in the case that everyone already knows what we're talking about, they're going to have their knowledge refreshed, and everyone will still be on the same level

I've tried to reduce my usage of terms and phrases like "obviously" or "as I'm sure you know". In the best case, someone knows what we mean, but if not, these make it even harder for someone to ask for clarification, as psychologically they'll be thinking "oh, I should already know this, I can't ask now, it'll be really awkward".

I've noticed that when answering a question, I'll answer in the form of the question, as I understand it, and my answer. I've found this helps confirm that I've understood their question correctly, as well as that my answer is directly responding to that understanding, rather than having the chance of misunderstandings.

Finally, I keep in mind that no matter how amazing you are, you will never be a subject matter expert in every conversation so at some point you'll be on the back foot. It's not the most fun experience having to pause a conversation to keep asking for clarifications, so having some empathy for those who are in that situation helps.