It’s funny, I expected geeks-turned-managers to be better at communicating changes to their teams. After all, they often have years of experience thinking about meticulous database migrations, feature rollout plans, and just thinking about how things will play out. Frequently enough, though, we don’t seem to apply these skills to how we talk to our teams. I routinely see poor execution with poor results, ranging from misunderstandings that needlessly waste time and cause worry or anger, all the way to people quitting and projects getting stopped in their tracks. We don’t want that, do we?
You likely have heard the term “communication plan” used to describe the efforts done ahead of time to decide how to break certain news. First, if you don’t actively do these, it’s time to start. But even for those who do invest some time into these, it’s easy to miss some pitfalls. Here are some common mistakes I see that you should be aware of before you announce another change.
Assuming People Understand Words
Funnily enough, we aren’t really good at understanding words. The complete opposite of compilers and code, words can have multiple meanings. Add to that people’s tendency to get stuck in their own head thinking about stuff while listening. And even more problematic is managers’ need to avoid sounding harsh, which drives them to wrap every sentence with so much fluff that it’s hard even to understand what they had in mind.
Have you ever had two people come out of a meeting with two completely different viewpoints of what took place? That’s what I’m talking about, and when we’re sharing information with a large number of people, you’re likely to have more than just two versions. That’s why your communication plan should include explicit and plain language, along with clarifying examples and scenarios ready to help people understand better.
It also makes sense to prepare to repeat the message multiple times in some cases. You might want to repeat the same concept in various ways in the same meetings or be ready to talk about it later in a different forum. I know we cherish “don’t repeat yourself,” but unfortunately, people aren’t as easy as computers.
Some companies are diligent about creating accompanying documents that explain things again and in more detail. These are useful to help people verify whether they understood things correctly and decrease miscommunication. In today’s hybrid office, it is also useful in case not everyone is able to attend the meetings synchronously.
Not Providing Time & Space
When you finish delivering the news and get no questions, what do you think of it? Some people just assume they did a great job explaining everything. Experience tells us this usually means that people lack time or space to process the news. It makes sense that people might not immediately grasp all of the different implications of a big change on them, even if it seems trivial to you. As I explain in The Tech Executive Operating System, we tend to treat things as straightforward by the time we announce them where it is often done after we’ve had days or weeks to mull over the matter. Expecting others to grok everything during those fifteen minutes that you’re talking about it is prone to let downs.
Bake in time to let people think about things and be available to talk to them later. I often recommend to my clients that they block out time after the announcement (and sometimes the following day as well) where they are free to have people come over and talk to them. It’s a good idea to let people know of this availability. If you don’t see it used, it’s a good opportunity to use management-by-walking-around and see if there’s any interesting chatter about it.
Further, some people also need private space to ask some questions. If you feel it necessary, schedule short one-on-ones right after the announcement.
Counting On Discreetness
People talk; it’s as simple as that. Whenever you allow your communication plan to span over too much time, you vastly increase the chances of people hearing things inadvertently. I’ve seen rumor mills get out of hand and essentially cripple entire organizations for days. Ripping it off quickly, like a bandage, is often the better choice.
Forgetting Your Risk Management
As with every change, you have to take into account the different risks at play and manage them. In your risk assessment, map out those individuals that are more likely to have issues with the new state of things and decide on your steps. Preventive measures might include bringing them in the loop before the big announcement so they won’t be as surprised or allowing them to provide feedback before things are finalized.
Your contingencies should take into account different outcomes. Can you handle a key person leaving? Don’t wait for these things to play out, be prepared. I’ve recently covered risk management here.
I hope this will help you avoid a pitfall or two!
Get a sample chapter
Get the best newsletter for tech executives online, along with a free sample chapter of The Tech Executive Operating System 📖. Tailored for your daily work. Weekly, short, and packed with exclusive insights.