writing – Jim Grey

Four critical tips for getting your ideas implemented at work

By Jim Grey (about)

After eight years writing and editing software documentation, I itched to make software again, like I did in college. So I took a job with a software company as a tester.

My corporate mug shot from those days - yes, long hair and a beard — My corporate mug shot from those days – the Grizzly Adams years

The company made a sprawling product for an industry I knew nothing about, so I had lots to learn. Given my background, the first thing I did was reach for the manuals. They were incomplete, inaccurate, and poorly organized. There was online help, but it was unnavigable. Nobody was ever going to use the documentation to successfully learn the product. My boss managed the technical writers too, so I marched into his office to complain. I wasn’t delicate about it. “This stuff is terrible! I can’t believe you ship this to customers! It’s an embarrassment.”

He leaned back in his chair and calmly said, “What would you do to fix it?”

“I would throw it out and start over,” I began. And then over the next ten minutes, off the top of my head I outlined a project that would create new manuals and online help that would actually help users not just use the product, but get the best value from it.

Three days later, he called me back into his office. “Remember that thing you said you’d do with the documentation? You are now manager of the Documentation Department. Make it so.”

It was a bold move for him to take a gamble on me. I’d never managed people, and my project management experience was limited. What I didn’t know was that every year the company surveyed its users about product quality – and every year the documentation got the most complaints. My boss had been told to fix this problem, but had no idea how. Then I walked in with a solution that sounded like it just might work.

Most of this story is just the nuts and bolts of the project – hiring and coaching staff, creating plans and schedules, doing visual and information design for the new manuals and online help, managing the project, reporting to management, and even doing some of the writing myself. The details would be interesting only to another technical writer. Much of this was new to me, but I had excellent support from a boss who needed to see his gamble pay off. He also helped me navigate the inevitable office politics, including another manager who kept trying to torpedo my efforts. Also, the program manager helped me master the project management tools we used, none of which I had ever even seen before. My team and I worked on the project for a year and a half. It’s not often a technical writing team gets an opportunity to do a clean-sheet rewrite like this, and they were all enthusiastic about it. I worked hard to clear their roadblocks, respond quickly to their concerns, and generally be a good guy to work for, and it paid off in the excellent work they delivered. When we were done, we had written over 3,000 pages and had created a seven-megabyte context-sensitive online help system.

I was invited to demonstrate the new online help at the annual user conference. 600 people flew in from all over the United States, and there I was before them on the opening session’s main stage. My presentation was the last of a series about new features in the product. When I finished, to my astonishment the online help received enthusiastic applause – and then one person stood, and a few more, and several more, and soon the whole room was standing and applauding. That moment remains the pinnacle of my career; I can’t imagine anything else ever overtaking it. The icing on the cake was when I overheard the VP of Sales say to my boss, “All the blankety-blank new features we pushed you to put into the product, and everybody liked the blankety-blank online help the best! The online help! You’ve got to be blankety-blank kidding me!”

I used to think I was just a grunt paid to trade the words I wrote for a paycheck. Through this project I learned just how interdependent everyone is at a company, and how everybody is important. Specifically, I learned:

If you want to see your great ideas implemented, they need to solve a big problem the company thinks it has. The problems your company thinks it has may very well be different from the problems your company actually has. Frame your ideas in terms of solving the problems the company thinks it has.

When you’re doing something you’ve never done before, find people who can coach you through it. I don’t care how far down the ladder you are at your company, your success helps determine other peoples’. Look for someone who both knows how to do the thing you need to learn and whose success depends in part on yours – that last bit motivates them to help you. In my case, it was my boss and the program manager.

Work for people who clear roadblocks out of your way so you can be most effective. I now leave situations where the boss doesn’t help me in this way. It’s that critical.

Your success always depends on other people, so treat them well. In giving my team an exciting assignment and creating an environment in which they could focus, they happily turned out huge quantities of good work. Also, after we shipped the new documentation, I promoted every writer. They deserved it.

A footnote: That company went through tough times a few years later and so we all moved on, some for better positions and others (like me) because they couldn’t afford to pay us anymore. One of the writers who had worked for me called me one day seven years later, by which time I really had moved into software testing. She said, “We have an opening here for a test manager. I’d love to work with you again, and this is a good place to work. You really should apply.” I did, and I got the job. I found out later that just before my interview, she went to the VP and said, “He’s a great boss. You don’t want to let him get away.”

