What Makes a Good Manager? What Makes a Bad One? IT Types, This Means You!

Folks, I have a chance to become IT Manager in a few months. Now, my background is in translation and programming, so I’ve never been a manager, although I have headed teams. I’ve certainly got no formal training in being a manager; on the other hand, my immediate supervisor for the past 18 months has not been the best I’ve had. If I decide to take this on, I’d like to be a good manager. I’ve certainly suffered enough under bad ones. :rolleyes:

Here are my questions to the Teeming Millions:[ul]
[li]What makes a good manager?[/li][li]What makes a bad manager?[/li][li]What have managers done that you’re glad they did?[/li][li]What have managers done that you hated?[/li][li]Can you recommend any books on the subject?[/li][li]Have you got any other advice?[/li][/ul]

This is a challenge which I never dreamt I’d face, but I’m looking forward to it. Maybe it’s about time this techie grew up a bit. On the other hand, please don’t tell me this means I’m getting respectable! :eek:

CJ

The #1 rule for managers IMO is “The manager is there to make the employees job easier, not the other way around.” A good manager is a facilitator - he’s the guy (or woman) who makes it possible for the workerbees to clear their desks and do their WORK.

Before you put any policies in place, ask yourself this - “Does this make it easier or harder for my employees to do their primary job tasks?” If the answer is “harder” then explore ways that you yourself can do whatever the policy is trying to accomplish. Case in point: status meetings. There’s no need for ten people to sit in a room for an hour so each of them can give their status updates to you, the manager. Instead, go around to each employee every Monday morning (or whenever) and GET the status from each of them. Let the rest of them work. If something comes up that involves a few employees, set up a meeting for those few who are involved. There’s no reason that the other 10 employees have to sit there while 3 of them work out an issue.

Other traits of some of the best managers I’ve had:

  • He or she was the last person to leave the office during “push” times. If one or two employees are working late to get something important done, by all means their manager should be there. Even if it’s just to order in some food or do some QA or research for them, it’s worth it. It sucks to have to work overtime; it sucks even more to work overtime when your higher-paid manager is at home relaxing.

  • Approachable. As a manager, you work on interrupt. Your door should be open as much as possible, and communication with your employees should be your number one priority.

  • If you have a problem with an employee, talk to them about it BEFORE it gets to be a big issue. For example, if someone is habitually coming in late, ask them about it. Often a gentle push is enough to solve a problem - “Gee, Marg, you’ve been coming in late lately. That’s not like you. Is everything all right?” gets across the idea that lateness is an issue and gives the employee a chance to correct it before it escalates.

  • ASK your employees what you can do to help them do their job. Going to bat for them on issues they may have is your job. George having problems because payroll is getting his deductions wrong? Give payroll a call yourself and make sure they know it’s an issue.

Here’s some BAD manager traits:

  • At review time, get your shit together. I’ll never forget the manager who told me I was getting a shitty raise because of a metric that was supposedly WAY lower than all my peers. The metric was easily checked - I checked, and the number my manager told me was WAY off. I was actually doing MORE work than several of my coworkers. I’m still pissed to this day that the manager in question couldn’t be troubled to run a script that took 30 seconds to double check his numbers before he decided to screw me on my raise.

  • Don’t assume you’re smarter than your employees. You’re there to MANAGE, not to come up with solutions. Not that you don’t have any input, but in a lot of cases the people closest to the problems (ie, the workerbees) are the experts. Let them do their job.

  • Don’t be an asshole. This should come without saying, but I’ve seen a lot of managers who don’t seem to get it that being a human and working with people is better than shouting obscenities or threatening people.

Athena made some great points. I only have two to add:

Listen. If they come to you with a question or a complaint, just hear them out. Don’t assume.

Try to get them involved in the decision-making process whenever possible. Then when you have to pass down decisions that they can’t change, they feel better about it because they know you would have let them at least talk about it.

Triple-think every new rule and guideline you put in place for your underlings. You will create much dissent and bad mojo if you expect others to follow rules that you yourself do not.

