Good It Manager

There's plenty on the Wiki that discusses what a bad manager can be like.

Please add your comments here on what makes a good manager (roles, functions, skills, experience, capabilities, traits etc), preferably recognizing the multiple roles of

making a positive contribution to the people he or she manages,
making a positive contribution to his or her management (this includes being accountable for the output/outcome of the uses of the resources (people as well as financial etc) that he or she is responsible for).

Mintzberg looked at what managers actually do, and showed that the majority of time is spent communicating. He also identified the following roles:

Interpersonal: figurehead; leader; liaison
Informational: monitor; disseminator; spokesperson
Decisional: entrepreneur; disturbance handler; resource allocator; negotiator

Are all these relevant for IT management? (I'd say yes)

Good IT Managers should lead by example - motivate their team (Team Building sessions are always good) - be assertive without aggression - Be able to put their foot down when necessary - Empathize with their team - Validate their team - Communicate with their team.

Most importantly, it takes courage for an experienced programmer to make the transition to management.

I did so a couple of years ago, after happily programming for over a decade. Management wasn't something I aspired to, or even had any desire to attempt. As many contributors here do, I found myself frequently criticizing management and management decisions. Implicit in this criticism was that I could do better.

Now, the way I see it, I had 4 choices:

Quit and find someplace else to work with a GoodItManager.
Continue to criticize, complain, and assume superiority.
Quit complaining and just deal with it.
Be courageous and step up to the plate. Take responsibility for making things better. IOW become part of management.

Perhaps if more programmers would be courageous, the ItManager would become a respected position. I know, I know, most programmers don't have good management or interpersonal skills. If you're one of those, then I'd advise option 3, just shut up and deal with it. -- KenMcKelvey

Agreed. Having been both a developer and a manager, I now have little sympathy for all the anti-management whining and moaning typical of developers. Many developers see a manager as a surrogate parent or fairy godmother who is supposed to make all one's dreams come true, and then complain when the manager doesn't fulfill that role, Managers are always looking for good ideas, and are willing to implement the ones that make sense. Developers' unhappiness often comes from an unwillingness to assert themselves and take responsibility. -- KrisJohnson

Same here. I've been dragging my feet for over 10 years, and finally accepted an informal (no extra pay) team lead role. I don't particularly enjoy it, and am not especially good at it, but somebody has to do it, and I've gotten to the point where I can't handle working for an idiot or an asshole, so I'll do it myself (sort of like I am my own lessor of many evils). I have been inspired by several good managers who were good at blocking the bullshit and letting me get on with the software, and so I figure I have to pull the bullshit blocking duty every once in the while...

There are actually some shades of grey between the above four options, or maybe it is a fifth option: manage up. The idea is to think about the bigger, ugly picture that managers have to deal with (instead of the more limited, technically "pure" level most developers prefer to focus on), and anticipate the problems, choices, decisions, and so on that your boss is grappling with, and offer them advice, estimates, succinct summaries, alternatives, references (web links), etc. to help them make good decisions. This will, in many cases, make your own life easier too, by avoiding "bozo" decisions up front, and giving you a voice in the whole process. See HelpYourManager.

I think this is what techies should expect from a good IT manager:

Techies have control over technical decisions.
Techies make estimates, and managers either accept those estimates, reduce the scope-of-work, or get the task broken down into smaller tasks that can be re-estimated and evaluated individually.
Managers should keep techies informed of decisions made and non-technical issues that come up.
Techies should not be asked to work more than forty hours a week for extended periods of time, and should be allowed to take their vacations whenever they want (within reason).
Techies should be given books, training, and paid time at work to improve their skills.
Managers should be very patient when techies are using new technologies or making drastic changes to IT infrastructure.
As needs increase, managers should hire more people, rather than pushing more responsibilities onto the existing people.
Spread assignments around, so that everyone gets a chance to learn and so that no one person becomes indispensable.

-- KrisJohnson

Kris, I have a problem with your list :)

If you set up a culture where techies feel that they have _Control_ over technical decisions, this can become a problem when business decisions overrule technical interests - I feel that it is better to promote that Techies are a major source in technical discussions, with the manager / team lead as an arbiter in the discussion.

I agree with Kris's sentiment, although I think "control" is the wrong word. My view is that people who are designated as "technical" on a project are responsible for "recommending" technical solutions. However (and this is important) they are also responsible for telling the manager (and customer) about the implications of that recommendation being overruled (for any reason, including business decisions). If the business insists on some other approach being adopted, then the techie has to come up with a solution that fits, even if they don't like it. As long as they communicated the implications, the decision is taken with full knowledge by the manager or customer.

Another difficulty with this whole manager / techie relationship comes when the manager used to be (or still is, in other scenarios) a technically competent individual. A key skill of a good project manager is to recognize that their role is to manage (and leave the technical stuff to the techie roleplayers). Project Management is a fulltime job. A manager who gets heavily involved in the technical stuff is probably, by definition, neglecting something in their management responsibilities. It's hard to trust the techies to get on with their work when you think you could do better. -- MattStephenson?

If you explain every decision, which is what often happens when you inform teams of every decision, you eventually don't have any time left for making decisions :)

