Management Tactics

Tom Van Vleck

Sometimes managers understand that the cost (and risk) of rework and recovery from mistakes is very high, and that it outweighs the cost of getting it right the first time, and see that the development culture has to be changed. At the same time, the good managers know that their organizations have significant inertia, and that there's a lot they can't change quickly. They don't start issuing decrees and edicts. They look for something concrete they can do to start things in the right direction. There are a lot of tactics that won't work: revival meetings, seminars, training, free books, and little plaques may all rock the organization out of its rut, but it'll fall back in unless the culture is changed.

Anthropology can help. It tells us that the troops will be interested in whatever management's hot buttons are, if only in self defense. This is a consequence of some people having more authority than others.

One tactic a manager can try, after some significant problem has been fixed, is to drop in on the lead engineer, and say something like, "Gosh, Tom, I heard about the XYZ problem. What really happened there? What would help us in situations like that? Is there any tool or resource you need?" In other words, not punishing or praising, just expressing interest. Meanwhile the engineer is thinking Oh-oh, am I in trouble? What's going to happen? Nobody likes visits from management: they may be perfectly wonderful people, as individuals, but interacting with somebody who could have you fired or disciplined makes anybody nervous.

With any luck, the result of this visit will be that the next time the engineer is about to release some product, he or she will take extra time to check things out, to make sure there's less chance of a management visit.

Triage. Small practical steps.

(This is a good tactic for a number of reasons. Besides setting the tone, that of caring about the real day-to-day details of quality, the manager is getting first-hand information. Upper managers, especially, tend to get their bad news late, filtered, and de-emphasized. Occasional contact with the front line folks might provide another channel for information to flow, if the manager can listen.

Rewarding a programmer with serious attention, and the tools needed to do a good job, makes a lot more sense than handing out monogrammed items.)