For engineers – aka techies – business communication can be difficult. Not because of the subject matter, but because of how it is communicated. No matter how engineering-heavy your organization may be, there is a business side. It is worth recognizing the different perspectives and the different ways those perspectives are communicated.
It is the business side of the organization that makes sure the company’s messages and values are clear to the market. This is critical. No matter what cool, techie stuff you and your team are doing – if it doesn’t make sense to the market, you don’t get paid. Hence, why it’s important for engineers to understand the business communication modality and how to participate in it.
A lot of my tips come from direct experience, and are tips that I have to remind myself of regularly. These tips also include what I’ve heard from my business peers who express frustration about getting information, engaging with, and understanding engineering teams.
Business Communication Styles
There are a multitude of business communication styles. For the purpose of this discussion though, we’ll look at communication “approaches” – personal (i.e., one-to-one, or one to a few) face-to-face, verbal communication, and personal written communication.
Whether verbal or written, though, there seems to be two extreme styles of techie communication: too brief or too lengthy.
Below is how I break down some of the challenges with both communication styles:
Brief (but Incomplete?)
Engineers will sometimes be too short with their responses, especially in written communication. This is often because they know they need to respond, but their brain is immersed in a separate, intense thought process. They also see the value in not wasting time with a whole bunch of redundant prose, which I assume every good business team member would value also.
Brevity is good in many cases, but it can be impersonal and incomplete. The incomplete portion is what causes problems.
Engineers and technical practitioners will often answer parts of questions, but not all of them (in an e-mail response, for example). This is partly because there’s sometimes the assumption the short answer will explain it all. But, this is often not the case because the dependency list for anything technical can be long and the business user doesn’t have all the dependencies enabled in their minds that the techie does.
My tip: Being brief in communication is fine, but you should always consider your audience’s perspective; and then ask yourself, “Will they think my response is complete?”
Lengthy (but Rambling?)
When discussing topics that the techie is deeply interested in, we can talk forever. We can get into details that are well beyond the typical listener’s scope. It’s not that the details are bad. They’re great! But they should be relevant and explained.
As you know it’s very hard to stay engaged in a conversation when you feel like things are over your head. Your listeners most likely are interested, but it’s good to build breaks into your flow of conversation to make sure they’re engaged and that they are in fact able to follow the conversation. Reading these queues might be hard. If you can’t tell, don’t be afraid to ask.
It might be that the people involved in the conversation are tremendously interested, but at a high level. Marketing, Sales, and Success peers are hungry to learn more about technical details, but they have to hear about the technical details at their pace, not yours. The best business people today will certainly try.
The other aspect of rambling is interjecting details that are two or three degrees removed from the conversation. This is usually fine with – even appreciated by – your close peers. But some people in the conversation may be trying hard just to hang on to the original topic.
Also keep in mind that fun references to super heros, movies, shows, and video games are usually going to flop. If you can’t avoid these references, don’t be shocked if your coworker doesn’t get the reference. Techies are a breed of their own, and what they think is fun or funny, might draw blank looks from others.
My tip: Never assume that the person or people you’re talking to understand(s) the engineering topic matter you are talking about. Confirm it by asking them explicitly; and omit tangents.
Interjection is another faux pas. This one is hard for me. I get actual anxiety when I’m not part of a conversation about something I am interested in or know about. Interjection in a community setting such as we have during days when lunch is delivered, is more acceptable than interjection when people are talking amongst themselves in the hall. In general, you should avoid interjection.
My tip: If you are going to interject, ask yourself, “iIs it kind, necessary, and useful?”. It has to be all three. And the necessary one is the hardest to answer. If you want to lean into the conversation, find the person(s) later, introduce yourself and explain your interest or how you might help.
No Response
The extreme form of brevity is no response. ‘No response’ isn’t acceptable, except in the cases of spam email or an unsolicited sales pitch.
When it comes to your peers – other engineers – however, you should never leave them hanging. Even more important is the timing of your response – e.g., less than 24 hours. You don’t have to have all the answers, or even any answers; but you do need to acknowledge the inquiry or request.
E-mail as a mode of operation is challenging to most techies. Their work is highly technical. It requires focused effort, and distraction can come at a huge cost. An engineer’s work usually can’t afford interruptions.
My tip: If responding to emails is difficult to do while working on a project, then set aside dedicated time for this type of communication.
The other reason for a lack of response could be poor task management and prioritization. You might acknowledge correspondence from a peer in your head, but that’s obviously not the same as responding. Forgetting you didn’t respond isn’t a great excuse, and better organization can help you avoid this problem.
Also, don’t just accept meeting invites without also responding to the email requesting your time to begin with.
My tip: Just respond. There’s no excuse not to.
Business Communication Channels
E-mail Sucks
E-mail sucks. However, business communication with your peers is often down through e-mail. You may not always be able to communicate through your preferred channel. Therefore, you have to be able to adapt to the channels and preferences of your peers.
Support Docs for Learning
You might like support docs. Many engineers prefer this communication channel to get the information that is important to them. But business users usually do not want to learn that way.
Your business communication preference is fine, but you should respect others’ systems for being productive. (As long as it works, and it’s not fax!) I try to limit my email to sharing info in a digest fashion, both in and out. But I get a lot of emails where people want to chit-chat. I grin and respond.
My tip: A lot of business peers will use email as their primary communication. Just swallow the pill and respond to emails.
Conclusion
This stuff is not easy. And even the idea of having to change how you communicate with your business peers is frustrating. But not being in a collaborative environment is even more frustrating.
For long-term career growth for engineers your ability to communicate and understand the business side of the house is critical. It’s useful for you to also just get insight into the business whenever you can.
Recently, during a lunch with our engineers, one asked me a whole bunch of questions about our go-to-market. I thought it was awesome! His drive to know will serve him very well. The business side should be doing the exact same with you, and in some organizations, it should be mandatory.
My tip: Find time to disengage from your code and projects in order to engage with the business. The energy from building and delivering applications is what drives you, but understanding and supporting the entire organization will be what supports your career growth. It will help you better understand why you build what you build.
As you grow your career and consider management, you will need to understand the flow of business activities and the importance of things such as go-to-market and communication with customers. High-performing engineering teams should be required to sit with the business on a monthly basis, at a minimum. And you should find ways to make engaging with your business peers effective and non-disruptive.
