One thing I have learned over the years is that I am awful at communicating; I am a “techie-first, whatever-other-hat-second” Software Engineer. If I had a choice, I would be most comfortable in a dark cavern with a dedicated fiber line, a nice laptop, and a complex technical puzzle to solve.
That being said, I have learned - really, beat into myself - the understanding that we as engineers always need to communicate beyond just what we make.
In this post, I want to cover one of the most important topics of the tech industry today - Technical Communication.
Besides the “what”, I plan to cover below:
- Why is Technical Communication important
- How to approach Technical Communications
- What I have experienced
1. Why Tech Comm is Important
Taking a step back - what is Technical Communication? From an education standpoint, it is:
…a genre of non-fiction writing that encompasses not only technical materials such as manuals, instructions, specifications, and software documentation, but it also includes writing produced in day-to-day business operations such as correspondence, proposals, internal communications, media releases, and many kinds of reports. It includes the communication of specialized technical information, whether relating to computers and scientific instruments, or the intricacies of meditation. And because oral and visual presentations are such an important part of professional life, technical communication also encompasses these as well. Source: Technical Writing Essentials by Suzan Last
Back in the day *cough* 2009-2013 *cough*, I received my Undergrad degree at the University of Michigan. As part of our engineering curriculum, we were required to take classes in Tech Comm. To be frank, most of us in my Computer Science Engineering (CSE) cohort hated it. We did not declare CSE as our major to learn to write - we explicitly chose a profession where we basically write gibberish and something cool pops out the other end on our computer monitors… At least most of the time… Like, 80% of the time.
As it turns out, 4 courses in Tech Comm is nowhere near enough preparation for what the tech industry actually requires. For example:
"Tell me about {your project}..."
That’s a pretty simple question, right? It’s five words long, everyone has answered this in interviews, piece of cake…
But, who are you talking to right now? Is it your manager? Your tech lead? Your grandparents? An interviewer?
What context surrounds the question - is this a post-mortem overview of a sprint, is this a project recap, is this at a tech conference where you’re a speaker?
What level of detail do I need to go into - do they want to know the architecture, the code, the plan?
What if they don’t care about the technical bits and they’re on the Sales/Marketing/Leadership side of the house?
What about the business outcomes of the project?
On and on and on… this is not a simple question anymore.
Everything listed above and all the permutations that go with them requires a slight tweak in the fit, form, and function of your technical communication. The way you shape, word, and elaborate on your message; all these require a deft hand in deciding what is and is not appropriate in a given situation. If you do it incorrectly, you lose your audience, confuse rather than inform, and likely take a wrong direction into a lake… OK, maybe not a lake but you get the point.
By making time up-front to gather your thoughts and organize, you’ll likely save yourself and others’ time while giving a more comprehensive and accurate answer to simple or complex questions asked of you.
2. How to Approach a Question (Briefly)
We can and probably will spend multiple posts digging into different aspects of Technical Communication. For now, I’ll jot down a brief overview on the general focal points when a request comes your way. From the overview on “why” above, you probably have an idea on what makes up a question and what you will require. More explicitly, the moment I get a question I run through the following list:
- Audience
- Purpose
- Style
- Content
Audience
Who you are talking to is one of the most important parts of how you will communicate. Knowing the audience size, make-up, and knowledge level drives a big part of what story you will tell.
Examples:
- Audience Size: 1, Type: Manager - It’s an infamous one-on-one. There’s a whole slew of documentation out there about making your one-on-ones more effective. Likely in these situations, you’re answering the question about “your project” at a more technical level or a status update. This is not likely a presentation but a more informal discussion.
- Audience Size: 1-10, Type: Peers - I like tech talks and so do you, and to say the least there’s a science now to making one. Your peers are likely some of your most technically-driven audiences so your focus likely sits in that realm. Don’t get lost in the weeds the entire time though. While you can focus on showing how the sausage gets made, remember to illustrate the outcomes as well.
- Audience Size: 10-100, Type: Mixed - Tough crowd. Can’t go too high-level the entire time or you’ll lose the folks closer to the ground. Too low-level, you’ll lose the leaders and managers. Depending on the Purpose and Content, striking a balance by giving enough context while sampling the behind-the-scenes work is key here.
- Audience Size: 0-2, Type: Parents - Just call them every now and then, jeez.
Purpose
Now that we know who you are talking to, we need to break apart why you are talking to them. Similar to Audience, Purpose is giving you a set of guard-rails on the general direction of your answer. Are you informing about a change in the project? If instructing a group, do you need to prep a presentation ahead of time? Am I inspiring a company to follow a vision or strategic direction related for your project?
Each of these purposes lends to a different type of communication Style and content strategy.
- For informing, verbal and written communications vary on the audience and technical level required.
- For instructing, your written communication becomes more important than your verbal comms, though depending on how you’re instructing someone your verbal can be equally important.
- For inspiring or entertaining, there’s a dramatic flair added to all of the above to enrapture an ever-busy audience.
Your purpose is the subtle difference that guides the strategy for the type of Content you will produce. Clearly define it ahead of time to tell your story efficiently.
Style/Tone
Similar to Purpose, the way in which you say or write something now has also taken legs of its own. From advances in speaking like TED Talks (inspiring, entertaining), to podcasts (informative), down to written e-mails (hard inform), there is an appropriate style in which you communicate now as well. Am I going to strike a serious tone? Is comedy allowed? Do I have certain verbal or non-verbal cues I should hit with my hands and body posture? I won’t drain the list here, but in general terms:
- Purpose is solidly in the driver’s seat for style. Depending on why you’re talking about {your project}, your story will be framed differently and told in subtle, harsh, or mixed tones.
- Audience also shouldn’t be forgotten. The way I talk to a manager versus a VP, a peer, or my wife is probably a little different. I do not think my wife will appreciate harsh feedback, but a peer may find it useful.
Content
Now that you know:
- Who you are talking to
- Why you are talking to them
- How you want to talk to them
…you can get started on the actual meat of your answer to the question. Content varies in so many different ways and formats though - is it a presentation, a document, a book, a blog post, a recording, an email, a sticky note… Depending on the situation, you’ll have a wide variety of choices to make. From a technical communication perspective, I plan on covering a few of those in the future (namely: emails, presentations, and docs). For now, know every communication tool has a purpose.
3. What I Have Experienced
Now that we’ve broken the question into 4 different aspects - audience, purpose, style, content - I want to cover some common mistakes I have experienced in a few environments when someone has not thought through all 4 aspects.
The Missing Outcome
The most common missing piece, a lot of technical communication misses the “why” in the final answer. Take the interview prompt again:
Tell me about {your project}:
- Common Answer: I implemented the following tech stack, which was a difficult engineering problem.
- Real Example From Me: I developed an email parsing engine to replace a legacy case management system.
Does it answer the question? Yes.
Does it tell me about the technical aspects of the project? Probably.
Isn’t that the point? Almost
You can deliver the best, most efficient, awesome piece of tech out there - but if there is no outcome grounding it then you’re missing the bigger picture.
Granted, there are lots of cool technologies out there made for the sake of making. But in the context of a company or job, we as engineers need to know why we’re working on something along with how. If we look back at the previous answer, “implemented the following tech stack” answers how but not why. A better answer instead is:
- Improved Answer: I implemented the following tech stack, which was a difficult engineering problem. Delivering it improved Y feature leading to Z business outcome
- Real Example From Me: I developed an email parsing engine to replace a legacy case management system. We delivered it under budget and on-time, hitting 100% Case creation accuracy compared to the legacy system while saving $X.XXM dollars in licensing fees.
Always explain the why along with the what.
The Triple Tech Talk, or “Why Audience Matters”
Back when tech conferences were… things, I once went to an Amazon Web Services (AWS) Summit in nearby Santa Clara, CA. Outside of the keynotes, Amazon ran this summit in one of the most unique ways I have ever seen when space-constrained. As seen below:
What looks like a normal conference setup was 3 simultaneous tech talks happening at the same time, separated by silent disco headphones attendees would wear.
Outside of “Hey, that’s a clever use of technology”, attendees quickly figured out how to tweak the headphones and switch channels between the 3 tech talks… albeit discouraged as best as the ushers could. Blue = Left, Red = Center, Green = Right.
What that meant - and why ushers were a little persistent - is that you could visibly see when a speaker lost the interest of their crowd. If I’m sitting in the Red section, but half the attendees have swapped their headsets to Green, what does that mean about the content of Red’s presentation or vice-versa?
tl;dr; - I tracked this behavior throughout the day and landed on a pattern:
- Tech talk starts techy, keeps techy, got in the depths of AWS - The headphones stayed.
- Tech talk starts techy, but pivots to general marketing material (usually for stuff newly launched that day/in beta/not demo-able) - The crowd swapped.
Understanding the crowd mix you are speaking to is essential, though hopefully you are not put in a situation where you can directly see yourself lose the crowd… Talk about immediate and direct feedback.
The Frozen One
One last scenario that happens especially during interviews is more of a psychological one but one I’ll briefly touch upon - freezing up. I have had the (mis)fortune of this happening twice - once with a certain Redmond company, once with a certain video stream and chill service - and both times had me asking myself afterward, “why did I not just walk-through my story beforehand?”
If you know your audience, purpose, style, content, and have just a little bit of prep, this happens a lot less. Through breaking down the question, you will have thought through multiple scenarios, made various content and communication decisions, and weaved a fabric that tells your story effectively.
Understand your comfort zone and prep thresholds. From making note-cards to recording yourself speak, a little practice can go a long way.
At least for me, my big 3 helpers:
- I will have made bullet points
- I will wave my hands around
- I will attempt to intentionally - with purpose - talk slower
Last Bits
We have covered a lot here across a few paragraphs and stories, but there is still a ton more out there that you can read up as well.
- While we covered the surface-level content side of the house, the design of materials and supporting docs is just as important as the story we wish to tell. Google the type of material you’re making and dig in (like with presentations)
- Additionally, we did not even get into the underlying psychological factors such as conscious and unconscious bias that likely lie beneath the surface of what we say.
- Alternatively, maybe you like the editing portion of technical communication a bit more. Potentially look at subjects like copy-editing (like The Copyeditor’s Handbook).
Technical Communication is a life journey. Like body-building, the best way to work those mental muscles is by doing. Find creative avenues to stretch your verbal and written communication skills at home (like - say - a blog) or on the job.
If you take anything away from this, remember:
- Who - Audience
- Why - Purpose
- How - Style
- What - Content
And hey, maybe take that first step and leave a message as well as practice. Tell me about a project of yours…
Appendix
Link: The After-Post