Help Your Manager

Many developers complain that their managers don't understand what the team is doing, don't provide the necessary resources, and have unrealistic demands or expectations.

Most managers are neither stupid nor malicious, and are honestly trying to do their jobs well. You can help your manager to be more effective by following a few simple rules. Making your manager effective and happy is an excellent way to advance your career. Following these rules makes the manager and team more effective, which is good for everybody.

You can think of this as "managing up"; that is, managing your manager.

Or you can just complain about your managers behind their backs, hold them responsible for all the problems, and continue to suffer from their shortcomings.

If your manager actually is dumb as a stump and/or completely evil, then ignore the following advice. Just work on your resume, and find a better job. If you believe that all ManagersAreMonsters, then maybe you should look for a line of work where you will not have to deal with managers at all.

Be honest and respectful

Don't LieToYourManager. This never helps. Don't overstate your progress, and don't make promises you can't fulfill. Be honest about mistakes you've made and problems you don't know how to handle. You can get yelled at a little now, and then fix the problem, or wait and get yelled at later when it is too late.

Asking tough questions is the manager's job--don't take it personally. Most managers do not enjoy humiliating people, and are not looking for an excuse to fire you or trying to make you quit. Don't treat the manager as an adversary; remember that you are both on the same team.

Don't treat the manager as a clueless moron. Never SetTheBozoBit on a manager. If the person has been given a management position, then the person has probably demonstrated some sort of competence. Just because the manager isn't a brilliant developer doesn't mean that the manager doesn't bring important skills to the team.

Managers have to deal with a lot of issues that developers don't, so their priorities and focus may seem out-of-whack sometimes, but it is best to trust that they have good reasons for doing whatever they are doing. Everything works a whole lot better when managers and developers AssumeGoodFaith from one another, especially when the going gets rough.

See also HowToTalkToManagement

Discuss issues in terms of Costs, Schedules, and Risks

Your manager might not, as a manager, care much about "elegance" or the QualityWithoutaName or any of the other metaphysical aspects of software development. That is as it should be: a manager's responsibility is to make sure that work will be finished on time and within budget.

A manager's job is to allocate resources, to track progress, and to manage risk. You can help the manager do that job by presenting information in that context.

Whenever possible, give the manager specific numbers, and list the specific consequences of any problem or decision. ManagersLikeMeasurements.

For example, when a problem comes up, don't just say "We found something ugly in the code, and it will take a while to fix." Instead, say "This will take two weeks to fix, which will make us miss our next deadline. But if we don't fix it, then such-and-such will happen."

Whenever you are about to embark on some major effort, be sure to ask yourself IsYourCodeThatImportant. If you aren't sure, ask the manager before you spend time or money doing something that may not be necessary. Suggest ways to SimplifyTheRequirements if you think you know how to reduce cost/time/risk.

Present alternatives

Don't just tell managers that there are problems, and wait for them to tell you how to fix them. That's not a manager's job.

If it is a technical problem, then technical people need to determine potential ways to address it. If the different alternatives have varying tradeoffs in cost, schedule, or risk, then it's the manager responsibility to decide between them. A manager's ability to make a good decision in such cases is directly related to how well the technical staff explains the alternatives and the consequences.

Don't overload the manager with details

A busy manager may receive dozens (even hundreds) of e-mails per day, and have dozens of scheduled and impromptu meetings and teleconferences. Don't add to the noise--only give managers information that is relevant to their jobs. (See also PeopleWhoDontNeedToKnow.)

Also, don't expect the manager to remember all the details all the time. The manager is probably dealing with a lot of issues. Don't assume that what you are working on is something the manager is constantly thinking about. So, don't send the manager a message saying "I fixed that problem we were talking about last week." Instead, say "I fixed Bug #123".

When you need to present the manager with detailed information, put it in an e-mail or a memo so that the manager can read it when not distracted by other emergencies.

Don't use techie jargon with a non-techie manager

