RE: How do hiring companies view TW resumes?

["McLauchlan, Kevin" <Kevin -dot- McLauchlan -at- safenet-inc -dot- com>]

Bill Swallow [mailto:techcommdood -at- gmail -dot- com] said:
> 
> >> - 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 worthwhile.

OK, specifically, now...

I make "preliminary" - otherwise known as 'Beta' - documentation 
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 find 
a willing customer. If somebody is demanding a specific 
feature, then we make a Beta cycle with them a condition 
of implementing what they want, of course. But I'm talking 
about general releases that incorporate fixes, feature 
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 aspects 
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 about
> > 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 your
> > respective positions) I'm practically invisible.
> 
> This is exactly why you need to measure the good impact.

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 effective 
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 contribution 
of the techwriter to sales last quarter?  Last year?

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 insert
> > a bunch of claims that you "raised this by
> > this amount/percentage", "lowered that by
> > that amount/percentage", but I'd be very surprised
> > if the majority of us were able to justify any
> > such claims.
> 
> Again, that's disappointing to here, because it's possible.

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 will
> > open up vast new vistas of opportunity for me
> > 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 transmission 
may be privileged and confidential, and therefore, protected 
from disclosure. If you have received this communication in 
error, please notify us immediately by replying to this 
message and deleting it from your computer without copying 
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 Writing,
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 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:
http://lists.techwr-l.com/mailman/listinfo/techwr-l-chat