There are many things that I love about working at Microsoft. We are always building amazing technology. We are always looking to the future to try and figure out what directions and paths we should take. But we are also always looking at ourselves and trying to figure out how we can make ourselves better as individuals, teams and as a company.
On my team we frequently discuss the team culture and try to identify 2 or 3 specific areas to focus on and improve.
Recently, my team has been looking at what we can do to create a team culture where meetings are more inviting. If you have worked in the technical industry for any amount of time, you know that there is often the need to get groups of people together to solve technical problems. You also know that sometimes these meetings can be great experiences – and sometimes they can be awful.
We want meetings on our team to be something that people look forward to.
The first thing that we did was to talk to the team and get their ideas. We received some surprising, but (in hindsight) obvious feedback from the newer members of the team.
Unexplained acronyms and codenames ruin meeting inclusivity.
Role playing the problem
Imagine this scenario for yourself – you are newly hired to a technical team. You have been assigned to a project where there are half a dozen engineers working on it. You go to the first status meeting. Shortly into the meeting one of the team members asks “What is going on with LXJ2?”. They clearly appear concerned that there is a problem. Another developer groans in frustration and says “I cannot make any progress on LXJ2 until we sort out JJH3! And no work is happening on JJH3 until XX47 is completed!” The first developer pauses and says “ah”.
…
As a new team member, you have no idea what is going on here. The obvious thing to do would be to just ask what all these acronyms and codenames mean however:
- You do not want to look like an idiot in public
- You worry about wasting the time of other team members
- Some of these acronyms and codenames clearly have strong emotions associated with them, and you worry about the potential of making people upset if there is an in-depth discussion
So you decide to stay quite. And now you are no longer participating in the meeting, you just happen to be sitting in a room where other people are meeting.
What can we do about this problem?
The easiest thing to do would be to go to the newer team members and tell them “If you hear an acronym or codename you do not understand, let us know and we will explain it!”. In fact, I am sure this has been said many times to new team members. It is also the wrong solution, for two reasons:
- In social settings, any obvious solution is usually wrong. If a solution is obvious and effective, then the problem would not exist (because people would do it). If there is an obvious solution that people are not using – just telling them to do it anyway is unlikely to yield any change.
- When one group of people is being excluded by a second group of people. The problem is with the group that is excluding people, not with the group being excluded.
Instead of doing this, I have been spending time identifying behaviors I can model as an experienced member of the team to address this problem. I have come up with a list of four behaviors to start with:
Expand your acronyms and codenames the first time you say them
Acronyms and codenames are very useful! They help us to communicate more efficiently. And in the world of software development, where the official name of a feature might change multiple times during development, having a durable codename reduces the potential for confusion. However, they are harder to understand.
In written communication there is a simple rule for dealing with this. This rule is that you should always expand an acronym the first time you use it in a block of text. For example:
I love virtual machines (VMs). VMs allow me to play with all different kinds of operating systems.
You can do the same when speaking in a meeting. The first time you mention an acronym or codename, just pause and give a one sentence summary of the meaning, then move along. This will not slow down the meeting, but it will ensure that everyone is included.
Expand other people’s acronyms for them
As a more experienced member on the team, I know most of the acronyms and codenames that we use. If I am in a meeting and someone uses an acronym or codename without explaining it, it is very easy for me to pause and just say “XXJ2? That is the project to develop a hypervisor for the Sega Dreamcast, right?”
This will not slow down the meeting substantially, and as an experienced team member most people will assume that I am just paging information in after thinking about something else. In other words, there is no downside to me for doing this but there is a benefit for any new team members in the meeting.
Be a public idiot
Even as an experienced team member, there are still times when someone will bust out a codename that I do not understand. In this situation, my natural inclination is to bluff. I can pretend that I know what the codename means, get through the meeting, and then find out what it means afterwards.
But this does not make for a better meeting environment. The best thing for me to do is to stop, and loudly say:
“I have no idea what project XXJ2 is!”
As someone who has worked on the team for a long time, I can do this without harm to my reputation. I have enough demonstrated technical competence under my belt that the worst people will think is “Gee, Ben has a lot on his plate if he has not had time to learn about XXJ2”. But doing this in public has multiple benefits:
- Someone will now explain what XXJ2 is, and everyone will know.
- It encourages other team members to feel comfortable calling out their own ignorance publicly
- It lets the people working on XXJ2 know that there are sections of the team who have no idea what they are doing!
Be aware, and follow up privately with new team members after meetings
I can keep an eye out for new team members in meetings, and if they do not appear to be engaging in conversations, it is easy to reach out to them afterwards and say “Hey, we just ran over a lot of topics – is there anything in particular that I can give you more background on?”. A half hour conversation can greatly improve their ability to contribute to future meetings.
Underlying these four ideas, is one thing to avoid. Do not make things worse by calling out new team members in all of this. Do not think it is helpful to use a codename and then ask “Does everyone know what that means?”. Do not expand acronyms, but preface this activity by stating “now, for Jeff, this means”. These actions will make your meetings less inclusive, not more inclusive.
Not just a problem for new-hires
One final note to make – throughout this whole post I have avoided using phrases like “junior” and “senior”. Because this issue has nothing to do with experience or capability. To demonstrate:
I was recently having a one-on-one meeting with a senior member of a partner team. They had many years of experience at Microsoft and had recently started helping my team on a complicated project. In chatting with members of my team – they were all extremely happy with how this person was contributing. I was expecting the one-on-one to be very positive overall.
However, when we started the partner team member was clearly agitated. After a short conversation, they eventually stated: “Ben, I have no idea how your technology works!”
As this sunk in – my heart broke for them. They had been attending weeks of meetings and doing great work. But the whole time they had felt like an imposter, because no one had explained our world to them, and they did not feel comfortable asking for help.
Needless to say – I spent the next hour doing my best to bring them up to speed. But this is evidence that this problem can happen at any level of experience.
These are just some of my early ideas and thoughts here. I would love to hear about any practices you have adopted to make meetings more enjoyable in your work place!
Cheers,
Ben
Very insightful article. Thank you.