The communication skills every technical expert needs

You may have heard that to excel as a senior technical expert, technical skills aren’t enough. People skills are an important part of the picture.

But let’s get real for a moment. While communication matters, it isn’t your core focus. Even the most senior engineer is still performing a technical role. You’re neither a diplomat nor a psychologist, even if those competencies might be useful once in a while.

So which communication skills truly matter for technical experts? Which are non-negotiable for career success?

It comes down to four key areas:

1. Understanding business pain points—and linking them to technical decisions.
2. Sharing your unvarnished reckons on the spot.
3. Explaining technical concepts to non-experts.
4. Leadership skills, including managing a technical team and giving effective feedback.

If you master these techniques you’ll be able to share your knowledge with anyone. And you’ll gain the flexibility to take on senior roles, from Team Lead to Chief Technical Officer.

So what exactly are these techniques, and how can you include them in your daily work? Let’s take each one in turn.

1. Understanding business pain points

Tech experts and business stakeholders have a different set of knowledge and experience. In theory this shouldn’t cause a problem: specialisation is beneficial and the reason we have experts in the first place. But in most organisations, the relationship between these two groups can be delicate, because:

• your field’s best practices don’t map cleanly onto business goals
• managers may know little about your field (but can’t admit it because they make the decisions)

To avoid both embarrassment and catastrophe, it becomes your job to understand business pain points—so you can use them to justify technical decisions. That way, managers are happy to follow your advice because it aligns with their goals. And instead of drawing attention to their lack of technical knowledge, you make them feel smarter by explaining the piece they need to understand.

Take an example from the world of software engineering: security. Imagine you’re a Team Lead making a case to management to spend time and budget on redesigning a system. To your peers the motive is obvious: the system needs to follow best practices for security. But that reasoning is too abstract for managers, who may assume that you’re naïve about business realities. To them you sound like a perfectionist, fiddling with a functioning system while neglecting other priorities. If it ain’t broke, don’t fix it.

Your task is to convince them that it is, in fact, broke—on their terms. Here’s a shortcut. Ask yourself what keeps them up at night, then show how your advice will alleviate that pain.

The good news: business goals are usually easy to understand. To simplify only slightly, businesses care about:

• increasing profits
• reducing costs
• managing risks (including reputation)

At first glance, your proposal scores negatively, because it increases costs while avoiding work that might turn a profit. But what keeps leadership up at night? How about a ransomware attack that might cost millions to resolve? Or an investigation by a regulator that could tarnish the company’s reputation?

Use evidence and simple arguments to show that:

• the existing system exposes the business to substantial risks
• the changes you propose will mitigate these risks as efficiently as possible

They’ll see your proposal in a completely different light. You’re no longer the nerd insisting on a perfect architecture. You’re a trusted adviser saving them from legal liability or financial disaster.

The importance of listening

Don’t make the mistake of thinking that you can do all of this from your desk. You probably won’t figure out how managers see business goals without talking to them.

The most effective technical leaders are skilled listeners. They know how to get inside the heads of non-technical people. But they aren’t mind readers. They use techniques like active listening, the Swiss Army Knife of communication. If you’re not familiar, here’s the precis:

1. Ask an open question (like how / what / why / where / when).
2. Listen without interrupting.¹
3. Reflect back what you heard, in your own words. Then ask if you got it right. “It sounds like you … because … . Did I get that right?”
4. Return to step 2.

The more you practise this skill, the easier you’ll find it to link technical decisions to organisational goals.

2. Sharing unvarnished reckons on the spot

When you picture a senior technical expert, what do you see? You might imagine a commanding figure, demonstrating their mastery through carefully researched papers and slick presentations. The audience looks on, captivated by the depth of your knowledge…<RECORD SCRATCH>

Sounds too good to be true, right?

While senior experts have opportunities to share their wisdom in formal settings, that’s only part of the job. More often, you’re called on to give an opinion on the spot. With no time to research the question or craft a watertight argument.

This is both difficult to get your head around—why do people want less rigorous answers?—and tricky to pull off.

