TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Subject:Re: Transferable skills of a Tech Writer From:Monica Cellio <cellio -at- pobox -dot- com> To:mbaker -at- analecta -dot- com Date:Wed, 7 Sep 2016 11:24:15 -0400
As you go higher up the responsibility, senior manager, director, VP and
CxO on up, a particular skill-set, i.e., an ability to stay unattached,
becomes vital. Often at these higher levels department heads doggedly
pursue their own passion and agenda, many times not really ready or willing
to make tough decisions. Group think and party-line thinking pervades (yes,
even in startups.)
This is an important point. Sometimes what they most need is a reality
Several years ago, as I arrived one Monday morning, the director of
engineering met me and said "I need you to come to a meeting about
upgraders in 15 minutes". Upgraders were a key part of our software
related to data integrity.
We were, at the time, planning a major rearchitecture. The work would be
spread across three releases (roughly annual). We needed to decide now
what hooks to put in place so that future upgrades would be possible.
Something like $30M was at stake if we blew it.
I had been peripherally involved in the design and development of the new
architecture, but I hadn't been involved in the upgrader discussions at
all. I did, however, know a lot about our software (having been there for
many years and having contributed to parts of its design).
In the room were: the director of engineering, the CTO, the chief
architect, the lead developer for this part of the system, and the program
manager. They did not agree on how to approach the problem. Because I was
new to the discussion I started asking questions of each of them to tease
out what was important. I reflected it back to them, and started combining
things -- "you say we need to do X because of Y, but Fred is worried that
if we don't do Z now we're going to have trouble with YY next year, and Sue
says YY isn't a problem because of XX"... that sort of thing. Sometimes I
sprinkled in other ideas, like "would you be able to address Y by doing W
instead of X?".
I realized, partway through the meeting, that I'd been brought in because I
was the senior-most person who knew something about the subject and didn't
already have a stake in it. I was brought in as a *negotiator*. Some of
them, though, clearly thought I was just there to take notes so we could
document our decision.
We got it sorted out in the end. Sadly, this story does not end with "and
they acknowledged my contribution / gave me a bonus / thanked me", because
success in that sort of role depends on people thinking things were their
ideas. You have to check your ego at the door -- but do make sure to cover
it in your next performance review.
Visit TechWhirl for the latest on content technology, content strategy and content development | http://techwhirl.com