Re: AW: How do hiring companies view TW resumes?
Keith Hood <klhra -at- yahoo -dot- com>
KevinMcLauchlan <Kevin -dot- McLauchlan -at- safenet-inc -dot- com>, Christine Leisgen <Christine -dot- Leisgen -at- gmgcolor -dot- com>
Tue, 23 Mar 2010 10:02:34 -0700 (PDT)
A survey would be useful in quantifying the effect of documentation only if the customers indicate how much of their buying decision is based on documentation. If they tell you something like, 20% of their decision to buy your product instead of a competitor's was because your docs were better, then 20% of the purchase amount is to the credit of the docs group.
On design documents such as use cases or requirement docs, here's an idea: the cost of bugs can be quantified as the payroll cost of the rework time needed to fix them. Some of those bugs will result not from programming or database mistakes, but from the design docs not being followed properly. Those are what I call procedure-fail bugs. Sift the bug reports and identify the procedure-fail bugs. Then claim that if the docs had been read and followed in the first place, the company could have saved the rework costs of those procedure-fail bugs.
On a slightly less serious note: I always figured there is one way to provide numbers that exactly quantify documentation's effect on the bottom line. Have the sales people spend one quarter flogging the newest version of the software. Have them tell the customers that the new UI is designed to be so user friendly, so intuitive, that the company isn't bothering to provide any documentation - no online help, no user manuals, no startup guides...At the end of the quarter, compare the sales figures to previous quarters.
--- On Tue, 3/23/10, Christine Leisgen <Christine -dot- Leisgen -at- gmgcolor -dot- com> wrote:
> From: Christine Leisgen <Christine -dot- Leisgen -at- gmgcolor -dot- com>
> Subject: AW: How do hiring companies view TW resumes?
> To: "McLauchlan, Kevin" <Kevin -dot- McLauchlan -at- safenet-inc -dot- com>
> Cc: "TECHWR-L" <techwr-l -at- lists -dot- techwr-l -dot- com>
> Date: Tuesday, March 23, 2010, 4:45 AM
> Dear all,
> I would be interested in this as well. Our CEO just
> happened to demand exactly the same thing, not only for
> documentation, but for the entire development department,
> but it would be a start to hear some opinions for TWs.
> In the following are ideas we came up with so far:
> - Priorize use cases and review after the release, whether
> the products cover them sufficiently.
> - Survey, either web or telephone based, directed at
> customers, in regular intervals. Compare the results.
> Any suggestions, how you evaluate the quality of your
> documentation or products?
> Best regards, Christine
> > -----Ursprüngliche Nachricht-----
> > Von: techwr-l-bounces+christine -dot- leisgen=gmgcolor -dot- com -at- lists -dot- techwr-l -dot- com
> > [mailto:techwr-l-bounces+christine -dot- leisgen=gmgcolor -dot- com -at- lists -dot- techwr-l -dot- com]
> > Auftrag von McLauchlan, Kevin
> > Gesendet: Dienstag, 16. März 2010 22:01
> > An: Bill Swallow
> > Cc: TECHWR-L
> > Betreff: RE: How do hiring companies view TW resumes?
> > Bill Swallow [mailto:techcommdood -at- gmail -dot- com]
> > >
> > > >> - Increased product sales by 30% through
> the release of preliminary
> > > >> product documentation
> > > >
> > > > No one tracks such info at our company.
> > >
> > > Gasp! How do you track your successes?
> > >
> > > > I'm not sure how one could know.
> > >
> > > By employing the types of metrics you want to
> track. It requires work
> > > and change, but then again so does everything
> > OK, specifically, now...
> > I make "preliminary" - otherwise known as 'Beta' -
> > available, by strange coincidence, whenever we have a
> > Beta delivery leading up to a new product or new
> release of
> > existing product. In the past, we didn't do
> Betas all the
> > time, but our policy is to do them whenever we can
> > a willing customer. If somebody is demanding a
> > feature, then we make a Beta cycle with them a
> > of implementing what they want, of course. But I'm
> > about general releases that incorporate fixes,
> > bumps, etc.
> > So, when the rough patches have been smoothed in
> > our new ERP, sufficiently that I can consider asking
> > for new metrics and perhaps my own play-space,
> > what should I be asking for?
> > Which aspect of my work am I tracking, and what
> > of other people's work am I specifically matching
> > against, such that I'll get the kind of useful and
> > unambiguous numbers you are describing?
> > I'm asking sincerely, since I don't immediately
> > see my next few steps from here.
> > > > "Gee, Mr. Techwriter, we're also looking at
> hiring three engineers
> > > > who used to work at the same company you did
> and, combined,
> > > > the four of you seem to have taken credit
> for 218% of the
> > > > fiscal benefit from that one project!"
> > >
> > > Now you're just being snarky again.
> > Oh, well, yeah. A little. :-)
> > But I've been on the wrong side of the hiring
> > when such claims were accepted without the
> > hiring manager being able to verify them.
> > I shared an office with a non-productive braggart
> > for several months, until process got rid of
> > him. He set an ISO 9000 qualification effort back
> > by that much. I think he was hired out of naivete.
> > Everybody in that Ericsson TAC environment was
> > smart, motivated, skilled, and really nice people.
> > Tremendous working environment. Probably caused
> > somebody to let down their guard. Anyway, the next
> > ISO consultant was a dynamo, so we made up the lost
> > ground.
> > In an earlier episode (with NV Philips) I worked
> > in a group with a guy who initially seemed
> > impressive, and even had some recommendations,
> > but later turned out to be running his own
> > business out of our office and attempting to
> > sell industrial secrets. We were alerted to
> > the scam by a senior executive at Wang, USA
> > (the competitor whom he'd approached) - it's
> > good to have honorable competitors.
> > In the ensuing investigation, it turned out he'd
> > been hired on the basis of the accomplishments
> > of a former co-worker. The person who had managed
> > the bad guy and his co-worker was conveniently no
> > longer available.
> > > > For an existing product, somebody with the
> knowledge and ability
> > > > would need to examine all sales for that
> product, before and after
> > > > you ... ahem... "release[d]... preliminary
> product documentation",
> > > > and decide how to eliminate all other
> factors in a shifting market
> > > > to conclude that it was the docs and not
> eleventy-two other
> > > > factors that made the difference.
> > >
> > > Yes, that's generally how people track these
> things. They employ
> > > metrics tracking mechanisms so they can sleep.
> > What are _your_ specific leading and trailing
> > indicators, and how are you tracking them?
> > Specifically, how are you tying them to the
> > sales performance of certain products or releases
> > of products, to the exclusion of effects from
> > all the other people who worked on those
> > products and releases?
> > > > Anyway, my guess would be that most TWs are
> in no
> > > > position to be able to make specific claims
> > > > how their work _positively_ affects the
> bottom line.
> > >
> > > And yet the tech writing community is full of
> people suffering from
> > > Rodney Dangerfield Syndrome. I can't help but
> think these things are
> > > related somehow...
> > >
> > > I have and do track these things because it is in
> my and my company's
> > > best interest to do so.
> > Can we have some specific examples, please? Both what
> > you track and how you track it?
> > > > When I'm doing a good job (or you are in
> > > > respective positions) I'm practically
> > >
> > > This is exactly why you need to measure the good
> > I agree, and I need to do more in that direction.
> > The 'how' is a bit daunting.
> > I know how to measure Sales, both at the company
> > and the individual level. That's because there is
> > a direct tie back to each sales rep, that shows
> > all the orders they've booked.
> > There's less hard evidence for the effectiveness
> > of Sales Engineers. Certainly ours are a very
> > bunch, the sales that hinge on their participation
> > are generally successful ... but how much of that
> > is also the 'fault' of the Sales Rep or Biz-dev
> > exec who lined up the opportunity and developed
> > it to the point where Sales-Eng participation was
> > even possible?
> > Going back further in the chain, it gets more and
> > more nebulous to tie, say, an individual programmer/
> > developer to an amount of sales dollars. You can
> > do something like total up all the sales of that
> > product line, divide by the number of programmers
> > and developers and architects who participated -
> > making some kind of adjustment for those who came
> > and went during the period being examined. You'd
> > also apply some weighting factors to more or less
> > senior people... and then you'd get into the
> > niceties of this one just programs, but this one
> > divides his time between programming and leading
> > the team, etc.
> > Then you get back to that single techwriter who
> > writes/updates all the customer docs for all
> > the releases of all the products in the product
> > line that is served by those 35 engineers, six
> > testers, one builds guy, one-and-a-half automation
> > guys, and a sprinkling of managers. Beyond
> > seeing that the number of documentation-related
> > customer problems is constant-or-declining, and
> > that features and procedures and API coverage
> > and tips and tricks and workarounds and orienting/
> > explanatory background verbiage seems to be correct
> > and relatively complete, and reasonably easy to find,
> > how do you tease out the relative monetary
> > of the techwriter to sales last quarter? Last
> > What are the actual data and measurements that you
> > need to put into the system in order to separate
> > out that TW?
> > Possibly by the end of this year, the new ERP
> > will have settled down enough that I can make
> > requests, so what's the first, second, and
> > third request that I should be making? If I know
> > the kinds of data and the differentiators, I
> > can devise reports that will bring it out.
> > > > All of that to say: It SOUNDS good to
> > > > a bunch of claims that you "raised this by
> > > > this amount/percentage", "lowered that by
> > > > that amount/percentage", but I'd be very
> > > > if the majority of us were able to justify
> > > > such claims.
> > >
> > > Again, that's disappointing to here, because it's
> > I'm in the forest, looking at the trees.
> > With answers to my questions above, I might
> > be able to re-orient my perspective to see
> > that forest, rather than just the nearest
> > trees - multiple shifting deadlines on multiple
> > shifting product releases.
> > > > If I saw such claims, when looking to hire
> > > > someone, I'd immediately say the same thing
> > > > that I say to other religious claims:
> > > > How do you know?
> > >
> > > Guess I'm not working for you. :-/ My resume
> follows that format.
> > Howzat?
> > You'd be deterred from continuing to pursue a
> > job you wanted just because the guy you were
> > going to work with asked you "How do you know
> > that you personally were responsible for an
> > 18% increase in sales for Prod-X at your old
> > employer?"
> > > > Maybe our brand new Oracle-based ERP system
> > > > open up vast new vistas of opportunity for
> > > > and the other techwriters at the company to
> > > > start claiming such stuff. woohoo
> > >
> > > Not without your involvement.
> > For sure.
> > I could use some guidance on what TW-centric
> > stuff I can/should request.
> > Is there a good TW-centric guide to this kind
> > of measurement?
> > I haven't read Hackos for years'n'years. Did
> > she have anything on that front?
> > - Kevin (all ears, when he's not being snarky)
> > The information contained in this electronic mail
> > may be privileged and confidential, and therefore,
> > from disclosure. If you have received this
> communication in
> > error, please notify us immediately by replying to
> > message and deleting it from your computer without
> > or disclosing it.
> > Use Doc-To-Help's XML-based editor, Microsoft Word, or
> HTML and
> > produce desktop, Web, or print deliverables. Just
> write (or import)
> > and Doc-To-Help does the rest. Free trial: http://www.doctohelp.com
> > Explore CAREER options and paths related to Technical
> > learn to create SOFTWARE REQUIREMENTS documents, and
> > get tips on FUNCTIONAL SPECIFICATION best practices.
> Free at:
> > http://www.ModernAnalyst.com
> > ---
> > You are currently subscribed to TECHWR-L as christine -dot- leisgen -at- gmgcolor -dot- com -dot-
> > To unsubscribe send a blank email to
> > techwr-l-unsubscribe -at- lists -dot- techwr-l -dot- com
> > or visit http://lists.techwr-l.com/mailman/options/techwr-
> > l/christine.leisgen%40gmgcolor.com
> > To subscribe, send a blank email to techwr-l-join -at- lists -dot- techwr-l -dot- com
> > Send administrative questions to admin -at- techwr-l -dot- com -dot-
> > http://www.techwr-l.com/ for more resources and info.
> > Please move off-topic discussions to the Chat list,
> > http://lists.techwr-l.com/mailman/listinfo/techwr-l-chat
> Use Doc-To-Help's XML-based editor, Microsoft Word, or HTML
> produce desktop, Web, or print deliverables. Just write (or
> and Doc-To-Help does the rest. Free trial: http://www.doctohelp.com
> Explore CAREER options and paths related to Technical
> learn to create SOFTWARE REQUIREMENTS documents, and
> get tips on FUNCTIONAL SPECIFICATION best practices. Free
> You are currently subscribed to TECHWR-L as klhra -at- yahoo -dot- com -dot-
> To unsubscribe send a blank email to
> techwr-l-unsubscribe -at- lists -dot- techwr-l -dot- com
> or visit http://lists.techwr-l.com/mailman/options/techwr-l/klhra%40yahoo.com
> To subscribe, send a blank email to techwr-l-join -at- lists -dot- techwr-l -dot- com
> Send administrative questions to admin -at- techwr-l -dot- com -dot-
> http://www.techwr-l.com/ for more resources and info.
> Please move off-topic discussions to the Chat list, at:
Use Doc-To-Help's XML-based editor, Microsoft Word, or HTML and
produce desktop, Web, or print deliverables. Just write (or import)
and Doc-To-Help does the rest. Free trial: http://www.doctohelp.com
Explore CAREER options and paths related to Technical Writing,
learn to create SOFTWARE REQUIREMENTS documents, and
get tips on FUNCTIONAL SPECIFICATION best practices. Free at:
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-
To unsubscribe send a blank email to
techwr-l-unsubscribe -at- lists -dot- techwr-l -dot- com
or visit http://lists.techwr-l.com/mailman/options/techwr-l/archive%40web.techwr-l.com
To subscribe, send a blank email to techwr-l-join -at- lists -dot- techwr-l -dot- com
Send administrative questions to admin -at- techwr-l -dot- com -dot- Visit
http://www.techwr-l.com/ for more resources and info.
Please move off-topic discussions to the Chat list, at:
- Re: AW: How do hiring companies view TW resumes?, Sally Derrick
AW: How do hiring companies view TW resumes?: From: Christine Leisgen
Previous by Author:
Re: IE security update on Jan 21 broke link to htm from chm
Next by Author: Re: Metrics (Re: How do hiring companies view TW resumes?)
Previous by Thread: Re: How do hiring companies view TW resumes?
Next by Thread: Re: AW: How do hiring companies view TW resumes?
Search our Technical Writing Archives & Magazine