Becoming a Manager

There they go. I must run and catch up with them, because I am their leader!

Mohandas Gandhi

After 10 years developing software, as well as a few years leading a team informally, I felt ready to become a project manager. I’d been a successful software developer, writing system and user software,and I’d recently returned from an assignment in Japan where I’d initiated and successfully led a project for a major AT&T customer in China. In my not so humble opinion, I was prepared to lead a crack development team to greater glory.

The day my opportunity arrived, I was called in to meet the Lab Manager. This was back when managers actually played the part. He wore a Brooks Brothers dark grey pin-stripe suit with a red “power” tie. His window office had an immaculate mahogany desk with a beautiful Newton’s cradle and a couple of other high end executive toys. The only papers on his desk were neatly lined up in mahogany In/Out trays. He managed over a hundred engineers and was responsible for millions of dollars in projects.

He told me that he’d called me in to “explore the possibility” of offering me a job managing technical documentation for the UNIX® Operating System [1] (this was back when AT&T still owned the UNIX OS). Managing technical documentation was far from my first choice, but it wasn’t a complete surprise that this would be the offer. The last two promotions had been to documentation manager, followed within a few months by a lateral move to managing “real” work. And, it was commonly accepted that a promotion to documentation manager was a relatively safe way to let a manager get his or her feet wet. After all, how much trouble can you get into managing documentation?

However, this time, he said, he wanted to stop the revolving door. He said that he would only offer the job to someone who agreed not to seek another management position for at least two years. Had there been other openings, I never would have considered this job. My experience with documentation was sketchy at best. In fact, I barely recognized documentation as part of the process, let alone an essential part. But, there weren’t other openings, and it didn’t look like there would be any for quite a while. So I decided to take the job.

That was 16 years ago, and except for a couple of a short time outs, I’ve been managing technical documentation ever since. I’ve had the chance to do other things, but I keep drifting back to this field. I have found that managing technical documentation is unlike managing other projects. Some skills carry over, some don’t. The objective of this book is to present the strategies and tactics that I’ve found most useful. Some of them would most likely fail if applied to software or hardware development projects, and many of the best practices for managing product development are equally unsuitable for documentation.

By necessity, any individual’s approach is constrained by his or her personal experience. While I’ve done my best to draw on the knowledge of others in the field, my approach reflects my experience and biases. My experience is primarily in large companies, managing documentation for software products, some of them end-user products, some of them highly specialized system products, like the UNIX Operating System. In addition, I’ve managed documentation for hardware projects and web projects. I also have managed several SGML/XML technology projects.

My biases are reasonably conventional. I believe in light-weight processes, but thorough planning. I believe in treating writers like adult human beings, who in nearly every case know how to do their jobs better than I do. I believe in hiring the smartest and hardest working people I can find. I believe the most important function of a manager is to set up an environment where writers can be productive; an environment where writers are respected, given the tools they need, shielded from interference from the corporation and its managers (including me), and left alone to do their jobs.

I believe in taking full advantage of technology, but having been seduced more than once by sexy tools, I have a jaundiced view of what technology can and cannot do. As a member of the DocBook Technical Committee, I’m naturally biased towards XML generally, and DocBook specifically, but I’m also aware that XML is not the answer to every question about documentation technology.

Looking back on my first days as a documentation manager, I should have been amazed that anyone would entrust the technical documentation for a major product to someone so completely unprepared. It didn’t take me much time to realize that I was way out of my depth. But the good news is that the team I inherited was very experienced, used to clueless managers, and fully capable of getting along without a manager until they could train me. And since I was enlisted for two years, they had some time to whip me into shape and were therefore willing to spend a little more effort on a manager who was likely to be there longer than most. Most of what I know about managing comes from what they and the groups I’ve managed since then taught me, and most of my mistakes come from not paying heed to what they taught me.


  1. […] Becoming a Manager […]

  2. Dick,

    The fact that you consider your biases about management to be
    “reasonably conventional” says a lot about your character. In my experience, your philosophy of management is rare and enlightened. There are sadly few managers who really believe in “treating [their employees] like adult human beings, who in nearly every case know how to do their jobs better than I do.”
    To most managers, “empowerment” is nothing more than a marketing slogan that is used to sell predetermined processes to employees under the pretense of giving them power.

    I hope you’ll expand this section to show how this approach has actually worked for you, allowing your employees to find innovative ways to approach the job that a more top-down management style would have suppressed.

  3. Mr. Hamilton,
    Kudos to your blog and your pending book. I’d like to second the Feb 18 comments by Jim Leth. Bravo!


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: