My final “Managing Up” post for Steyer Associates offers an abbreviated look at earlier trends in technical communications. Here’s a longer meditation on being in the trenches over some of the most life-changing technical advances in the past quarter century.
A decade out of college, I first asserted in a job interview that I was a writer. Previously, my job roles had included editing—for solar energy designers, conservation policy advocates, and a couple of dyslexic physicists. During that “editorial” apprenticeship, I typically tossed 90 percent of what I received and rewrote it. That made me a writer, correct?
I faked my way through that interview and went to work for a local power utility, where I learned the basics of tech writing, before the profession had degree programs or professional associations.
The tech writing basics? Forget what your English teacher said: There is no practical use for creative, complex sentence structures in tech writing: Continue reading
My post in the Managing Up series offers quick tips for how to do a quick audience needs analysis when you don’t have good info from product managers: “Who Are You? Who? Who?”
These tips work for assignments to document a small tool or app when you receive only a broad-brush statement about the target audience for the software.
My basic guess? For these kinds of (typically free) tools and apps, there’s something out there that’s similar. You can pretty easily find out who uses such software and identify the nature of common problems.
This month’s Managing Up post “You Want How Much Done? By When?” introduces scheduling fundamentals for contract #tech-communications workers.
Patty at Steyer Associates reported that their research showed that ~300 words was the right size for a blog post. So I had to pare from the 950 words I’d already drafted. I’m providing the whole article here—since scheduling for a program manager is a whole discipline. A 300-word peek won’t give you much insight into a manager’s compulsive, continuous thinking about schedules.
This topic is of interest if you are anywhere in your technical communications career where you need a deeper understanding of the scheduling processes. Continue reading
My latest Managing Up post for Steyer Associates — Program Management 101 – Session #1 — takes a peek at how techcomms managers tackle program management, especially for content projects in the tech sector.
Part 1 focuses on getting agreement (and documenting it) with cross-team stakeholders.
I’m writing this series for Steyer with a focus on providing insights for contract workers into how and why techcomms managers do what they do. The next article in the series is “Drafting and Refining Work Packages and Setting Schedules,” so please leave comments or write to me if you have specific questions about that aspect of planning.
I try to provide parallel insights between the Steyer posts for technical communicators and similar activities for fiction professionals. The related posts for writers and editors are:
Checklist for Writer/Editor Collaborations [PDF]
Notes for Indie Publishers [PDF]
My blog post for Steyer Associates — Stage Fright Part II: Your Writing Sample — examines how a tech-comms manager reviews writing samples when hiring a tech-communications professional. I discuss solutions for common problems, like when your current work sample is still under non-disclosure agreement.
I like to describe a parallel effort here on my blog for fiction writers, but the cases differ significantly:
- Your writing sample online is the first 10% of your ebook on Amazon.
Tip: Did you move the front matter to the back of your fiction ebook, so that a significant portion of that 10% is not copyright, dedication, and table of contents?Your “sample” should start as close to “a name=start” as possible.
- Your description / back cover text is what lures your reader.
Did you write a Fourth Grade book report or a marketing enticement that will help you “close” a sale with browsing readers?Most writers I’m met hate writing the back-cover text. It calls for an entirely different view of the story than what you just spend hundreds of hours writing. I’ve struggled with this 250 words more than any other text I’ve drafted, and don’t feel anything like a journeyman, must less an expert. Yet it’s not something that DIY writers can readily outsource.Here’s the most succinct guidance I’ve found, for staying on track in back-cover descriptions:
Stage Fright Part 1: Your Resume: My Steyer Associates blog post this month is about ensuring that a technical communicator’s resume serves as a writing sample.
The typical barrier to resume writing? Most people tend to get introspective, worrying about how to present everything they know. So here’s free advice for anyone who needs to maintain a professional resume:
Update your resume when you are not looking for a job.
You’ll have much better insight about your skills and your presentation of self when you aren’t under pressure.
When you’re writing your resume, try not to make it an existential crisis. It’s merely a recipe. If you’re too nervous, ask a writing professional to look at it — not for grammar and spelling, but as communication that describes the essentials of your professional self. Here’s the resume recipe: Continue reading
My July post for Steyer Associates plays on the David Bowie song — so if I’m going to risk an DMCA takedown, I might as well double-up and use the same headlines.
“every time i thought i’d got it made”
My Managing Up tips for TechComms professionals this month tackles the challenges of organizational and technology changes:
For those of us who’ve been around for a while, we turn over every rock labeled “new,” wondering: “Have I seen one like this before?”
Check the post for my best ideas on how to cope when management shakes the dice at your workplace.
“you’ve left us up to our necks in it”
Two “Rain City Comedy of Manners” books:
Artemis in the Desert
Nine Volt Heart
The Grrrl of Limberlost .
Penny Orwick and I completed a series of posts for Steyer Associates on peer reviews for technical documentation.
A point we both made in our example peer reviews was that the original draft content wasn’t ready for review, much less for publication. To wrap up our series, Penny suggested a checklist.
Today’s Ready for Review? A Checklist provides the basics, plus some cautionary notes about what you risk losing if you send poor docs for tech review:
- Discrediting yourself with your technical experts
- Discrediting yourself with your peers
Typically I link to my tech-communications blog topic with a parallel for fiction writers. But it seems like there are a lot of models out there. So this time I’ll just link again to my Checklist for Writer/Editor Collaborations.
Other topics in our “peer review tips” collection:
My Managing Up post for Steyer Associates this month — You Get What You Measure — touches on the difficulty with most metrics for productivity and quality in technical writing. I offer ideas for how to create personal measures to increase your satisfaction as a writer, editor, or other working in the content publishing chain.
Making progress on quality goals, working toward expertise—I believe these are fundamentals for personal ambition.
Sure feels like metrics for corporate tech-comms consistently undermines those personal metrics these days, doesn’t it?
What can we do, oh noble content providers, but go forth and meet our daily word count?
My related post on metrics and productivity in fiction writing is here.
Western Washington beat its old February – April rain record. Hunkering down inside to avoid the deluge, I’ve been providing reviews for other writers or begging beta reviews of my own draft fiction.
During this damp spring spent in fiction and nonfiction reviews and editing tasks, I repeatedly provided writers and reviewers with guidelines for how to review a manuscript. The tasks of a beta review for fiction or a peer reviewer for technical communications are different from an editor’s work.
My April Managing Up column for Steyer Associates is live: Lions and Tigers and Peer Review—Oh No!
Lions and Tigers etc. offers tips for 3 basic kinds of peer reviews in technical communications:
- Peer review as quality check
- Skill building through peer critique
- Mandated reviews as editorial replacement
As you might imagine, Continue reading