Many developers answer simple questions with a lot of technical mumbo-jumbo (from the manager's point of view). Sometimes this is due to inexperience (junior developers don't realize that everyone in the company isn't a programmer), but sometimes this is a deliberate defense to make the manager feel stupid and to stop asking questions.

If the manager is a techie (for example, the manager might be the lead developer or system architect), then feel free to use as much jargon as is needed.

And when technical details really are relevant to the manager's decision-making process, then use the real jargon. Don't dumb it down; educate the manager.

Accept responsibility for your work, and take initiative

When assigned a task, wholeheartedly accept it as yours and do whatever it takes to get it done. Don't say "That's not my job" whenever you are asked to do something you don't want to do. Don't whine about how unpleasant the task is. Don't try to weasel out of doing it.

If problems come up, figure out how to fix them. Don't blame others, or push the responsibility elsewhere. If serious problems come up that you can't fix, or which will have an exhorbitant cost, then make the manager aware. Otherwise, don't bother the manager with every little problem you have.

If you don't understand the assignment, or don't understand how your task fits in with The Big Picture, then it is your responsibility to ask.

If you have "nothing to do", don't sit idle. There are always documents to be written, unit testing to be done, makefile dependencies to be updated, bug reports to be researched, development tools to be evaluated, and so on. Do something useful; don't just make yourself look busy to avoid another assignment.

Don't be afraid to argue with your manager

If you think your managers are making unreasonable requests, then talk to them about it. They often do not realize they are being unreasonable. Managers want to know the truth, and most managers are very willing to change their minds. Good managers want people to correct them. Some managers like to PushPeopleUntilTheyPushBack.

But be respectful. Don't be insubordinate or confrontational. Stick to the facts--don't attack the manager personally. Remember that managers are often not accustomed to the kinds of heated discussions that developers have with one another, so adjust your behavior accordingly.

It's better to be credible than to be agreeable. Managers will defer to your judgment if they believe that you know what you are talking about. If you get too defensive, or if you are too willing to agree with them, they will lose confidence in your abilities.

If there is something you need, then ask for it. Don't wait for the manager to figure out what it is you need. If there are development tools, products, facilities, or other things that will make you more effective, then all you need to do is convince the manager.

However, don't waste a manager's time arguing over trivial matters, or second-guessing decisions that have already been made. Don't be a ChronicComplainer.

Don't be afraid to negotiate with your manager

See NegotiatingWithManagers

Manage your own workload

Managers usually don't realize it when they are overworking people. And some managers intentionally give people too much to do just to see how they handle it. If you or other members of the team are getting too tired, you have a responsibility to let the manager know. No manager wants people to lose productivity, or quit, due to too much stress.

Contrary to popular developer belief, managers do understand the concept of overwork and its negative effects on productivity. But managers need you to let them know when the limits are being reached. Overworked programmers don't sweat, turn red, collapse from exhaustion, or display any other obvious signs that a manager can recognize. It's hard to tell the difference between someone working sixty hours a week due to excitement about their work and someone working sixty hours a week because they overcommitted themselves.

When assigned new tasks, don't be afraid to say "No, I can't do that," or to ask "Which of these other tasks can I let slide?"

Telling your manager that your estimates were too low and that you can't meet your commitments may be unpleasant, but it's best to do it as soon as possible.

And don't forget to take a vacation once in a while.

Off-load some of your manager's workload

They say that management is like HerdingCats. Until you've been a manager yourself, you won't fully appreciate the analogy. It may seem like your manager does nothing except read a few documents, talk on the phone, give presentations, and walk by your cubicle to criticize you once in a while, but a manager's life is actually very busy and chaotic. Managers who seem calm and unhurried are not lazy; they are just very, very good managers.

If your manager seems overworked, or if you are interested in management yourself, offer to take on some of your manager's tasks. This will make the manager more effective (which is good), and will also help you learn about management yourself (which is also good).

If you are a senior developer, or otherwise have a position of respect within the development team, take on some of the responsibilities of motivating other developers and maintaining team cohesion.

Even if you don't want to take on management tasks, you can still make your manager's life easier by doing little things like getting your status reports in on time, prioritizing your own work, showing up for meetings (and paying attention), working out differences with other team members on your own, etc. Don't make your manager spend time reminding you to do things you've already been asked to do, or addressing trivial problems that you can fix yourself. In short: don't be un-manageable.

Off-load some of your workload

Don't be afraid to reverse delegate certain tasks back to your manager, especially if you are under tight schedule constraints. For example, if your manager decides to add a fancy user manual to the scheduled release, propose that she draft the outline and main points, and you'll provide the missing technical details as time permits. This practice helps your manager stay involved in the work you're doing, helps your manager feel productive (many managers feel detached, having been developers in the "good old days"), and helps educate your manager about the impact of things added late to project deliverables. But in general, it's also a way to have fun by seeing how much direction your manager will take from you. Remember to play nice.

Remember that managers are people too.

Managers make mistakes. Managers get tired. Managers sometimes collapse under pressure. Managers sometimes get irritable or angry without good reason. Managers sometimes get distracted by personal problems. Don't hold managers to an incredibly high standard just because they make more money, have an impressive title, or have the authority to fire you. They are just people, trying to do their jobs the best they can, learning by trial-and-error, hoping to make their house payments and raise their kids and have a little fun once in a while.

You may even find out that you like them, if you take some time to talk to them or to share a pitcher of beer with them.

If your manager is doing a good job, let the manager know. Managers usually hear nothing but complaints. They like compliments and positive feedback just like anyone else. But it may be difficult to do this in a way that doesn't seem like you are sucking up, so don't force it if it is unnatural, and don't give false compliments.

Don't take it out on your manager if the company freezes salaries, cuts benefits, or institutes draconian policies. If your manager is not a CEO, president, or vice-president, then your manager probably has no influence and is suffering just like you are.

And remember that your manager has a manager too, who is probably a whole lot tougher. Being held accountable for the quality and speed of other people's work is a very stressful position.

Comments:

Excellent page. I was a developer for 10 years, and have been managing a SW group for 6 months now. Every point above resonates with me. I was a developer and can relate with developers, but the view from my current position is different. I am more stressed, for sure. I have many more things on my plate, even if each item is smaller. (Many deadlines per day, instead of one deadline per week or weeks.) I am learning how to deal with the new demands, but I am sure I am making mistakes. The transition has been easier in that I worked in the group I now manage for 6 years, and because I have really good people working for me.

Having just come off a two-year management stint myself, I am amazed at how patient my former managers were with me, and how easy they made it look. --KrisJohnson

What about the other way? How can a manager help you? See GoodItManager, and add something -- PaulHudson (a manager interested in the answers)

Ok, ignoring the occasional case where the manager (due to nepotism, fluke, whatever) actually *is* a clueless moron, I still find this problem often initiates the other way round. If you are an IT manager in the sort of shops I have worked in, you are probably not as bright nor as well educated as several of your team. If you insist on believing otherwise, and pushing ill-conceived ideas on people who understand the problem better than you do (which has been my experience with two *poor* managers I have had), you create an antagonistic relationship. If a manager doesn't actively show respect for the developers, they are unlikely to get much in return. In a perfect world, nobody would have to work at this, but in the real world... well, team building is part of a managers job, it's often not thought of as part of a developers job, and practical management has to account for this.

The point of this page is that developers can take some initiative, rather than putting all the responsibility on the manager or taking an us-vs.-them approach. Team-building is everyone's responsibility. I've found that being open and honest with a manager, even a bad one, builds trust that smoothes thing over whenever serious problems come up. --KrisJohnson

CategoryManagement