Why do people want simple answers?

In my work I often see a mismatch between the way my clients and their audiences understand the expert’s role.

Experts want to give a technically correct answer. You want to show that you’ve considered all the options and edge-cases. That you’ve used the right methodology and carefully considered risks. It’s like you’re bracing for the inevitable criticism from someone who knows better. Whether it’s an academic supervisor or the junior colleague who thinks your approach is out of date.

Don’t get me wrong. This is the right approach for a conference talk—you know the first three “questions” will be people telling you you’re wrong—or a meeting with technical peers. But non-expert audiences see your role differently.

To someone who doesn’t share your background knowledge, your field is a frightening wilderness. And you’re their only guide. They wouldn’t think to question your expertise. So when you try to bolster your credibility, they end up confused or concerned. These people want less detailed, high level answers. Answers which may seem trivial to you.

Why do non-technical audiences want your unvarnished reckons? It’s because they:

• implicitly trust your intuition
• work at a high level of abstraction, and don’t care about the details
• prefer to “pick your brain” instead of breaking down a lecture

In short, your raw, imperfect insights are a crucial part of the value you provide.

The challenge of speaking off the cuff

This mismatch also explains why so many technical experts have difficulty speaking off the cuff. You’re asked to speak under pressure, and you make faulty assumptions about what people expect. Add some natural anxiety and you have a recipe for freezing up. It feels like you can’t find your words.

When you find yourself in this situation, consider whether you’re trying to do something impossible. Like constructing a bulletproof argument in 10 seconds flat. Or explaining years of experience to someone with no domain knowledge.

When you’re trying to achieve the impossible, the solution isn’t to try harder. It’s to pause, take a breath, and choose a more realistic goal. Remind yourself that this isn’t a doctoral defence. For this audience, imperfection is a feature, not a bug. The bar is lower than you think. All you need to do is:

1. Check that you understand the question.
2. Remind yourself that they trust your expertise and don’t want detail.
3. Trust your gut, and give a simple, high-level answer.

Then look the audience in the eye. If they need more information, they’ll let you know.

3. Explaining technical concepts to non-experts

When you’re promoted to senior technical expert, it’s no longer enough to know your stuff. Now you’re also expected to:

1. defend an approach in front of fellow experts
2. explain what you know to people who don’t share your background

We’ll talk about your peers later. Let’s discuss the second point. How do you explain technical concepts to non-experts?

It’s harder than it looks, for a couple of reasons. First, because you’ve developed tacit knowledge over many years, it’s impossible to explain all of it to someone who doesn’t share that background. This can fool experts into thinking that their audiences see them as frauds—so-called imposter syndrome—which is barking up the wrong tree. Non-technical colleagues don’t expect you to explain the detail. They want to understand the high-level concepts which are relevant to their goals.

Execs don’t understand tech, but can’t admit it

Second, most technical experts haven’t considered what it’s like to be an executive or a professional from a non-technical discipline. These people have a lot of responsibility—for example, they may make decisions that affect your ability to operate—but their knowledge is high level.

To put it crudely, they’re responsible for making decisions about things they don’t understand. They’d never express it like that, of course. Management theory says it’s fine: as long as the expertise exists somewhere in the org chart, it will bubble up. But the reality is messier.

In 1988, usability guru Don Norman wrote The Design of Everyday Things, which stated that when people have difficulty using a device, they tend to blame themselves, not the designer. A similar thing happens when non-experts don’t understand technical concepts. They silently blame themselves. They imagine that technical topics are simply beyond them, as if they aren’t intelligent enough to understand. But you and I know that’s not true. It’s just that no one has explained it properly.

Put yourself in the shoes of an exec. You talk the talk, but secretly doubt your own ability to understand the tech that underlies the business. What would you want to hear from a senior expert?

Make them feel smart

The most effective technical leaders make their audiences feel smart.

Whether you’re talking to execs, customers or fellow experts, they walk out of the room with a clearer understanding of your field. When they listen to you, they don’t feel helpless or overwhelmed. They realise that it’s not so complicated after all—they can follow when someone explains it well. That means that they associate you with the experience of learning. In other words, they see you as a skilled teacher.

