As a technical writer, I straddle two worlds. In one world, I have to collaborate with brilliant solution architects, programmers, and engineers. In the other world, I have to work with marketing, designers, and trainers.

Straddling that line so much I’ve heard “Well they’re not technical” whispered more than once or said behind closed doors. It’s a value statement. While it’s easy to call it an unfair categorization for some as an outsider to the tech industry I’m going to say that sometimes non-technical people place this curse on themselves.

Carrying the curse

The curse that non-technical people bring on themselves is the real or implied perception that they aren’t contributors to technology project efforts. Take the case of non-technical people that don’t do their homework about the technology. Nobody expects them to be an expert. However, busy people do appreciate somebody who’s at least trying. You don’t know what you don’t know, and smart people can sense that. But when you lumber into a room and demand time from busy developers and other project team members before spending some self-study time, you can become seen as a time leech.

During my first official job as a technical writer, the engineering manager and his team were frustrated with my manager. During one particular nerve-wracking meeting, my manager tried to distort technical facts to her misunderstanding frustrating us writers and the engineering team. She was either too dumb or too arrogant to admit she didn’t know what she was talking about when it came to technology. After that meeting, my manager left the room first, when I was getting up to go the engineering manager pulled me aside and told me that if I could understand 50–80% of the technology on my own, I would be an asset to any programmers and engineers I would work with during my career. That was advice I’ve carried with me to this day.

While keeping abreast of technology has become more challenging especially in today’s cloud computing era, we live in an age where’s there’s a bounty of technical information available.

I’ve seen this curse strike project managers, technical writers, and even some executives.

Lifting the curse

On a team and organization scale, a collaborative culture can help lift this curse yet that takes action from technical and non-technical staff. Collaboration isn’t about one party doing something for another party. Delegation isn’t collaboration either.

I had a brilliant manager once. She was non-technical, a minority, and female in the wrong company at the right time (the wrong time for her, unfortunately). She provided more leadership to us writers than any of her predecessors. As a manager, she didn’t understand the technology we were writing about in our documentation and was clear about it. In the end that didn’t matter because she never claimed to the understanding. She had an incredible talent to remove distractions from us. Not to mention, she was a superb administrator. Her contributions to the team rivaled any of our past managers. She applied her strengths to some of our weaknesses and made our jobs easier.

Subject matter experts we dealt with liked her too because she was professional, organized, and conscious of people’s time. She had a talent for getting project teams the things they needed to get their work done. I learned from her the value of threading the needle — something I mentioned in a recent IDG Techtalk Twitter chat about soft skills in IT.

A non-technical person who can thread the needle to get what they need is an incredible asset. The SMEs saw my manager as somebody who listened, could marshall resources, and get things for the project logistically.

Regarding a technical writer role, it’s about a writer who can make the best use of other team members’ time. It’s about marketing people that at least ask, what can I do to help? Or it’s the non-technical manager who asks the team what they can do to remove project blockers?

Lessons learned

There are lessons in how my old manager operated for all of us especially non-technical people who think they might be carrying the curse:

• Acknowledge what you don’t know and don’t try to bend technical facts to your lack of understanding
• Ask how you can help, you might be surprised how much a round of edits to a document, a spare piece of hardware you have lying around in your office, or your talent for logistics can be a help to a busy programmer or engineer
• Respect the time of other people that you need information from by doing some upfront homework before you ask them questions
• Remember that collaboration is a two-way street so coming with asks isn’t collaboration, it’s asking for help

Fortunately, this curse isn’t deadly. It doesn’t even strike everybody. We all need to see it as a call to collaborate better with each other and draw out the diverse talents of the teams in our organization.

Hey there! My name is Will Kelly. I’m a technical writer and content development manager living and working in the Washington, DC area. After spending years focusing on technical and SDLC documentation, much of my work now focuses on thought leadership content and marketing collateral. My articles have been published by DevOps Agenda, Mobile Business Insights, TechBeacon, CNET TechRepublic, and others. Follow me on Twitter: @willkelly.