I think Techies need to trust their managers more.

The best relationships I have seen between Techies & Managers are when the Manager is considered to be part of the team. Problems are then solved & decided by members of that team, and everyone trusts that the individuals are making decisions for the good of the team. This seemed to result in not needing to discuss every decision. Possibly because if anyone in the team had to make a decision they were unsure of, they would discuss it.

Maybe my problem with the list is that its has an UsAndThem / BillOfRights feel.

-- SvenDowideit

I agree that an us-vs.-them mindset is bad, and that it is best when the techies and managers see one another as part of the same team. The format of the list is really to answer a question posed at the bottom of the HelpYourManager topic: How can a manager help the team? I would agree that "control" is probably the wrong word; business needs are always top priority. But I do think that keeping the techies informed of business decisions is important. Managers keeping techies in the dark is just as bad as techies keeping managers in the dark. "Trust us, we know what we're doing" doesn't inspire confidence on either side. -- kj

ahhhhh

then my version of the list would start with

Actively join the team
Give strong guidance & feedback (so that Empowerment happens)
Support & encourage Mentoring
Be the project's Coach
Learn to delegate effectively

-- SvenDowideit

I would strongly agree with point three. I think the best 'managers' I've ever worked under (and would do so again) have been good mentors. They were willing to work with the team, listen to opinions and make strong decisions when needed, but not without at least pretending to listen to the team input. Basically, they were good team builders. Building good, motivated, competent teams is hard; it only takes a few days to completely destroy morale.

From my own experience, management leadership seems to fall into two camps:

Leadership via mentoring (line management)
Leadership via creating monstrous Gantt charts (project management))

-- ChadThompson

See also ManagementRoles

Whomever refactored this to add the project vs line manager: thank you. It provided for some interesting reading. Maybe it gets more to the point: in many situation that I have been in, there has not been a separation of "different types" of management. It seems that there is only "the team lead"; likely not the best approach to any form of management. -- ChadThompson

GoodItManagers do not last

end 2004Note: I think last significant edit of this page was over 1.5 yrs ago, based on my search in WayBackMachine?

does it mean there is nothing to revisit/enhance/refactor, etc?
or have people with interests on this topic all moved out due to WikiNoisePollution?

Discussions on this page have not yet considered the views of the most important people, in deciding who is or is not a GoodItManager. Suggest people to search for articles like "what to look for in hiring your next ItManager", and post good links here -- dl

should be a good ProjectManager for the project of StrategicAlignmentOfItProductsAndServices
skilled in applying SocialDynamics to achieving results

Top of my list are the following 3:

Since IT stands for Information Technology, a GoodItManager should have both a fundamental understanding of the technology stack used within the company. This may sound improbable, but it isn't in my experience. I know more than one IT Manager who's only background is COBOL, yet they are resposible for managing a J2EE or .Net shop. The GoodItManager recognizes that they, at least, need to keep up to speed with what is going on in the industry. The BadItManager? says "I'm a manager, not a techie, so I don't need to know about it."
Recognizes that technology is changing rapidly, and accepts it. I have actually seen one IT manager request a system be built that "would never change". The reason was that change costs money, and "the system didn't change much before".
Is forward thinking. IT Managers should be reading periodicals, surfing the net and keeping a handle on how their environment may change in the next 5 years.

I think that you all have very good points and it is hard to be a good IT manager. I think that a lot of the time techies like to work beyond their bounds and make decision about issues that involve them but where they are not accountable. I find that everyone who has information about the issue wants in on the decision. This is problematic because not everyone can be given equal accountability, and decision making without accountability is dangerous. Those making decisions without accountability can become risk prone while those with accountability for decisions made by many others refuse to act. I find that happens quite frequently in the environments that I have working in as a techie and a manager. - Norvan Vogt

You know your manager is a GoodItManager when you think he actually does nothing (because he's not in your back), AND you don't have his own manager in your back, AND you don't have a lot of administrative paperwork to do instead of concentrating on your technical tasks. A manager is supposed to manage, and when this is done efficiently, this is just invisible. Mine is like that, so yes they exist :) -- PhilippeDetournay

I would disagree. If a manager just leaves his team alone, then he is not leading his team. If the manager is not pushing team members into new directions, the manager is letting his team stagnate. If the team is not doing the administrative paperwork, then it means the manager is doing it instead; this is a failure to delegate undesireable tasks. Remember, if the manager is not directly involved with your team, he is probably acting the same way towards upper management and not fighting for new opportunities for your team. The good manager is actively selling the capabilities of his team upperward and pushing downward to move his team out of its comfort zone.

Well, new opportunities are not to be fought for. The team works on the same product for more than ten years, and this is a constant challenge just to keep it in line with the customer's expectations. The fact is that I can work with low pressure, which makes me happy and allows me to do a good job, which in turn makes the customer happy (well I hope so). On an other hand, I didn't say the manager was leaving his team alone...

How has the product and the team advanced over the years? What product improvements have been suggested by the development team to the customer? What changes have been made to team processes? What new skills are team members learning? These are the responsibilities of a good manager.