Following are some steps that you can take to resolve conflicts with your managers.

• Don’t make a plan without talking to your manager first. This one has always been a huge hurdle for me, given that I’m so tactical and immediately start thinking in flowcharts and mock-ups as soon as I’m presented with a problem. But it’s imperative that you not come up with a fixed plan of action on a goal without first conferring with the manager who is going to be responsible for making that plan a reality. The greatest risk here is that you talk through a project with your peers or—yikes—your boss and set some level of expectation that you feel pressure to meet. No offense, but your idea could be off-base, and when it comes to tactics, managers who report to you are better sources than your boss. They actually do it every day.
• Answer the “Why?” question first. When you first roll out a new project to your manager, come with a sheet of desired metrics or goals and a quick synopsis of the benefits to the company. A PowerPoint is probably overkill here; just tell the manager what the company wants to accomplish in general terms. The correct starting point is: “The company is going to outsource some desktop support in the third quarter, and we need to get some user environments standardized,” not “We’re moving to Office XP, so go shop for some upgrade prices.” Make it clear that the goals are not negotiable, but the path to them is still to be determined.
• Compare notes. Have a follow-up meeting with your manager in a few days and evaluate what he or she has come up with. This is one context where I think it’s best to tone down the manager/employee vibe and just collaborate. This atmosphere lets you present your own ideas in a way that your manager won’t resent.
• Be sure to include some input from your manager. The worst thing you can do is ask someone what he or she thinks and then completely blow off the person’s ideas. With managers, this risk is amplified, because they think a lot—maybe more than you know. Even if some of the feedback is pretty far off, mold some of your manager’s ideas into usable forms and include them in the plan. If everything you hear is just wacko, you have a deeper problem than just the project.
• Look out for the “Just tell me what to do” response. This is the big red flag that you’ve probably gone too far and actually are “micromanaging” your manager into frustration and maybe even fatalism. You don’t want managers to do what you tell them; you want them to understand your goals and then go make them happen (believe me, it’s a lot less work). If managers just throws up their hands and check out of a project, you can bet the ground-zero staff is going to do the same thing, and you’ll find yourself pounding out Java code to meet a deadline instead of coming up with your next big idea.

Some management mistakes are so common that you can actually compile them into a list. If you’re a manager struggling to find out why your team is dysfunctional, take a look at the behaviors in this list and see if any look familiar.

1. Not communicating with the team. I know, I know, you’ve seen the advice for communicating so often you want to smack someone. I want to smack myself for saying it so often. But you know what? Unless you’re on the front line heading into a military battle, you have to take time to communicate with your team members. You don’t have to pass on every shred of information you’ve gotten from upper management on a new initiative, but you have to give them enough information to know why they’re being asked to do what they’re being asked to do. The more information your team members have, the more ownership they’ll feel in the process, and the better they’ll perform.
2. Continually focusing on the negative. Thinking in negative terms is a common result from working in a reactive environment, which IT tends to be. In that environment, IT spends most of its time keeping the negative to a minimum with goals such as decreasing network downtime or putting out fires. A good leader has to make an effort to recognize the positive. (How about mentioning increased uptime?) Recognize your people for the forward progress they make and not just for their efforts to keep things from getting worse.
3. Changing policy due to one person. The term “team” makes some managers think they have to treat everyone the same way. This is true in many cases, but if one person has a performance issue, don’t take across-the-board measures to correct it just because you’re afraid of confronting that one team member. If one team member is failing to complete some duties in a timely manner, don’t introduce a policy forcing the whole team to submit weekly progress reports. Deal only with the one with the issues.
4. Not understanding the needs and concerns of your team. Some IT leaders find it virtually impossible to tell their bosses that something can’t be done. The team’s bandwidth or overall state of mind takes a backseat to real or imagined glory of being the guy who “gets things done.” Good managers don’t over-promise on their team’s behalf.
5. Never admitting you’re wrong or never taking responsibility. There’s risk involved in being a manager of a team. And that risk is, if your team fails at something, you should and will be the one held accountable. It doesn’t matter if one team member screwed something up; your job was to manage the overall process of all the team members, and you didn’t do it. So suck it up and own up to that. On a related note, if one of your actions caused a kink in a project, admit it. It’s ironic but not owning up to a problem damages your credibility with your team more than simply saying, “I was wrong.”