Tech people are steeped in the ways of problems. It's one of the fundamental organizing principles behind nearly everything we do. We find problems, define them, analyze them and solve them.

So it's not surprising that when we move into managerial roles, we view ourselves as management problem-solvers. We fix people problems. And that's often where the problems begin.

Managerial issues usually first manifest as some sort of crisis: A project deadline is missed, a budget is blown, a client or user is unsatisfied, or a business process is broken. And, as good problem-solvers, we start looking for solutions.

Often, these solutions involve some sort of process or policy. For example, if the breakdown was caused by a client's failure to share information in a timely manner, we require the customer to submit requests in writing two weeks before they need a service or product. If a client doesn't like the way a system works, next time we ask him to physically sign off on the requirements before any work begins on implementation. If IT staffers have delivered unintelligible memos to clients, we require that the authors submit them for editing before distribution.

These may seem like reasonable solutions, but in these examples, are the problems actually solved? I think that these approaches merely treat the symptoms rather than resolve the real issues at hand.

If customers aren't submitting requests in a timely manner, there could be several underlying causes. They may hold IT staffers in low esteem and either be deliberately trying to annoy them or, more likely, consider IT's time to be less valuable than their own and see no reason to give more lead time. The customer group may not understand the priorities or workload of the IT group, either. Or they may not know their own needs long enough in advance to make timely requests. But forcing a rigid timeline for formalized communication doesn't ameliorate poor relationships between the two teams or improve planning. It just annoys people and feels bureaucratic.

If a client doesn't like the way a system works at delivery, he probably never really understood his own needs completely in the first place. Forcing him to sign off on requirements probably won't help him to better understand what he's trying to accomplish with the next system or envision how the business process will flow. Often, requirements don't become entirely clear until users have a chance to play with a real system or at least a prototype or mock-up.

And if your IT staffers are delivering documents in poor condition, either they are poor writers or they don't feel that it's worth their effort to write well. While external editing can help (I know my editors at Computerworld are a great help), poor writing is usually the result of unclear thinking rather than an inability to string words together. Editors can't think for writers, but they can encourage them to think for themselves.

These typical types of solutions not only treat symptoms while ignoring the real issues, they actually reinforce the problems, making them more enduring and intractable than before. Policies mandating how and when to communicate usually result in formalized and narrow communications between groups rather than relationships based on mutual understanding and trust. Formalized requirements can't guarantee business value. And heavy-handed editing usually causes writers to stop proofreading their own material. Why bother if someone is going to do it for you?

When addressing managerial problems, always ask yourself, "Am I fixing the problem (as in resolving it), or am I fixing the problem (as in engraving it in stone)?"

Paul Glen is the founder of the GeekLeaders.com Web community and author of the award-winning book Leading Geeks: How to Manage and Lead People Who Deliver Technology (Jossey-Bass, 2003). Contact him at info@paulglen.com.