For most of my career as an IC, the code did the talking. If the system worked, the message was clear. If the tests passed, the argument was won. Communication meant writing commit messages, maybe the occasional design document, and turning up to stand-up with something coherent to say.

Then I moved into leadership, and I discovered something uncomfortable: the thing I’d spent the least time deliberately practising was suddenly the thing I needed to be best at. Not architecture. Not debugging. Communication.

I think most of us who came up through technical roles carry a quiet assumption that communication should just come naturally. You’re a smart person, you understand the problem, so surely explaining it to others is the easy bit? What I’ve found, over 25-odd years of getting this wrong in various ways, is that communication is a craft. It requires the same deliberate practice we’d give to learning a new language or framework. Calling it a “soft skill” does it a disservice, there’s nothing soft about it.

The Four Layers

One framework that really clicked for me comes from Cate Huston’s thinking on the layers of communication that leaders operate across. She breaks it into four levels: Mission, Strategy, Tactics/Process, and Execution.

Mission is the “why are we here” layer, the purpose of the team or organisation. Strategy is how you plan to achieve that mission. Tactics and process are the mechanisms and workflows you use day-to-day. Execution is the actual work being done.

The insight that changed how I think about this: as a leader, you’re constantly switching between these layers, often within the same conversation. You might start a one-to-one discussing execution (“how’s the migration going?”), shift to tactics (“should we change the rollout process?”), touch on strategy (“does this align with our Q3 goals?”), and occasionally connect it all back to mission (“remind me why we’re doing this”).

The problem is that your audience might only be tuned into one layer. If someone’s deep in execution mode, worried about a failing build, and you start talking about strategic alignment, you’ve lost them. Not because they don’t care, but because you haven’t met them where they are.

This is something I’ve had to learn the hard way. Early on, I’d walk into a room with what I thought was a clear message, only to realise afterwards that half the people heard something completely different. Not because they weren’t listening, because I was broadcasting on the wrong frequency.

What You Say Isn’t What People Hear

Patrick Pena captures this brilliantly: what we say is not what others hear. There’s always a gap between intent and impact, and as leaders, it’s our job to close that gap, not the listener’s.

This was a genuinely humbling realisation for me. I’d spent years assuming that if I was clear in my own head, the message would land. But people bring their own context, their own anxieties, their own interpretation to every conversation. Someone who’s worried about redundancies hears “we’re restructuring the team” very differently from someone who’s excited about a promotion.

A few principles I’ve found useful here:

Impact matters more than intent. If someone misunderstood you, the instinct is to say “that’s not what I meant.” But what you meant is almost irrelevant, what they heard is what you actually communicated. Owning that is uncomfortable but necessary.

Meet people where they are. Before launching into your message, take a moment to consider what’s going on for the other person. What layer are they operating on? What are they worried about? What context are they missing that you have?

Reframe for positivity where honest. This isn’t about sugarcoating, it’s about framing things in terms of what we’re moving towards rather than what we’re moving away from. “We’re investing in platform reliability” lands differently from “we’re fixing the mess we’ve made,” even if both are technically true.

Value silence. This one took me years. The urge to fill every pause, to keep talking until you’re sure the message has landed, is strong. But silence gives people space to process. Some of the most productive conversations I’ve had involved long pauses where I had to physically stop myself from jumping in.

The Dangerous Words

When I started looking into how language choices affect communication, one thing that surprised me was how much damage two small words can do: “just” and “simply.”

Marcus Blankenship calls these “lullaby words”, they lull both the speaker and the listener into underestimating complexity. “We just need to migrate the database.” “It’s simply a matter of updating the API.” Every experienced engineer has felt the quiet dread that follows these words in a planning meeting.

The problem isn’t only that they hide complexity, they hide ambiguity. When you say “just,” you’re implicitly claiming that the path is obvious and the effort is trivial. Anyone who disagrees now has to argue against your framing before they can even raise their concern. It shuts down the very discussion you need to have.