You will be the cause of much grumbling and frustration if you change rules after a few months because the ramifications of said rules were not thought out before they were implemented.

Listen to suggestions. I’m not saying necessarily implement them, just listen to them.

Give credit where credit is due.

Document, document, document.

You said you’ve worked under some real winners in the past - use that to your advantage. Sit down and think about every single time your managers ever pissed you off. Why? How would you have handled the situation instead, if you were in their shoes?

Fear not for your lack of managerial experience. You have scads of IT experience, so you know the type of jobs you’ll be overseeing - which IMO gives you a much better head start at running a smooth and happy IT division. From what I’ve experienced, a managerial degree isn’t worth squat if the manager doesn’t know/care the responsibilities and pressures of his staff.
Just one techie chick’s opinion on working for The Man. Congrats, BTW! Good for you on movin’ on up in the world! (Or at least the workplace…)
…and on preview, I see I’m repeating some suggestions from others. Oh well, I guess that means they’re important points to ponder…

Whenever there is a problem, work first on solving it. Finding blame and throwing shit should only be done after the problem is solved, if you still feel like it.

People who never admit they are to blame and always find a way to blame everything on someone else are not management material.

Good points in the above posts!

I would add, as a side-note, that taking these actions with your employees are going to really pay off, even if occasionally it is difficult. If you go to bat for your employees you will be amazed to see how much loyalty they will give you in return.

A lot of managers tend to ‘screw’ over their employees because they are more concerned with keeping favor with those above them. What they don’t realize is that if your employees are treated well they will be loyal enough make you look good all on their own. They will see their sucess is tied to yours.

As an IT employee one of the things I have always had a problem with is defining the amount of creativity I am allowed. Before you assign a job to someone, especially if they are new on the job, have another employee help or have the standards for the job given to him. Knowing limits will always help anyone to do their job.

Instance: I was given an intranet web programming job to do and was told I should make it not only dynamic but to be very creative. So every time I tred to retrieve information or put up active graphics, the networking department would come back weeks after it was done and tell me to get rid of it. It made for a very frustrating job. There was not much in the way of definitions and what the other branches of the company were using wasn’t necessarily our standards. So I was constantly trying to figure how to manage the site. I was so relieved when it was done and I was on my way. Managed to do it using no creativity at all. It will probably still be there ten years from now with only the direct links updated. That is, if they continue to use the same documents.

AND as we all know. When someone is doing a good job, let them know it. This goes along way in my book. I would rather work for someone who understands this need and goes out of his way to appreciate the fact that I wrote part of this program at home for no pay. Than someone who couldn’t care less how I got the job done as long as it suited him.

Well I’ve been in the techonolgy and management consulting field for about several years…so my answer is ‘I have no idea’.
Seriously, though, as a manager you will find that your focus is going to shift from an internal one to a much more external focus. You job is to get stuff done. It is to make sure your team has all the tools and information they need to complete their job. That means a lot of dealing with other teams and managers. Other than the technical aspects of project management (Gantt charts, process flows, scope documents, statements of work, etc) your job will also be to manage the people and their egos.
I would second the ‘document everything’. It’s good to have a written record of everything, if for no other reason, it helps keeps your team on the same page. If you just give instructions orally, sometimes things can get missed. I don’t remember how many times some manager has come to me with “you might remember when I said xyz…” No…I don’t remember that particular sentence that came out of the eight hour team meeting last week (oh yeah…keep meetings short and to the point…don’t let them turn into rambling bitch sessions).

Oh and don’t be afraid to be an asshole sometimes. Treat people with respect but don’t worry that they won’t like you if you ask them to do something unpleasent.
Some standard MBA management fare:
Built to Last

Good to Great

The First-Time Manager

The McKinsey Way

The Marine Corp Way: Using Menuever Warfare to Lead a Winning Organization

