Communicate clearly as a Tech worker
When Satya Nadella, the CEO of Microsoft was asked what he looked for in new hires, he replied: “Do they create clarity, do they create energy.” This article addresses the first part of his answer: Clarity.
Clarity is so precious because it is rare. Clarity is so rare because it is hard to achieve. Clarity involves first the task of having other people understand what you say and write, and this first task can already be challenging in the complex context of tech companies.
In this article I present 2 rules to communicate clearly as a tech worker. These rules are no secrets but knowing them is not enough. I will go into analysing why these rules are hard to follow, and then give some advices to overcome these difficulties. I gathered these rules and advices through my working experience as a Software Engineer, Manager, CTO, and then back to Software Engineer again. These apply to realtime conversation, presentation, emails, etc.
Let’s go.
Rule #1: Deliver your message first, then develop
This means you have a message and you deliver it as soon as possible. The message must be stated with one or two sentences in a plain, direct way, so that the audience has no chance to suspect that you mean something else.
"I recommend to use design option A over option B. Let me tell you why.""I think we can deliver half of the feature set this month. Here's my plan to do that.""I will need help with the configuration of the database. Here's what is blocking me."
Without the message to be stated plainly, there is always room for misunderstanding. You can NOT just give your audience “all the elements” and expect them to come to the same conclusion as you do. By my experience, I consider this the most common scheme for unclear and ambiguous communication.
How soon is “as soon as possible”? If your audience needs some context to see what your message is about, then you can start by giving them the minimum context possible. If your audience already has the necessary context to see what your message is about, you can deliver it straight away. Because you have not yet explained the why and how of your message, your audience has a high chance to disagree with you, but it is at least clear for them what your message is. Based on that clarity, you will start then to develop/explain your message.
Why this rule is hard to follow?
First, this rule is hard because it can happen that you don’t know what your message is. Why? Because the subject is complicated and you have not thought about the message clearly enough. As Barbara Minto put in her much important book The Pyramid Principle , the cause of unclear communication is often unclear thinking.
The second reason why this rule is hard is our urge to express ourselves. Having too many details in mind, we can feel the urge to explain all of them to the interlocutor to give them the “full picture” so that they can understand where we are in our thoughts. In fact, the opposite is true: too many details kill clarity, especially when these details are delivered prior to THE message.
Another important reason why we fail to follow this rule is the fear of conflict. We don’t want to be rude stating out loud our message, especially when it is bad news. We talk and talk, giving the details and hope the message is “guessed” somehow.
“I think we will need 3 more weeks to finish this task, on top of the 10 days that we are late by already” — no one ever wants to say this.How to make this rule easier?
First, you need to identify the nature of your message. Is it an opinion? Is it an update about the current state of progress? Is it to raise awareness about some risk or delay? Is it an ask for help? Once you have identified the nature of your message, the sentence delivering it will come much more easily.
An update: “Since our meeting last month, we have made good progress on the engineering side. I think we are globally on track, but there are still risks to mitigate.”An opinion: “In my opinion we should target the vulnerabilities of our API before the next release of our iOS app.”An ask for help: “I would need a hand from you guys to better design this data layer. I have trouble making it both flexible and strongly typed.”
My second advice is to say “I don’t know” when you don’t know. Sometimes, you are asked questions that you simply can not answered (yet). Instead of babbling around, start by admitting that you don’t know. You can tell your interlocutor to give you more time to investigate and come back later, or you can propose that you two discuss together about the question.
You should also address your fear of conflict, in case you have it. The fear of conflict makes you focus on being nice instead of being clear. In order to communicate clearly, you must be convinced that healthy conflicts are necessary for team work. Patrick Lencioni made an excellent point about this in his book The Five Dysfunctions of a Team.
Rule #2: Communicate at the right level of abstraction
As a tech worker, you might have exposure to different situations where you need to communicate with very different people. A software engineer, for instance, needs to talk to her peers, to the product owners, to the managers, to the CEO, to the interns,…
To communicate at the right level of abstraction means you know what to say to each person that corresponds to their role and needs.
Imagine someone comes to you and asks “How’s it going?”. You should reply completely differently depending on who they are.To a peer Software Engineer: “Oh you come at the perfect moment. I need some help here to center this button.”To your product owner: “I’m struggling to center this button. Can we place it on the right instead?”To your CEO: “I am handling the final adjustment of our new selling page. My team and I will keep you posted about the progress.”
Why this rule is hard to follow?
One source of difficulty is already mentioned: you might be expected to talk to too many different people, especially in cross functional context.
On the other hand, you would be working in multiple levels of abstraction, shifting focus to and fro among them. The diagram below is from the book Lean Software Development: An Agile Toolkit by Mary and Tom Poppendieck. It shows how a designer goes through different levels of abstraction while working. The same pattern would apply to any person working in Tech.
When you discuss with someone, you’ll have to pick an abstraction level and communicate based on it. This is an arduous thing to do, either you do it consciously or unconsciously, .
How to make this rule easier?
It helps a lot if you can keep track of your work through these levels of abstraction, like having a map so that you know where to position yourself. One way to do this is to always know the Goals, the Deliveries and the Uncertainties of your task. I wrote an article about it here. It is written from the point of view of a Software Engineer, but I believe it can apply to different roles in Tech as well.
It also helps if you can try remark and to mimic the vocabulary of your interlocutor. Using someone’s vocabulary will constraint you to address them at their right level of abstraction.
Epilogue
In my first job at Pearltrees, I worked directly with Alain Cohen, the CTO of the firm. Once, knowing that I was struggling, he came to me and asked: “Hi Nhat, have you resolved the issue you mentioned in our meeting this morning?”
I was debugging, so I started explaining to him my process, the variables, my hypotheses, etc. At some point, he interrupted me: “Nhat, I asked you a yes no question. So your answer must start with either Yes, No, or I Don’t Know.”
That was my first lesson in communication as a Tech worker.
I hope this article and little anecdote can help you or someone you know :)
