Perhaps they’re not really confessions. More likely, secrets. Technical writers are in hot demand these days. Primarily due to the tech explosion and exponential growth of online architecture solutions.

For the last decade or so, I’ve helped many companies migrate from dated, clunky user guides to web-based help systems. The secret sauce to success is building logical workflows that do what?


#3. Territorial Determination

Many writers protect their future by guarding their territories. It’s quite common with developers as well. Face it. Job security is a sensitive subject when they’ve jumped from contract to contract.

Unfortunately, safeguarding documentation isn’t smart. Nor does it mesh well with team sprints. I’ve worked with far too many writers who see protecting their future earning potential as job #1.

Huge mistake.

Compulsive hoarding creates division of manpower. Soon you find your organization filled with employees and contractors protecting their turfs rather than engineering content solutions.

One large company I worked with years ago streamlined all content edits and distribution to one single person. Ouch.

Granted, she was excellent at her job. However, after my chat with her I realized she was more about protecting her existence within the organization rather than helping build better workflows.

#2. Product Testing Avoidance

“I’m the technical writer,” many of us say introducing ourselves to fellow team members. Unfortunately, traditional roles no longer contribute to product design and testing. Many writers resist opportunities to pitch in with product testing. What’s even more disheartening is they usually have enormous time gaps to fill.

Listen, I understand every project requires varying degrees of multi-tasking. However, all too often dev teams (I’m including writers in them) experience many times throughout the day when they could better manage their contribution to product advancement.

One finance company project I worked on was exceptional in managing time schedules and backlog work. We had a fanatical scrum master who was a genuine superhero holding our team to strict burn rates.

I loved it because it truly isolated those members of our team that were loafing. We eventually completed all of our sprints early and pitched in helping other sprint teams reach success.

Another project I consulted on had a half dozen writers. None of them were willing to shift gears and dive into product testing. I see this type of decision self-defeating and selfish. Indeed, also risky to future employment.

#1. Tethering Tools to Projects

If you’re a project manager or work on a hiring committee, beware. Writing tool selection of your technical writers can become self-serving. It’s actually pretty common to be devoted to your preferred software.

Living your professional life within MS Word or PowerPoint can be required depending on the organization. But structurally, it’s enormously limiting. Converting to web-based content management is by far, the better move.

As they say in the mafia, ‘Forgetaaaboutit.” You can forget about 1982 file management structures. Then give up wondering which version of the document is the most recent.

Online solutions have been used by companies since 2000. Shaming writers into learning JIRA and Confluence shouldn’t be a chore. We, as a creators, need to be more proactive about diving into the deep end and discover the beauty of communicating with developers.

The issue that’s common with some writers is their fear of learning new tools. Or worse: resisting the need to move from traditional tooling to online content management modules.

If you think about it, writing is merely half the job these days. If your writers aren’t building their skill set with other interfaces and products, they’re actually holding back your growth.

Am I suggesting every user document become tasks in JIRA? Hardly. Although relying on the use of a software project management tool will streamline open communication of your work. From a project manager’s perspective, I love seeing time-stamped updates on work flow.

Case in point: a small project I consulted on required the development of a custom-built API UI. Rather than build an admin module, the developers wanted to streamline content development within the text editor (Atom). “Nope,” was the response from one of the writers.

He wasn’t interested in expanding his writing environment to a code-based editor.

Was it professional insecurity? Doubtful. Instead, many writers fear revealing their learning gaps. However, I’ve also seen companies send their writers to online bootcamps to merge their writing skills with dev needs.

The result is always a better functioning team moving forward in product development and content creation.