Why being a non-techie technical writer feels like being an American football kicker

The team is exhausted; they are gassed. They have been fighting with every ounce of their being for nearly four quarters. Just one more push, one more well-executed drive for a score is needed for glory.

The offensive line, despite weariness and the crowd noise disrupting their communication, coordinate their blocking scheme to perfection. This gives time to the receiving corps to execute a route combination that unlocks the defensive scheme; meanwhile, the running back correctly identifies the imminent threat of a blitzing defender, and he stifles the foe in his tracks. The quarterback – the much maligned and battered team leader – adheres to his coaches’ game plan and recalls with crystal clarity the scouting report which foretold what was to happen under the condition of a perfectly delivered pass to a wide-open receiver down the seam of the field: a first down, deep in enemy territory.

The offensive group mustered enough to get the ball in scoring position, but time is against them, and it is too risky to run another play. The kicker is summoned to boot a distant but manageable field goal that will seal the victory.

The ball is snapped; it is placed down; the laces spun away from the awaiting toes of the kicker.

The kicker – feeling no physical drain, but only mental and emotional weight – must only put his body and mind in a motion that he has done a thousand times, and the ball will surely go through the posts. However, a defender has leaked through the offensive line. The kicker rarely sees opposing colour this close to him before a kick. The defender is not close enough to block the kick, but his proximity to the kicker’s comfort zone is enough to derail the focus of the kicker for a fraction of a second. The ball is kicked. It sails wide left.

No victory. The team fails.

The dramatized version of hundreds of football games like the one describe above is, thankfully, a very rare example of how I feel as a technical writer (officially a “documentation specialist”) for a software company. The team of quarterbacks, skill players, and the offensive and defensive linemen, put everything they got into a game; the team of product managers, developers, programmers, and quality assurance specialists put everything they got into a software release.

Then there is the kicker: he sees the field maybe ten times per game, and he can either make or break the game – send the winning ball through or botch the attempt and squander the chance.

Then there is the technical writer: they are called upon late in the development cycle, and they can either make or break the software release – compose and publish an accurate document, or write poorly and omit crucial details that befuddle users upon using the software.

Technical writing was not the writing gig I was aiming for as I studied journalism and International Relations. However, thus far it has paid more than what my personal writing has produced. Even still, I am guessing that I am not a typical technical writer: I am mildly technical in that I can turn on a computer, use it, troubleshoot its basic problems, and turn it off. I do not know much programming (elementary QBasic has not carry me very far in today’s tech world); I rarely know nor care to know the exact speed of my Internet connection; I irritate onlookers as I work with my lack of keyboard shortcut usage. In work meetings, I am sometimes lost in the jargon-inundated meetings with terminology and scopes and “regressions” and quality assurances. But my abilities as a writer, and the questioning and getting-the-details skills learned as a journalist behoove me in this role.

In my American football career, kickers were known to receive special treatment apart from the other players. Kickers were rarely required to meet certain strength and conditioning benchmarks (relevant to their physique, of course). One collegiate head coach of mine once told our team’s kicker, “As long as you make field goals, I don’t care if you show up for weight sessions or not.”

I believe that my short experience as a technical writer can relate to the experiences of kickers. I am not working the day-to-day grind of coding, developing, testing, re-coding, re-testing, merging, and so on as my colleagues are. I am only needed when things are nearly ready and I need to translate technical jargon into an FAQ that any grandparent could follow. Similarly, kickers are needed only during specific moments in a game. They are not a part of the grueling drive that puts a team into scoring position. They just need to kick a ball between two pipes to tack on a few extra digits to the score.

Technical writers just need to dot their i’s, cross their t’s, and describe the product correctly.

Most of the time, I have delivered the kick I was expected to make; I’ve computed correctly the technical aspects of a feature and what it is designed to do for the user, allowing me to translate technical language into everyday English.

Good documentation goes through the uprights, and everyone is happy.

Write bad documentation – miss the chip-shot kick – and the world crumbles.

Successful field goals are appreciated, but expected. Missed field goals are ghastly and appalling.

I learned a valuable lesson several weeks ago. I failed to fully comprehend the content, the nature, and severity, the urgency, the purpose of a certain update to our software – hence, I did not produce an adequate document to properly inform our loyal users on the island of Malta. My poor effort was reviewed by management, and eventually the head honcho himself, who was so dissatisfied with the document that I was reamed over the phone and Slack for a good two minutes apiece. Luckily for me, there was still time left on the clock to make corrections before delivering the work to the public.

I could have, but did not, blame the poor document because I was given insufficient information with which to work. Kickers could blame the team for the poor setup, and team could blame the kicker for whiffing it. Good kickers and teams do not do that.

As with all the great teams I have been on, the software companies I have worked for, and especially the one referenced in this blog, have been great teams. Total blame never falls on one particular person. I have been on both sides of the spectrum: as an offensive linemen fighting to gain every inch of the field and a chance to win the game, only for the kicker to miss it, and I have failed to perform my duties after the development team worked long, overnight hours to get the product ready.

It is all about the collective effort when it comes to success or failure.

I never envisioned myself to be in this position, but I am thankful to have wandered into it.