Working well with others

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.

3 thoughts on “Working well with others

  1. Yes, talk to your SMEs. Equally important, listen to them. Even when they go off on a tangent about the fun stuff they do on weekends. Of course you can nudge the conversation back on-topic. But listening, to whatever the SME wants to say, is part of establishing the rapport that leads to a good working relationship.

    I always remind myself that the SME cares deeply about the product he or she is building — as least as much as I care about my writing. If I show that I care about the product too, the SME is usually happy to work with me. If, on the other hand, I scoff or roll my eyes, or come to a meeting unprepared because I couldn’t be bothered to do my homework, then I have no right to expect cooperation from the SME.

    1. *smacks self*

      Thanks for pointing that out, Larry. I couldn’t agree more: listening is vital. Your SMEs aren’t merely resources full of precious information that you can mine at will.

      Never, ever come unprepared. It’s not only disrespectful, but it makes you look like you don’t know how to do your job. How many lines of code could a developer write instead of waiting for you to get to the point?

  2. I think it is really important to engage with the SMEs as, well, people, and not just a source of information. I’ve seen other tech writers fail to get the amount of information they need simply because they are too formal – it is all meeting requests, appointments, very structured Q and A sessions etc. When this happens, it can often reinforce the ‘them and us’ feeling that often exists between tech writers and SMEs.

    SMEs are often very enthusiastic about what they do. In my experience, if you can tap into their enthusiasm and take an interest in them and their subject, they will volunteer more information than you actually need.

    100% agree with you about not wasting their time. If you don’t treat their time as precious, why should they care about your deadlines?

    I wrote an article on working with SMEs a while back, if anyone’s interested –

Comments are closed.