You have 1 article left to read this month before you need to register a free LeadDev.com account.
During a recent panel about the role of the CTO, I was asked to name one of the most important skills for technical leaders.
My answer was ‘code-switching’, or the ability to tailor your messages based on the audience you’re talking with.
This might seem an odd choice, but earlier in the panel we discussed how my average day might include discussing a technical design with engineering teams, sharing a roadmap with a customer, explaining the company vision to investors, and collaborating with executives outside of R&D. Needless to say, those are all very different audiences.
Becoming an effective communicator is a crucial career skill for technical leaders, especially if you aspire to senior leadership. There are many aspects to becoming a good communicator, but I think it’s helpful to consider first principles. Whether your audience is one person or thousands of people, as a speaker you’re trying to convey a message, and have your listeners learn something new or update their beliefs (if we want to get nerdy, according to the Shannon Information Theory, information is data that causes us to learn something new).
This is where having empathy for your audience becomes critical. Learning happens in the context of our existing knowledge. If you try to teach a concept that is already well known, then nothing new will be learned. If you try to teach a concept to someone without the prerequisite knowledge, then similarly nothing new will be learned. You wouldn’t teach algebra before arithmetic for this reason. The sweet spot is to introduce a concept that builds on existing knowledge, and to use analogies to connect the new idea with existing ones that are better understood.
For any given audience, the first question becomes: what can you assume they know? Assumptions, by their nature, are guesswork, and it’s better to err on the side of assuming less, particularly the larger the audience and the less well known they are to you. A classic mistake made by many technical people is to assume the audience knows as much as they do. When I’m with an internal engineering team, I can generally assume they know our technology, internal systems, and common acronyms fairly well. However, that’s not a safe assumption for a customer.
By trying to guess what the audience knows, we’re trying to get into their heads. But what they know is only part of the equation. Understanding their motivations and concerns is the second crucial part. Your internal engineering team might be motivated by technical tradeoffs, while a customer cares about solving a business problem, and an investor cares about making a financial investment. Even if these audiences had the same knowledge, they have very different motivations.
Starting with the audience’s concerns, we can contextualize how we deliver our message and tune the level of detail based on our assumptions of their knowledge. This is ‘code switching’, as we tailor our message to make it most effective for a particular audience.
If this still seems a bit abstract, we can use an example to illustrate.
Applying code switching
Let’s consider a hypothetical new feature for a product. We can start by identifying the audience, some key assumptions, and how we might communicate with them about the feature.
Starting with our development team, we can assume a high level of familiarity with the product and implementation. They’re likely concerned about the scope, roadmap impacts, and technical trade offs in the solution. We can have a very technical discussion about the possibilities: we need to add a REST API to allow users to configure the Foo widget to perform Baz behavior based on a configurable schedule, restricted to admin users only. This is very detailed, but allows the team to determine an implementation plan and make technical trade offs.
Now, suppose we’re sharing a roadmap update with a customer. We can assume they’re using the product to solve a business problem, and know the product at a high level but not details of the implementation. They’re likely concerned with business value, risks, and costs. We can present the same feature in a very different way: next quarter we’re adding the ability to automate a task that today is manually executed by your admins. Here we’re making clear the business value of automating a task that requires human toil, but we’re abstracting away the details that are unlikely to matter to this audience.
Lastly, suppose we’re talking with investors about our R&D roadmap. We can’t assume they know the products well, but they’re probably familiar with the broader markets. They’re concerned with competitive posture, market opportunity, and business execution. This feature could be presented as: we’re closing a competitive gap by investing in automation, which improves our customer value proposition. Here we’re even more abstracted, because the specific capability isn’t relevant to the audience, but we’re addressing their concerns in a way that doesn’t assume any detailed product knowledge.
Hopefully this example illustrates the process of identifying the audience, making a reasonable set of guesses about their knowledge and concerns, and tailoring the same message in different ways. However, the best way to get good at this skill is frequent practice with different messages and audiences.
Practice makes perfect
When I started my career as an engineer, I struggled with public speaking. One of my early managers and mentors was generous in his feedback that my communication skills would be a career limiter and suggested that I join a Toastmasters group to build comfort and confidence. Today, it’s an essential part of my job. As a natural introvert who struggled with public speaking, I believe this is a skill that anybody can learn with practice.
There are many ways to practice code-switching. One approach is to take a real world example, such as a new product feature, and write down ways of messaging it to different audiences like we did above. Try out different audiences, document your assumptions, and iterate on how you would message to them. The downside of these table top exercises is that it’s hard to get feedback on the accuracy of your assumptions or the resonance of your messaging.
That’s why there’s no substitute for delivering the message to a live audience. This allows you to test your assumptions by asking clarifying questions (Are you familiar with the product? Are you concerned with the process overhead?) which will improve the quality of your guesses over time as you get more familiar with the audience. It also allows you to test the messaging and refine, for example presenting the same feature to multiple customers and tweaking the message to see what resonates best.
To build this skill, you need to find opportunities to practice. This is a great development goal to work on with your leadership, asking them to identify potential forums. Outside of work, there are groups like Toastmasters, meetup groups, and conferences that provide other venues to practice with different audiences.
At the heart of being a great communicator is having empathy for your audience. Tailoring your message to the audience makes any conversation more productive and is a broadly applicable skill. With some practice, you’ll find yourself code switching as an automatic habit.
