Ten rules for bad development management

© 2001 by John Hedtke

Serial rights granted to STC newsletters to reprint the article in entirety in exchange for advance notification and permission and two copies of the printed final version. For reprint rights, contact the author at john@hedtke.com.

There are advantages to being a bad development manager. For one thing, you don't stand out from the crowd: most development managers are pretty bad. For another thing, bad development managers have a knack for getting promoted in the face of all evidence to the contrary. With mediocrity the norm, bad development managers have an edge: nobody expects much of them. Perhaps best of all, bad development managers don't have to do a lot of original thinking. 

This article identifies the ten most common things that bad development managers know in their bones. If you follow all ten of these rules, you'll be able to hold your head up as the baddest of the bad. 

1. Don't spec anything!

Specs are for wimps! A real development manager knows how to code from a complete system document written on the back of a cocktail napkin. Besides which, specs only mean that you'd have to waste valuable coding time writing words, and that's not what they hired you for, is it?

2. Never admit you don't know something.

Even if your ignorance is flying a flag, don't admit you don't know anything about the subject. If necessary, dismiss the idea as irrelevant ("I evaluated that and decided it wouldn't work here. I made an executive decision and saved my staff the time.") Don't join technical organizations, either; they'll just highlight where you aren't up to speed on a technical subject.

3. Don't inform your staff of innovations or tricks you're aware of.

As a corollary, your staff needs to be kept in the dark. You don't want them showing you up; besides, it's their job to come up with things on their own. And never encourage them to read magazine articles or books. If they ask you if you've seen something, merely say "I read that article a year ago" in lofty tones.

4. Plan your project by gut instinct.

Although closely tied to rule #1, this rule's a little different. You may not have a spec, but there might be a de facto consensus as to what you're generally trying to accomplish. However, real development managers know that there's no way to predict how long a development cycle will take, so you can't possibly schedule anything. Including release dates. 

5. Don't review code.

Reviewing code would make you responsible for other people's mistakes, and you'd never want to be held accountable for that. Instead, assume that everyone is coding well, tests their own code, and knows what they're up to. 

6. Don't have a test plan.

If you had a test plan, someone would hold you to it and you'd be accountable, once again. Let the tech support geeks deal with testing in their free time. It's good OJT for the product. If they've all been laid off because of a late product release, let your beta sites and customers do the testing for you. Everyone knows that software has bugs: that's what .01 releases are for!

7. Don't make time for support.

Tech support will want to know what's being done in the new product so they can be up to speed when the product comes out. Keep them in the dark as long as you can (even up to the date it's released to the customers if possible!) because they'll only ask embarrassing questions. Even if they don't, they're going to drag your people away from essential tasks like coding, and you already need everyone working as hard and fast as they can. 

8. Don't make time for documentation, either.

Documentation is a non-essential task that is simply not the concern of a good development manager. (It's only typing, after all.) The technical writers should be able to read the code and figure out everything they need to know. Similarly, you should never, ever give Marketing the most recent version for press releases. Let them take pictures and demonstrate the stuff that's been tested and you absolutely know is going to work, even if you've decided not to use it.

9. Ignore turnover issues.

There will always be some malcontents who can't see the vision as clearly and leave before finishing their commitment to the project. (Crybabies.) Explain to the remaining staff members that whoever left "wasn't that good anyway." And feel free to add programmers whenever the project is running late. Fred Brooks wrote "The Mythical Man-Month" 25 years ago about mainframe development in the early 60s, not about what you're doing. 

10. Interfere with other managers' departments.

The last rule is to stick your oar in wherever you can, whether you've been invited or not. Once you've got your people working to capacity, you should have a fair amount of time on your hands, so why not let other managers benefit from your expertise as well? They'll be sure to appreciate it, particularly if you have recommendations on who to promote or fire. Moreover, since they'll have to deliver your message when the layoffs come, you'll be able to keep your skirts clean. 

Scoring

• If you scored 1-3, tough luck! You're probably never going to be a bad development manager. 
  
• If you scored 4-7, you're well on the road to a stunning career in development management and will be recognized by your peers for what you are. 
• If you scored 8-10, your future is assured: you're going to be talked about with awe and wonder for years to come. 

Note: No one person was maligned for this article; rather, this is a summary of many different bad development managers (most of whom worked at companies that are now, oddly enough, out of business). However, if you're reading this and the shoe fits.... 

John Hedtke is the award-winning author of 23 books, including "RoboHelp for the Web" (with Brenda Huettner, Wordware Press, 2002). He is an Associate Fellow and a member of the STC Nominating Committee. He can be reached through his website http://www.hedtke.com. John lives in Ft. Wayne, IN, and is a member of the Hoosier Chapter.