This article originally published on our sister site, TechRepublic.

One of the toughest adjustments I’ve had to make in my career is learning how to manage managers. It’s a different ballgame—if someone has earned the responsibility of overseeing a process or functional team, then he or she also has entrenched habits and acclimations that you’re just going to have to deal with. You’re not working with unformed putty here.

The first lesson I learned—and it was a hard-bought one, I can assure you—is that you just can’t hand a to-do list to a manager and expect that person to smile and say, “Yes, sir!” That’s a real risk for many of us in hands-on fields, such as IT, where most managers earned their reps by being successful in tactical areas. You saw how the machine was misfiring, you fixed it, and you got a promotion. It’s a simple enough equation when you’re just dealing with object-oriented design or a QA timeline.

People, on the other hand, have bothersome egos and tempers you have to deal with. The managers who report to you, in particular, are likely to be a little headstrong, independent, and sensitive to being given explicit marching orders. If they weren’t, they couldn’t run team meetings and come up with innovative solutions to problems that you haven’t even noticed yet, which is what you ought to be getting from your investment of confidence in these people.

Being a totally hands-on character myself, I’ve been forced to develop this little rule to help me curb my enthusiasm for the details when dealing with managers who report to me:

Don’t tell managers what to do; tell managers what you want them to accomplish.

Of course, I’ve had to cheat once in a while, particularly when launching a new product or process. And from time to time, somebody just won’t get it. But by and large, this little pearl has saved me a lot of consternation over the years. In fact, I’ve tried to extend this philosophy to frontline staff members who report to me, and that usually works out as well. With managers, though, this is one little piece of management dogma with which I will never part.

There is, of course, one caveat—you have to plan in advance.

Come prepared
I’ve found that many second-tier managers who have a reputation for “micromanaging” are basically just flying by the seat of their pants. If you don’t have some midrange or long-term developmental goals for your team, then you’re not going to have the time to let your managers build their own plans. You’ll just be passing along tactical ideas that came up in a manager’s meeting.

Your managers hate that. It robs them of a sense of investment in their work and, even worse, gives them the impression that you think they’re stupid, which of course, is not your intention. You’re just in a hurry.

There’s no simple solution to the eternal friction between near-term and long-term management—you’re just going to have to juggle. Yes, there will be times when you do need to ask one of your managers to tackle a specific task at a moment’s notice. And if you’re engaged in the team, you’re always going to have good ideas about how things should work. Shut down that part of your brain, and you become detached and indifferent in the eyes of your reports.

Like I said, no simple answer. And you can count on a few feathers getting ruffled, particularly if you are tackling a problem on the team. However, here are five little tricks I’ve come up with that have helped me steer clear of serious conflicts with managers when I need them to fix a problem or drive a new initiative.

  • 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.