I’ll add a few:

  1. Don’t undermine your superiors in front of your people. If your boss makes a decision you don’t agree with, tell her so, but if she sticks to it, champion the decision before your people as if you agree with it. (I’m assuming it’s not something that’s illegal.) If you bitch about your boss to your employees they’ll think you’re a weasel, and they’ll bitch about you.

  2. If it’s not written down, it never happened. It was said already, but it’s worth saying again. Write EVERYTHING down. Never use the phone when E-mail will do.

  3. Prioritize, prioritize, prioritize. There isn’t enough time to do it all.

  4. Be positive. Smile a lot. Laugh. If you seem like a happy and friendly person people will tell you more.

  5. I have worked in an office for years and years and I have never in my life seen a situation that merited raising my voice.

  6. If people dont have clear, written objectives, you are not doing your job.

I’ll second that. I’ve definitely been in jobs where I had no fookin’ clue what my boss wanted from me. Not surprising in retrospect that I didn’t particularly excel in that job. Guessing what your boss wants is not fun, nor is it productive.

I would like to reemphasize this as very important. Managing your team is your job, not making allies with other managers. When the shit hits the fan someone takes it in the face. If your team isn’t at fault, don’t take the blame. Stand up for your guys, and defend them(it should go without saying that you should know them well enough to know whether you can defend them) Taking one for the team may make you feel big and noble in the bosses meeting room, but your actual team will find out about it and never forgive you as the question mark always hangs over thier heads.

Thanks for asking.

First and foremost, we’re not all alike. Some of us are methodical and detail-oriented; some of us are task-focused and work best if someone else studies integration into the whole; and some of us are hackers raw and simple and make functions happen in base form (and then call you over to show you) and then add polish and details and prefer to debug specifics in response to live bug reports.

I’m good at what I do, and damn fast, jaw-droppingly fast, in my ability to hack out a rendition of what you describe to me as “what you want”. Nine times out of ten I can do it while you’re sitting there describing it to me, edits on the live project, works right now, like that?

Work with my strengths. Respect them, don’t abuse them. Spend a little bit of time thinking through what you want and whether or not having it that way will have repercussions on other things that are either in place or are things you’ll want down the line. I really hate ripping out stuff that works that you requested to be this way, even though I’m fast and can do it, because by now there’s legacy data in the system I’ve got to accomodate, and if you layer change request upon change request that affects the same damn data I’ve got an ugly klunky nightmare of backwards-compatibility to deal with.

If it isn’t me you’re working with, work with the strengths of the person you’ve got. Don’t wrestle with them: if you’ve got a cautious but exquisitely thorough person, don’t scream at them for changes more rapid than they are comfortable making, 'cause when they say they are done the system works and every t is crossed and every i is dotted and it’s all documented and you should praise God or Og or the Great Chip in the Sky;

if you’ve got a hacker like me, by all means come to me and ask me to show you what it would be like if such-and-such were the way things worked, but don’t tell me to roll it out live and then come back to me a week later and ask for changes that’re going to screw up what I just put into place — i.e. if you don’t know for sure and you’re just thinking this would be good, don’t bullshit me and say it’s how it’s gonna be. I’ll’ve built a dozen things on that assumption by the time you reverse course out from under me and it pisses me off. Oh, and don’t begrudge me implementation bugs. Most of my stuff works, but my strength is rapid app dev and I whack out stuff that basically works in hours, not days, and yes sometimes other stuff breaks. Report it, I fix it (also fast). Don’t treat it like a personal insufficiency. You could’ve hired one of those exquisitely thorough folks instead, but you’ve got me. Work with the strengths of the person you’ve got. I’m fast. Damn fast. I get it right the first time 91% of the time and I edit live systems while users are still in them. Tell me about bugs, don’t harass me about them; I can fix them in less time than it takes for you to report them to me; oh, and goddammit, don’t bug me about the ugliness of the fuckin’ graphical user interface when I’m showing you that a process does indeed work. Damn, we’ll slap some pretty on it later, don’t you understand that 3D shading and wider fields and better fonts is NOT something I wanna hear when I’m showing off successful functionality?

