A big part of a technical communicator’s job is research. The information we use to create content comes from a wide variety of sources: technical specs, product research documents, business proposals, white papers, internal wikis, customer support tickets…
And even from actual people. There’s lot of good info locked away in our coworkers’ heads. Getting to that info isn’t always easy, but I’m honestly surprised how often one question comes up both in interviews and in discussions with other tech writers: “How do you work with engineers?”
Because engineers are the worst, aren’t they?
Engineers are introverted, antisocial, taciturn, unfriendly to non-programmers, aloof, arrogant, too focused on their code to see anything outside of it, unwilling to explain their work to people they think won’t understand it, rarely respond to email, never care about the business case for what they’re doing…
That’s probably enough. And that’s nonsense, of course. But those are common misconceptions. I’ve even believed some of them at one time or another.
Here’s the truth: The people on the engineering team are your coworkers. They attend the same company meetings and that you do. They talk to the same product managers and see the same presentations.
If any of them are aloof it’s because they’re worried that you’re going to ask them a shopping list of questions that can be summarized as “tell me everything about what you do.” Or they might be worried that someone asking for details about their work is going to critique it.
The same way some technical communicators react when you ask them why they used those specific screenshots, or didn’t include more technical detail, or built an example in a particular way.
So how do I work with engineers?
The secret is simple: I talk to them. More precisely, I talk to them like people who have things to do and don’t want to waste their time answering a shotgun blast of random questions.
Email is a great way to set up meetings. But it’s much more effective to talk to them, at least for the initial contact.
And this is where I don’t really understand why people keep asking this (“how do you work with engineers?”): it’s just like any other meeting. Come prepared with what you want to get out of the meeting, know what you want to ask, make that clear to people you’re inviting, and don’t waste time.
Not that you need to strive for mechanical efficiency and avoid all small talk. Honestly, programmers/engineers do fun stuff on weekends, too. Just let everyone know what you want when you invite them and try to stay on topic as much as possible.
I said talk to them, right?
That’s ok, I’ll say it again. Meet in person if you can, or via phone or web conference if you can’t. You’ll get a lot more information that way, both in the initial meeting and in future meetings now that you’re both more than lines of text in email.
I know this advice is obvious, but I also know that I’ve had to be reminded of the value of face-to-face discussions. Often after an email exchange turned into a morass of text thrown back and forth, or after a few minor misunderstandings had started to turn things ugly.
A wise manager once told me that email has caused at least as many problems as it’s solved. Obviously an exaggeration, but it came from experiences dealing with difficult personalities, and the way that people will often assume the worst intentions in any email exchange. I’ve encountered this, too, where my attempt to say “I’m not sure about this idea and need time to think about it” is interpreted as “That’s the worst idea ever and you’re an idiot for proposing it.”
I’m better about crafting less ambiguous replies, but that also means learning when it’s time to step away from email because your answer is ambiguous, and you need to explain that in terms of “it’s not you, it’s me” (or “it’s not you, but…ok, it might be you, but I’m not sure yet”).
The answer should be simple
The answer to “How do you work with engineering teams?” should be simple: Work with them like anyone else. They’re your coworkers, maybe you’re even in the same organization. But as with anyone else, make your requests (and intentions) clear, be respectful of their time, and be appreciative. Which doesn’t mean baking them cookies after every meeting (although I doubt anyone would object), but “Hey, thanks for the info. Here’s the doc I wrote based on that.”
That also gives them a sense of ownership; possibly obligation, too, but that’s great. We want other teams to understand that they have a stake in the documentation (online docs, videos, tooltips, whatever).
Even better than cookies
The best possible way to encourage collaboration comes when we can share user stories. The highest compliment we can give our subject matter experts comes from user feedback. If you can tell an engineer (or product manager, customer support agent, and other SMEs) that you’re getting great user feedback on content that you created together, that SME knows that they’ve done something that’s directly helping customers, and they’ll be more willing to help you in the future.
Plus, that sort of thing looks great on their performance reviews.