I’ve caught myself doing this more times than I’d like to admit, particularly when communicating upwards. It’s tempting to simplify for executives, to make things sound manageable. But there’s a difference between simplifying and minimising, and “just” almost always crosses that line.

The 7 C’s

If you want a practical checklist for whether your communication is actually working, the 7 C’s framework is hard to beat. Your communication should be:

  • Clear, no ambiguity about what you’re saying or asking
  • Concise, say what needs saying, then stop
  • Concrete, specific examples and details, not abstractions
  • Correct, factually accurate, including the nuances
  • Coherent, logically structured, each point flowing from the last
  • Complete, the recipient has everything they need to act or respond
  • Courteous, respectful of the other person’s time, context, and perspective

I don’t mentally run through this list before every Slack message, but when I’m writing something important, a strategy document, a difficult email, a team announcement, I’ll often review it against these. The ones I most frequently fail on are “concise” and “complete,” which are in constant tension with each other. Getting the balance right is part of the craft.

Writing as a Scaling Mechanism

One of the most powerful shifts I’ve made as a leader is prioritising written communication. Saul Diez-Guerra frames this as choosing public and persistent over private and ephemeral. A conversation in a corridor helps two people. A well-written document in a shared space helps everyone, including people who haven’t joined the team yet.

This becomes critical as teams grow. You simply cannot, and I’m using that word deliberately, have the same conversation individually with fifteen people and expect consistency. Writing forces clarity in a way that speaking doesn’t. When you write something down, the gaps in your thinking become visible. You can’t hand-wave past the bit you haven’t figured out yet.

For distributed teams, this is even more important. Juan Pablo Buriticá’s work on distributed team communication really resonated with me. Being explicit about what’s asynchronous versus synchronous, building a written-first culture, using RFCs and decision documents, these aren’t bureaucratic overhead. They’re how you make communication work when you can’t rely on bumping into someone in the kitchen.

I’ve worked in teams where the culture was heavily synchronous, everything was a meeting or a quick call. And I’ve worked in teams with strong written-first habits. The difference in alignment, in shared understanding, in the ability for people to get context without interrupting someone, is enormous.

Communicating Upwards

Talking to executives is its own discipline. Travis Kimmel’s advice on this has been useful: scale your granularity, push information up proactively, and lead with the ask.

Scaling granularity means adjusting the level of detail to your audience. Your skip-level doesn’t need to know about the specific Kubernetes configuration that caused the outage, they need to know the impact, the resolution, and what you’re doing to prevent recurrence. This sounds obvious, but when you’ve spent three days deep in the weeds of a problem, the instinct is to explain all of it.

“Tell-tell-tell” is about not waiting to be asked. If there’s something your leadership chain needs to know, push it up before they have to come looking for it. Surprises erode trust faster than almost anything else.

And leading with the ask, stating what you need before providing the context, respects their time and gives them a framework for processing what follows. “I need approval to delay the release by a week. Here’s why…” is far more effective than a five-paragraph build-up to a request buried in the final sentence.

Connecting the What to the Why

Jeremy Wight describes connecting “the what” to “the why” as the highest-leverage activity a leader can perform. I think he’s right. Every piece of communication, every stand-up update, every strategy document, every bit of feedback, is an opportunity to reinforce why the work matters.

This doesn’t mean every Slack message needs a philosophical preamble. It means that when you’re asking someone to change direction, or take on a difficult task, or accept a decision they disagree with, you owe them the connection between what you’re asking and why it matters. People can tolerate a lot of ambiguity and discomfort if they understand the purpose behind it.

The Ongoing Practice

I don’t think you ever finish learning to communicate well. I’m certainly still working at it. But the single biggest shift for me was treating it as a craft, something to study, practise, and refine, rather than an innate ability you either have or you don’t.

If you came up through IC roles like I did, you probably spent thousands of hours deliberately practising technical skills. You read books, did tutorials, built side projects, reviewed other people’s code. Communication deserves the same investment. Read about it. Pay attention to what works and what doesn’t. Ask for feedback on how your messages land, not just whether people received them.

The code might have done the talking once. But the higher you go, the more the talking is the work.