If you’ve got what I call a “focus person”, in many ways you’ve got the best of both worlds. You’ve got someone whose output is often going to be more polished than mine would be, developed more quickly than the t-crosser who is perfect but plods along more slowly —but the end result may need to be tested for integration into the whole, and the focus person’s screwups, such as they exist, may be in the interfaces and intestices where this new module meets up with other stuff. Focus people often work well in teams with a project admin who integrates stuff, but only if they are given suitable credit and accorded authority for the subproject that’s been assigned to them, and not chastised for not being better at “big picture integration” or being faster at rapid dev.

And some minor shit:

•I don’t do ties and suits and stuff. I am willing to own a set and wear it on special occasions if the CEO of the parent company wants to see the stuff and you want me to demo it. Otherwise, lose the dress-code shit or lose me. I’ll take a 15% pay cut to escape this kind of bullshit and I’m not alone.

• I hate meetings where we sit around and blab about what we did this week, or put the public spotlight on someone whose work isn’t going as desired. Do this shot mano a mano, not in meetings. Don’t waste my time. I’ll move on to a job not paying any better than this one just to escape stupid freakin’ meetings.

• Don’t even think of restricting what I can do on my computer unless it ties up your bandwidth. I get lunch breaks and I get downtime and there are times when I do my best cogitation of how best to implement your requests while browsing the Straight Dope or Timbuktu’ing a file from the girlfriend’s computer at home. Not your business. Don’t tie me down. If you’ve got a firewall, I want the key to get beyond it. If you don’t trust me not to bollix up your network, fire me. And don’t ever, ever, harass me for how I’ve spent my time. You’ve never ever waited for more than a week, rarely more than 2 days, between a request and an implementation, so don’t act like this is a time-clock kind of activity.

•I will ask for toys sometimes. If you can buy them for me (software or hardware), thanks. I will, at other times, tell you I need something, or that we need something. I will make the distinction. In the latter case, buy the suckers. I won’t ever disguise a “toy requisition” as a necessity. If you balk at equipping the place with what I say we need, I’ll recommunicate more emphatically, then if you stil don’t get it I’m out of here.

Does management want you there as a leader or as an administrator? If management only wants you to prepare a budget (and punish you for going over after you did what they told you to do) then you have a different job than a person who is also expected to look for the problems and opportunities in the upcoming years.

Technology keeps changing, so you need to know how it will affect your department. New software (or upgrades)? When should you be on the bleeding edge and when should you let other people die the death of a thousand (paper) cuts while you accomplish your primary job with stable software? These are the decisions of the leader–and if management will not support leadership decisions, you need to know how to cope with that. Getting your people trained to handle upcoming changes is another fight that the leader must tackle with upper management.

Most of the issues with your employees have been addressed, above, but you also need to remember to let your employees make mistakes. Discipline is appropriate for goof-offs and for people who have disobeyed a direct order and brought a project down in flames. However, it is also important to let them see the results of bad decisions by having to recover from them. (This is difficult because their errors reflect on you and because you have a fiduciary responsibility to the company to prevent waste or negligent loss. However, if the corporate loss will not be excessive, letting someone screw up (especially when they have been warned and you can review the project for the bad decisions, later) can be an invaluable teaching tool. The important part is the follow-up in which the Why of the error (not of their mistake, but the reason that path was incorrect) is laid out and dissected without covering the staff in blame.)

Beyond that, I am a big advocate of playing to people’s strengths and not treating everyone at the same grade position as if they were interchangeable. The frantic coder and the staid documentarian each have a legitimate place on the staff and telling the mad coder to slug his way through a bureaucratic nightmare will send him screaming into the night (or another job) while putting the methodical plodder on a job that was due last week will cause you to grow ulcers in places that the medical community did not realize they could grow.

The other aspect of management is managing the change. It is wonderful to implement new software that should make everyones’ lives easier, but a reluctant user staff can kill the finest software. Make sure that the users have “bought” the reason for the change and are not sitting back waiting to sabotage the project. (And impress on your staff that they are there to make the users’ lives easier, not to write wonderful flights of code.)