Sometimes the good things you do come back to you!

The difference between quality and excellence

By Jim Grey (about)

My long career in software development was briefly interrupted in the mid 1990s when I took a job editing technology books. My first project was editing a new edition of one of the publisher’s biggest sellers. I drew this plum assignment not for my l33t editorial skills, but for being the new guy. The author had a reputation for running his editors ragged, and the other editors were glad to scrape this book onto me.

I never understood why, because editing the author’s work was a pleasure. His writing was clear, engaging, and funny. When I made suggestions for improvement, he gladly took most of them. He even called me to discuss and improve on a few of them. He did require a lot of attention, all of it for the good of his book, as he sweated every detail. For example, I spent hours on the phone with him poring over proofs, which are draft printouts of the book after it’s been laid out. It’s the last stage before the book is printed, and he used this time to polish his work further. He sometimes rewrote entire paragraphs to make them funnier (as humor was his book’s hallmark) or reworked graphics to make them clearer, all of which never ceased to thrill the overworked layout department.

When we were done, we had a book to be proud of. I displayed my copy prominently on my bookshelf. It then sold a bazillion copies.

My next assignment was to edit a thick book about a communications technology that was still popular then. This author handed in cumbersome and clumsy text full of basic writing errors. His humor was lame and sometimes offensive. His technical explanations were incorrect and incomplete. I spent hours hammering his work into something marginally usable. He ignored most of my suggestions and avoided taking my calls.

After he had handed in 100 of the book’s 800 pages, he announced that he was done writing. I was incredulous as he explained that the remaining 700 pages would be reprinted (and poorly written) documentation from shareware related to this technology. What laziness! What gall! I accosted the acquisitions editor – that’s the guy who hired this author – and raised an unholy ruckus. I said, “This book will be useful to nobody!” He shrugged. “It’s his book. Is it on schedule?”

I spent the next several weeks with my stomach knotted from anger and disgust as I edited those 700 pages. I pinched my nostrils shut as I sent the chapters to layout. I suppressed my gag reflex as I reviewed the proofs. I rolled my eyes when my copy of the finished book arrived. I hid it in a dusty and forgotten corner of my bookshelf. Then I succeeded for several weeks at forgetting the whole sordid ordeal until I received a letter from somebody who actually bought the book. He wrote something that knocked me out of my chair:

“Dear Sir. I was trying to figure out this communications technology when I found your book. I wanted to tell you that it was exactly what I needed. I played with a couple of the programs the book described and, with the book’s help, got one of them running. Thank you for publishing this book. Sincerely, Some Reader.”

I was humbled. No, I was shamed. Mr. High-and-Mighty Editor thought that the author created a steaming pile of feces while giggling at the teller’s window as he cashed his advance check. Yet somebody found the book to be exactly what he needed.

I started to see that maybe I wasn’t the final arbiter of quality, that maybe quality is what meets the customer’s needs. I’ve carried this critical lesson into every job I’ve had since.

But now, many years hence, I have learned another lesson from these two books.

That first book was Macs For Dummies, Third Edition, by David Pogue, a keystone of the juggernaut Dummies franchise. More recently, you might have seen David’s technology column in the New York Times, or his acclaimed The Missing Manual series of books, or maybe the stories he does for CNBC and for CBS News Sunday Morning, or the four-part series he did for NOVA on PBS. David has done very well for himself since his Dummies days. He has worked very hard for it, leveraging every opportunity with his characteristic energy, wit, and grace. He could have gone a long way on those traits alone. But his ability to do top-flight work truly distinguishes him.

I haven’t been very kind to the other author here so I won’t reveal his name or the title of his book, which sold poorly despite the one fan letter. I’ve encountered him here and there over the years and he has always seemed very happy. But he has not achieved a hundredth of what David Pogue has.

The new lesson? Something modest may meet a customer’s need. But it sure is satisfying – and the hard work sure worth it – when you can really delight the customer. And David Pogue’s case shows that talent and hard work can still really pay off.