To pull this off, accept that knowing stuff isn’t enough. You need to learn how to teach. Push back against the idea that non-experts can’t understand your field. Of course they can. Because you’ll walk them through the concepts they actually need. And demystify the jargon.

Here’s how to explain technical concepts like a teacher:

1. Assess the knowledge level in the room. Look at your audience. How familiar are they with your field? This helps you pitch your material at the right level.
2. Identify goals or interests. What do they want to achieve? Or, which area do they need to understand to do their jobs well?
3. Find their learning threshold. Identify a concept or idea that your audience doesn’t understand yet. They need to learn this to move closer to their goal.
4. Explain the minimum detail possible to teach that concept. Remember, you need to avoid overwhelm and convince people that they can understand your field. So keep it clear and concise.
5. Check for understanding. To see whether it worked, test out your audience’s understanding. If they get it, great. If not, try again.

A final tip: don’t try to impress. The best teachers don’t dazzle you with their brilliance. They make you the star of the show by demonstrating that you can tackle complex topics.

4. Leadership skills

Senior technical experts need to lead others, whether
as a line-manager, project lead or mentor. There’s some overlap with the leadership skills that every manager needs. But technical teams have some quirks which benefit from specialised approaches.

We’ll cover two areas: managing a technical team and giving effective feedback.

How to manage a technical team

Technical teams attract people who are very focused on a particular area. They can come across as dogmatic about the right way to do things, and overzealous in sharing their opinions. Sometimes this narrow focus makes them unaware of how their work interacts with other parts of the business. But more often, they:

1. are attached to a certain way of thinking;
2. feel anxious when they hear proposals that seem to contradict their principles;
3. need space to explore alternatives that can work for others.

In other words, most techies are less inflexible than they seem.

Defending an approach

I mentioned earlier that as a technical leader, you may have to defend an approach in front of your peers. This can be challenging for a few reasons:

• you may not have chosen the approach (for example, if it was handed down by management)
• others may disagree and propose alternatives
• even though you’re more senior, the dissenters might have more experience in this area

It’s normal to feel nervous about conversations like this. But don’t make it about you! This isn’t a test of your technical knowledge versus others on the team. This is a management conversation, where technical correctness isn’t the only factor.

Start by explaining the approach and sharing all the information you have about the reasons behind the decision. Do your best to explain how this will affect people’s day-to-day work. Then ask for responses or questions.

If colleagues push back, don’t get defensive. Listen to their objections, and reflect back the essence to make sure you understand. Now decide what you can do with their feedback. If the decision’s already been made, state that. If not, invite them to write down their concerns. Or if people need space to get their heads around the new approach, set up a workshop.

Technical experts realise that they don’t call the shots. Their tough talk about different ways of doing things may mask concerns about whether they can adapt to change. Or they may see complications with your plan that you haven’t considered. Focus on hearing them out instead of trying to convince them that you’re right.

Make space for teamwork

One of the most fun aspects of running a technical team is enabling smart people to collaborate. There are few workplace activities as satisfying as watching people play off each others’ talents to create something that no one could achieve alone. But there’s more to making space for teamwork than setting up a Slack channel. It’s an art.

First you need to create a regular, protected time and space. In-person is best, but video calls also work. Next, explain the purpose of this protected time. For example, to figure out ways we can plug gaps in each other’s knowledge, spark ideas or unblock issues. (Make sure to remind people at every meeting.) Finally you need to run the room, making sure everyone has a chance to participate and there’s time for decisions and follow-through on any next actions.

People are often surprised at how effective these sessions are. The trick is to understand that everyone gets blocked sometimes—and we all enjoy helping others. Your role is to create an environment where people can enjoy helping each other, and unblock some issues along the way.

Navigating bureaucracy

In Silicon Valley folklore, technical leaders are supposed to shield their team from the distractions and interference of the wider organisation.² Whether or not you subscribe to this view, as a leader you can help your team by navigating bureaucracy for them.

