The recruiter backlash against technical writers with public sector experience

Photo by Casey Horner on Unsplash

Over the years, I’ve come across technical recruiters who have a bias against technical writers with public sector project experience.

Here’s one such reference I came across a few years ago:

By contrast, a background in government or national intelligence will likely count against you; this client’s experience is that such exposure dulls one’s writing skills.

Part of me agrees with such feelings. However, after serving public sector clients, I know there can be more to the story. The big secret of technical writers in the public sector is that they sometimes don’t even do the writing because of documentation by committee. There are also government contractors that bill by butts in seats first without regard for the solution. I came to see that there was no such thing as a one-person project when a federal contractor could dupe the client into four people for the job.

The real question these recruiters should be asking is the government technical writer ready to break out of their current situation? Look for a writer who has been keeping their skills up and who wants to get back to work to answer that question. There’s also the technical writer who grew tired as a professional and taxpayer of seeing waste across projects on a daily basis. It’s one thing to look down on government writers, but I challenge any of those people to spend time onsite in the information technology group of a federal government agency.

I watched federal government work lull many good people — not just writers — into false complacency and near career catatonia. When your biggest decision is where to go to lunch that day that is no way to live as a professional. It can be like socialized welfare in many ways.

However, for many people, a federal contract represents paying your mortgage and your kid’s college bill.

Don’t hate the technical writer, hate the game

As a technical writer who has crossed over from the commercial to the public sector (and back) a few times during my career, I’m the first to say that there are some technical writers and IT professionals who can’t make the switch between those worlds. That is on the person, not a statement on the entire industry.

On a positive note, government mandates such as the Data Center Optimization Initiative, Modernizing Government Technology Act, and the upcoming Cloud Smart are changing the technology stack and in turn the technical content (hopefully) that technical writers on public sector projects are producing. Right now, I work in the corporate growth group of a government systems integrator. Much of the work I do these days: white papers, marketing collateral, and technical solutions content is much like the content I’d be doing if I was working in a firm serving commercial customers.

In my freelance writing life, I’ve long been a proponent that the public and commercial sectors can learn from each especially in emerging areas such as agile development, DevOps and compliance. After all, when you peel back the bureaucracy and stereotypes, the public sector is one big IT compliance play.

Federal systems integrators are having to learn more about communicating value proposition and thought leadership not just writing proposals. They’re also having to learn how to make strategic alliances with established and emerging technology firms because government technology requirements are changing. More agencies want to use what the commercial world is using. Technical content in the public sector is changing along with those business shifts

In fact, I go on record to say the public sector is probably about the purest cloud computing play right now in my opinion.

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.

The curse some non-technical people place on themselves unnecessarily

Photo by Natalie Jeffcott on Unsplash

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.

Some of my content development goals for 2019

Photo by Bram Naus on Unsplash

As 2018 comes to a close, I’ve begun to start thinking about some content goals for the next year. My intent has always been to have the right mix of personal and professional writing projects to keep me busy. While my day job has been quite demanding the past few months, my freelance writing projects not so much, I’ve been looking forward so I can kick off writing in 2019 on a positive foot.

Here are a few of my content development goals for 2019:

Continue reading