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.
Re: % of time technical writers spend on core tasks?
Subject:Re: % of time technical writers spend on core tasks? From:Sandy Harris <sandyinchina -at- gmail -dot- com> To:TECHWR-L <techwr-l -at- lists -dot- techwr-l -dot- com> Date:Thu, 14 Mar 2013 10:50:39 -0400
On Thu, Mar 14, 2013 at 10:08 AM, <ryan -dot- minaker -at- ca -dot- pwc -dot- com> wrote:
> I'm trying to put together some percentages relating to how much time an
> average technical writer spends performing 'core' tasks. ...
>
> Any feedback/comments/ would be appreciated. This is what I was going to
> roll with -- 30% of time spent on core tasks, 70% spent on other (i.e.,
> learning software, attending meetings etc.)
I would define the "core tasks" differently, to include both research and
providing feedback within the project team.
Research includes reading specifications and RFCs to discover what
the software is supposed to do, looking at the marketing material to
see what we are saying it does, testing and often reading code to
see what it actually does. Often it also involves looking at other things:
developer mailing lists, testing and QC results, user feedback via tech
support or forums and mailing lists, ...
I find research takes about 90% of my time as I come up to speed
on a new project, then tapers off. On some projects, it gets as low
as 20% or so, but 40% is more typical.
Then there is providing feedback, which on some projects is the
most valuable thing I do. My testing finds bugs. Also, sometimes
two or more of the marketing stuff, the RFC, our product spec and
the code are inconsistent. I point that out. Sometimes the user
interface is not well thought out, difficult to use and to document.
I point that out and often suggest changes.
In the worst case I have seen, just providing feedback and
dealing with the ensuing kerfuffles took about half my time.
On a better designed and better run project, the percentage
is far lower, but I've never seen it get close to zero.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
EPUB Webinar: Join STC Vice President Nicky Bleiel as she discusses tips for creating EPUB, the file format used for e-readers, tablets, smartphones, and more.
