Effective communication and surprise
A ~15 minute talk intended for software engineers, delivered at an internal engineering summit at $current, September 2023.
Hi folks, my name is Cian Synnott. I’m senior staff engineer with Runtime Infrastructure - that’s our production compute, networking, identity & access management, and deployments systems. These days I’m focusing mainly on issues around cloud resource management.
The title of this talk is “Effective communication”. I’ll make a few general points, and then focus on the idea of surprise in communication.
I’ll talk about ways to reduce the frequency and impact of surprise, and how to react productively to it. Finally I’ll talk a little about the practice of empathy for our colleagues.
We’ll have time at the end for a discussion. I’m curious to hear whether the ideas I present resonate with you.
Communication at work is an enormous topic. I’ll touch on a couple of general points and then I’m going to focus on one interesting facet: surprise.
First up, what’s “effective” communication? Not just “impactful” - it’s easy to have a big impact with communication, positive or negative. “Effective” implies a goal: communication that has the desired effect.
There’s a goal behind most communication at work: convince someone of something; share context so they understand something that we know; learn ourselves, or teach; make sure we have the same understanding of a problem, or shared priorities.
If you’re trying to communicate something, particularly to a larger audience, and you can’t express what your goal is in doing so, maybe get back to the drawing board.
Second, the myth of the lone genius programmer is persistent in our industry, but the truth is that getting large things accomplished means working as part of a team - where you are communicating constantly.
As such, communication skills are first order skills for software engineers. We tend to valorize pure technical capability, but communication skills are easily as important.
Third, everything we communicate is to some audience of fellow humans: another engineer, our manager, our team, partners, customers, our organization. Not one person in this world sees things exactly the way I do or you do. We each have our own background, context, worries, preoccupations.
So we’re crossing a chasm when we communicate: trying to get our meaning, our understanding, our intention across to the people on the other side. To be effective - to achieve our goals - we have to try to understand where our audience is at and meet them there.
Let’s talk about surprise. Our team, our work group, our company is a community or a social system. And that combines with our technical systems to make our system of work - you hear people talk about “socio-technical” systems.
What do we call a big surprise in our technical systems? An incident! An incident requires response - often by many people - incident management, cleanup. It can be very chaotic. Usually an incident turns out to contain a series of surprises; some of those are in our social system. A good incident review will address these directly.
Our technical systems aside, communication is full of surprises. We can experience these surprises as positive or negative. Many are inconsequential. But big, negative surprises - just like a technical incident - can create a lot of chaos and upset.
As a few examples: unexpected negative feedback; realizing that you and a colleague have a totally different conception of a problem you’ve worked together on for weeks; finding out your company or your customers don’t value something your team has sunk a lot of time into.
Surprise in communication is the enemy of effective communication. It gets in the way of our goals, creates churn that we have to manage, and potentially derails whole efforts. So broadly speaking “don’t surprise people!”
Much easier said than done. Just like in our technical systems, surprise in our system of communication is inevitable. But what we can do is:
- limit how often we surprise people;
- limit the impact when we do; and
- react productively to surprise - ours or others.
How do we surprise people less often and less extremely? There’s a framing from Elizabeth Ayer that I love and use: “radiating intent”. Her analogy is a turn signal on the road: if you indicate what you intend to do, you won’t surprise the people around you when you proceed.
So say you want to make a technical change. You say “I intend to do X”. Repeat that in a few contexts: for example 1:1s, team meetings, customer meetings, an RFC for something bigger. You can get a few different reactions.
- Radio silence? Sounds like assent to me, go ahead and do it. You might still surprise someone, but you created a lot of opportunity for feedback.
- More commonly, you’ll get some feedback: maybe your team says “yeah that’s great, please do it”; maybe your manager says “Y is equally important and more urgent, could you take a look at that instead?” Maybe a colleague tells you that X is a terrible idea, we tried it three years ago, it’ll never work. That’s a good start to a conversation; you’ll learn something.
Note how different this is from “asking forgiveness rather than permission”. We’re still not asking permission: just stating our intent. But by doing that up front we create the opportunity for feedback. And we turn a potentially big surprise - “I went ahead and did this” - into a small one - “I intend to do this”.
Similarly, we can limit surprise by sharing the context we have with others. A big source of surprise in communication is unspoken assumptions, background we don’t share, missing information, differing incentives.
So we can “radiate context” as well as “radiating intent”: actively and readily sharing what we know as well as making connections between efforts and people.
For example, a little FYI or heads-up can go a long way - “in case you missed it, X is working on something similar from another direction, did you see their doc?”.
Or realizing in a meeting with a partner team that they’re unaware of the broader reasons behind how you’re prioritizing, and sharing those directly.
A great note from Denise Yu on what makes a strong senior engineer: “in every conversation you’re part of, create clarity and reduce chaos.”
Reducing frequency and impact aside, surprise is inevitable. So what about when you’ve surprised someone, or you’re surprised? Emotions are immediately heightened. Depending on the situation, you may experience a physical reaction: an adrenaline spike, heart racing, face flushing. And I don’t know about you, but these are things I do not enjoy at work.
But: just like in technical incidents, every surprise is an opportunity to learn. And we learn most when we don’t jump straight to blame and judgement. I won’t call those a natural reaction - who knows - but they’re certainly a common default.
Instead, we can take a breath, feel what we feel, and then set that aside and get very curious. What happened here? What does this person know that I don’t? Have I misunderstood something? What’s important to them in this situation?
A friend of mine calls this “leading with curiosity”, which I love because of the double meaning: both the sense of starting and of leadership. I often think of it as a means of “lowering the temperature”, calling back to Denise Yu’s note on clarity and chaos.
I find people react well to curiosity. I mean, genuine curiosity - not necessarily 20 questions. But “Huh, what happened here?” and a real attempt to understand their perspective.
Each of these ideas - radiating your intent and context; leading with curiosity - is a practical exercise of empathy: we’re trying to meet our colleagues where they’re at when we communicate.
That is frequently not where we’d like them to be: every person brings their own stuff with them to every conversation. So communicating effectively - meeting our goals - is always going to require navigating and dealing with surprise.
The good news is that these are skills! We can practice and get better at them. Just like blameless incident retrospectives are a trained response in an organization, we can train our personal response to surprise.
Sometimes, maybe particularly in our industry, we speak in a very “fixed” way about so-called soft skills: Cian “is” an empathetic engineer, like I was born that way. I assure you I was not.
We can learn to share our perspectives more effectively, and to understand other people’s better; to turn our rapid judgements into hypotheses fuelling our curiosity; and ultimately to achieve our goals more often when we communicate.
To summarize:
- Don’t surprise people BUT
- Surprise is inevitable SO
- Radiate your intent and context AND
- Lead with curiosity AND
- Remember these are learnable skills.
Thank you!
We have a few minutes left, so I’m interested to hear any questions you have, or any thoughts this raised. Does this resonate? Have I over-simplified?
A few references: