As technologists, we may see our roles in terms of the things we’re building, creating, and enabling with technology. But our roles are ultimately about building, creating, and enabling things for people. Our business stakeholders (or customers or clients) look to us to solve problems. The way we’re sometimes called on to solve that problem is through effective communication.
This point became apparent in a recent conversation with my husband. He’s dealing with breakdowns in communication with the IT department, who are building and maintaining a database for a project he supports. Working with them has been a frustrating experience for him. They either respond defensively and push back aggressively when he asks about something that doesn’t fall under their purview, or their responses to a question are completely hard to understand. He’s found their communication style severely lacking and has tried to minimize his interactions with them. But this isn’t a feasible solution; he really needs their help, but they aren’t communicating well and it’s leading to time wasted and duplicated efforts while he searches for alternatives.
Why it's hard to "translate" for nontechnical audiences
In many ways, I empathize with his IT department. One of the most difficult aspects of my job as a technical program manager is translating engineering considerations into language that business stakeholders can understand. This is par for the course. I work on an engineering team that manages a huge marketing website and our primary stakeholders are in marketing. Most don’t come from an engineering background, although some have worked with us long enough to understand both our processes and how our site infrastructure works at a very high level. I frequently have the same conversation with multiple people. I have to direct folks to the right person with the answers if it isn’t me. And engineers on my team participate in conversations where they are asked about time estimates and technical feasibility, often to business stakeholders who aren’t as familiar with things like design systems, accessibility, and technical debt. It can get frustrating, exhausting, and sometimes, in the way of the day-to-day work needed to keep things running smoothly.
If you’re in a position where you have to work with folks on the business side of the house (in other words: teams that are not in product, engineering, or IT—examples include marketing, communications, finance, sales), you’ve likely found yourself having to distill highly technical information, instructions, or concepts into terms that business stakeholders can readily understand. This is certainly the case for people in IT departments who are tasked with onboarding and offboarding employees, training people on how to use and access company systems, and troubleshooting hardware and software issues.
There are no hard and fast rules for managing communications with business stakeholders but there are some things you should consider when deciding how, when, and what to communicate:
1. What is the stakeholder really asking for? If you’re not entirely sure what they need, or if what they’re asking for seems unreasonable at first glance, ask them for clarification before you offer an answer. Rephrase their ask in your own words and ask them if you’re understanding them correctly. I’ve done this many times before and it has saved me from wasting my time and from potential misunderstandings.
2. What does the stakeholder actually care about? We might be tempted to give a lot of low-level technical detail when a stakeholder is coming to us with a question or for help, but if you give too much you may lose their attention. Try to figure out why they’re coming to you in the first place. Do they have to deliver something urgently to their VP? Are they trying to troubleshoot something before their next meeting? Are they trying to build something as part of a marketing campaign? Are they trying to figure out a process? You want to get as much context as possible to help you frame your response and to provide the necessary level of detail. Pro-tip: if you work with a PM or someone else on your team who is business-facing, ask them for what amount of detail to give the stakeholder. And ask them what the stakeholder cares about, etc. This will save you some of the guesswork.
3. Is this a question I see often? If you’re answering the same question over and over, consider documenting that response and sharing it with stakeholders as needed. Documenting responses to commonly asked questions saves you significant time from having to recall information or search for it. Point people to the exact place where they can find a response to their question, and let them know to reach back out if they have any additional questions.
The type of documentation you should create depends on your company and your team’s culture, but here are some examples:
- Article on the company Wiki (listing out the steps of a process and including visual aids, like screenshots, as necessary or appropriate)
- Canned responses (a doc where you save templatized answers to questions that you can copy/paste into an email)
- Video recording (if you’ve conducted trainings, record them and share out the link)
- Dashboards (if people ask you for certain kinds of reports, create a user-friendly dashboard where they can locate that information at any time)
4. Am I the right person to answer this question? Sometimes people will reach out to us or put something in our queue in the hopes of it reaching the right person. If you’re not the right person, tell them who the right person is. You may want to let them know that you only handle X requests, but {PERSON} can help them with Y requests and here’s their email. Directing people to the right place is an underestimated form of helping but just as impactful.
5. Am I answering this in a way the stakeholder can understand? Do they really need to know how this thing works in the backend? Is there a simpler way of explaining why this isn’t easy for us to build? Am I using jargon or terms that are inaccessible? I will sometimes run a response by a colleague before I send it to ensure that I’m answering the question clearly and giving the stakeholder enough information to make a decision but not enough to overwhelm them. I will always let them know that I’m happy to answer additional questions and can clarify any points as needed. This lets stakeholders know that they can ask me questions and that I am willing to reframe my responses as needed to help them comprehend what I’m saying. People always appreciate this.
And whatever you do: please sound courteous, especially in chat or email. It’s impossible to read a person's tone in email, and poorly worded messages may come across more harsh or abrasive than we intended. Aim to be polite and avoid phrases and sentence constructs that can be interpreted as aggressive, accusatory, or defensive. Here are some examples:
- “What does that even mean?”
- “That’s incorrect”
- “That’s confusing”
- “That doesn’t make sense”
- “No” (as in, just no)
Also, niceties like “hi”, “please”, “thank you”, and “you’re welcome” go a long way in written communication. Use them as necessary.
Like everything else in business, which of these considerations come to mind depends entirely on the situation. And thinking through these alone won’t make the questions go away. But they’ll get you on the path to better answering technical questions for a business audience.
If you're an engineer or in an IT role, how do you manage communications with the business side? What has helped you successfully navigate conversations with business stakeholders? Share your thoughts in the comments section!
This post was originally published on my blog.
I'm Stephanie, a Content Strategist and Technical PM. Visit developersguidetocontent.com to learn more about my work!
Top comments (0)