Things I keep in mind when communicating at work
I’ve been grateful to receive lots of positive feedback about my communication skills at work and I’ve been thinking a lot more recently about how to share any insights I have about that, particularly with other software engineers who might be looking to improve their skills in order to start having a more “senior” level of impact.
With that in mind, here’s a bunch of ideas I use when communicating at work (some of which might be more specific to software engineering). I’ve written this quickly without editing it too much and it’s all of course based on my own working life — I’d be interested in hearing both from people who find this useful and people who disagree or have had different experiences!
Aim to be fully & clearly understood
If someone misunderstands you, assume it means you didn’t do a good enough job of explaining (rather than it being their fault for not understanding properly). The goalposts might be different for every person but it’s your job to figure that out and adapt your communication to suit. Try to use a misunderstanding as a learning opportunity rather than taking it personally — unless it is personal and someone is being intentionally difficult (but most people aren’t).
Know (what) your audience (wants)
“Know your audience” advice often only refers to understanding what knowledge your audience already has. Knowing your audience to me means not only knowing your audience’s existing knowledge but also knowing what they want. Tailor your communication based on what outcomes the other party is looking for (a quick solution? Some considered feedback? What kind of feedback?). If you don’t know what they’re looking for your first job is to communicate in order to find that out.
Communication can have both social & practical components
A mix of both when appropriate makes for a great combination of something that’s useful but also makes people feel good. Different types of communication at work may skew more in either direction. An example of a combination of the two is something like “Great shout & thanks for raising this (social) — I think for the time being we can probably leave this as is and address in the next sprint (practical)”. Emojis & exclamation marks help with adding personality but use them sparingly. Taking efficient communication seriously doesn’t mean being serious all the time.
Effective communication is a side-effect of thinking about things in the right way
You should be thinking about the ideal end state of each situation you’re in (whether it’s a meeting, a conversation, a project that needs scoping or otherwise) and what you can do to get there. Communication is one of your main tools to help drive situations in the correct direction. If you don’t have a good grasp on what direction you should be heading in then ask more questions until you do.
If in doubt, over-communicate
I’ve already mentioned it twice above but if you’re not sure about something, let people know & ask as many questions as necessary until you’re confident that you understand what’s being asked of you — especially in a new context (like a new team, codebase or role). The more you do this initially the less you’ll have to do it over time (and eventually you’ll be sharing this acquired knowledge with someone else who is in the over-communication phase).
It’s OK if the road is a bit bumpy if it’s going in the right direction
Don’t get too uptight about having perfectly efficient communication. A meeting can be derailed by the occasional comment or tangent, but keep an eye on it. You might sometimes have to keep going back to someone to ask clarifying questions. Sometimes communication is a bit messy (because humans are).
Make sure people understand what you want
On the flip side of knowing what your audience wants, you should aim to avoid any misinterpretation by other people about what outcome you’re trying to achieve with your communication. For example if you’re reviewing someone’s code, it should be totally clear to the recipient whether you’re asking about something because you’re interested in it, or because you think it needs to change before you’ll approve their code. In spoken communication I’ve noticed that I sometimes need to try asking a question once before I fully understand what information I’m actually looking for (and then I try reframing my question so that it’s as clear as possible & I can get exactly what I need).
Aim for concise & well structured content that’s easy to read & act on
If you need a particular outcome from someone (e.g. feedback on a particular part of a project) tailor your communication to ensure they have to do as little as possible to fulfil this. I often write longer messages or updates outside of Slack or email & rewrite them several times to ensure they’re as simple & clear as possible. Sometimes this also involves taking the ‘heat’ out if it’s something I feel strongly about (there always ends up being a lot less “really” and “very” after revisions).
Sequence matters
Put the stuff first that you really want people to read and sequence things so that people can bail out at the right time (the right time being after they’ve received some value but before things get too detailed for them). For example: an overview of a project followed by a detailed breakdown of approaches; your preferred solution followed by others that you’re considering; a quick one-line summary at the start of a status update followed by a bit more detail for anyone interested.
Take your time
Take a moment before responding to someone when talking in person or in Slack (especially to consider some of the things I’ve mentioned above as part of tailoring your response). If your app isn’t suffering from a major production incident then you likely don’t need to urgently respond and taking the extra time will result in a more thoughtful and likely more useful response. The aim is to be helpful, not to translate your thoughts into words as quickly as possible.