This can be as simple as explaining HR procedures or signing off leave requests promptly. But it can also include working to get clarity from management about priorities and fending off interruptions as your team works to deliver them.

Effective leaders give their teams what they need to execute. Sometimes that’s information or protected time. Other times it’s enabling conversations and collaboration. Or it might simply be filling in the right forms. The trick is to accept that however annoying it might be, bureaucracy exists. And you can make that reality more tolerable by handling some of it on behalf of your team.

Giving effective feedback

Receiving clear, actionable feedback is necessary for learning. We all need it to develop and grow our skills. In a technical team the stakes are even higher. Because the team can only make progress on complex projects if we’re constantly giving and receiving feedback.

Here’s the problem: most technical experts have never learned to give effective feedback. So what they share often isn’t helpful. Yes, there’s a technique. No, it’s not complicated or difficult to use.

Why we need feedback

There’s a ton of evidence showing that receiving feedback is essential for learning. I’m not talking about praise, rewards or punishment, which have been shown to hinder learning. In contrast, effective feedback:

• shows you how you’re doing without judgement
• explains the consequences if necessary
• offers clarity on how to improve

As a technical leader, you need to give feedback all the time. Whether it’s reviewing work in progress, performance appraisals, interviews, workshops—the list goes on. You also need to be skilled at receiving feedback in order to perform well.

When asked to share feedback, most people instead share judgements or labels, like:

• “this is poor quality code”
• “he may be quiet but he’s an A player”
• “the report is unprofessional”

Although these responses are based on your expert assessment, they aren’t useful to the recipient, for a few reasons:

1. People react badly to judgements—whether they’re positive or negative, about themselves or their work. This emotional reaction blocks their ability to take on your underlying message.
2. They have no way of knowing why you made this assessment.
3. They don’t know what to do with it or how to improve.

But there’s an easy fix.

The core problem is that people tend to mix their observations—things that they notice—with their evaluations. You can think of an evaluation as an assertion about whether something is good or bad, desirable or problematic, productive or wasteful. (You get the idea.)

It’s not that evaluations are harmful. They’re a necessary part of judgement and decision making. Even if you tried, you couldn’t stop making them. But unless you do some processing work on your evaluations, they don’t make for useful feedback.

Underneath each evaluation are the observations that led to it. All you need to do is figure out what you noticed:

Expert evaluation: Hmm, this looks like bad quality code to me.
What leads me to say that?
Observations: Ah yes, it doesn’t follow our naming conventions and rolls its own hashing function instead of using standard libraries.

Another example:

Expert evaluation: This report reads badly and is unprofessional.
Why do I think that?
Observations: The report recommends a particular investment strategy without considering alternatives or citing evidence to back up its claims. I also noticed several grammatical errors in the executive summary.

Here’s your quick guide to giving effective feedback:

1. Write down your evaluations (gut reactions).
2. Ask yourself what you observed or noticed that led to your first answer.
3. Offer your feedback as a set of observations free of evaluation.
4. If necessary, explain the consequences. For example, “If you don’t follow naming conventions it’s difficult for others to maintain your code.”
5. Offer a possible way for the person to fix the problem. Make it clear that they don’t have to do it this way—it’s just a suggestion to show that solutions exist.

Try it out the next time you need to give feedback.

Rate yourself

In this article we’ve covered the four types of communication skills that technical experts need:

1. Understanding business pain points.
2. Sharing your unvarnished reckons.
3. Explaining technical concepts to non-experts.
4. Leadership skills.

Rate yourself on these four areas. How do you shape up?

If you have room to improve, don’t panic. People aren’t born with communication skills, they learn them. It’s like anything else: you need to try out techniques, practise, get feedback and repeat.

Before you know it, you’ll be proficient—and ready to take on more challenging roles. Get started today!

1. Some exceptions apply, like when you don’t understand a crucial part of what they said. ↩

2. Steve Jobs famously flew a pirate flag over the building housing the Mac team at Apple. ↩