‘Shouldn’t you endeavor to work with the type of people who are good enough at their jobs that they can make sensible decisions about what they’re doing?’
In an ideal world yes. In economic reality NO.
Fact remains, some people are very useful coders but utterly hopeless as developers or analysts. These people will always need close management (or micro-management if you prefer).
Quite a few of the more talented developers have limited people skills and prefer to be left to get on with whatever they are doing. They are not capable of pushing their less talented coworkers. Again, the manager needs to step in to make sure they share their knowledge and motivate the others.
My point is, no team consists of stars only. And in my eyes, a good IT manager is someone all of your team can talk to, the ‘automatons’ and the ‘high-flyers’. Therefore a good manager has to have a good technical background and people skills and fairly intimate knowledge of the projects and where they are at any point in time.
The lesser talented people do a lot of the ‘fetch and carry’ work for less money so you can have a number of star players, and still get the job done. And that is a fact of life and economics.
Interesting aspect. This a bit like our coding guidelines. Different coders here have different ideas how good code should look like - we gave up on creating guidelines telling people how to code. Instead we switched to guidelines on how not to code. It is easier to pick negative than positive examples and it is easier showing people a piece of bad code and explaining them why it is bad (what issues it does or might cause), and they’ll understand it and they’ll avoid it. It’s harder to show them a piece of code and explain them why it must be done that way, since you’ll get replies like Yes, but when I do it not like that, but like that, the problem won’t occur either, will it? and it’s a waste of time to argue about that. It’s a waste of time to argue what is the best way to avoid a problem, it’s more important to identify problems and just agree upon avoiding them.
Steven Covey talks about the differences of gofer delegation and stewardship delegation in his book 7 Habits of Highly Effective people. By giving people the freedom of being able to tackle a problem how they seem fit you are building up trust between that person.
I recommend this book to anyone who hasn’t read it.
It then links into moving from a transactional leadership approach to a transformational leadership approach. This is kind of a why give a person a fish, when you can teach them how to fish approach.
And if you are into efficient time management… Micro managing is a renown time wasting exercise where as developing someone to a point where you are happy for them to make their own decisions is a definite ‘Quadrant 2’ exercise (That’s good).
Especially bad when your manager is not a programmer and you are. Even trying to explain why something is difficult or why time estimates are so hard is a challenge.
yeah i think this is a big problem. as far as i’m concerned if you don’t play in the poo you shouldn’t get a say in how the poo pies are made. you get a choice of flavour and how they look but you should be very hands off about how they are made. there is a big risk that management will dictate how things are done while ignoring all the private knowledge contained in the heads of the people who actually work on the system. i think the main advantage of agile is it tries to harness this knowledge.
you are assuming that:
1- you’re working with top-skilled employees.
2- perfect company infrastructure, there is always enough people and technology to complete the tasks.
3- your developers won’t be called by marketing people because their email accounts don’t work or their computers crashed. other managers won’t try to STEAL your developers because they need help on other projects.
4- managers are not developers who were upgraded.
5- managers don’t have bosses who set the deadlines on a ridiculous schedule.
It’s never like that. if one of these fails and you try to manage a project on a high level without micromanagement: your project failed.
So what do you do? you cope with it. You generate micromanagement when it’s necessary, and try to leave the employees to make decisions on a safe ground, a ground that will eventually grow when they make good decisions and shrink when they make bad ones.
As a manager who has had to mentor entire teams of new programmers just out of school …
1-5 only apply once you are comfortable with your employees skills. Up until that point, exercising 1-5 studiously while still allowing your programmers to screw up is the only way to balance your programming teams growth with the necessity of shipping a product.
I lead a team who have demonstrated time and again that they simply cannot be entrusted to make decisions for themselves, right or wrong. Its not that they make wrong decisions all the time, they just dont make any decisions at all.
In spite of repeated emphasis on empowerment, trust, and judgment, more often than not they simply sit around waiting for their next directive. One person on my team is notorious for doing this, and he was in the military.
They simply don’t communicate. So I have to communicate for them. The bottom line is if they are not told what to do they will not do anything. It has created a lot of acrimony in our office.
Bad personnel? Probably, but the problem is further exacerbated by the lack of talent in my immediate area.
Lousy situation all around. But I guess what I’m saying is there are those too who are zombies and like it - if anything because it means they are relieved of certain responsibilities.
Think of Captain Picard. He never sat over Data’s shoulder telling him what buttons to press. He trusted his crew to do their damn job… Otherwise the show would be named
Star Trek: Picard’s Uber Micro
It would also end with the captain getting shot because he would be on the planets with the away team asking for status reports nonestop. That and probly mutany after a few days out.
So managers remember: WWCPD?
However don’t rely on the Scotty Principal also seen on TNG.
It’s easy to talk about what’s bad about micromanaging. What’s much harder, and would be more valuable, would be to talk about how to work with developing talent so that they become the sort of people who can handle responsibilities. We just don’t come that way out of the box, and we’re always learning. How do we help someone develop without micromanaging them, letting them fail a little, without letting them sink the whole ship?
The problem with managers who aren’t technically astute is that they are easily flummoxed by vendors, magazine articles, bloggers, and dumb ass coders. Which is not to say that micro-managing is the answer, but that managers of technical staff had best know more about the tech stuff than anybody.
It is, after all, the MBAs who destroyed the banking, auto, and most every other industry that used to exist in the USofA.
Jeff – I say this as kindly as possible (really – no insult intended), but have you ever worked for a large company? One with entrenched rules and bureaucracy?
Let me give you an example:
Today, at about 04:00 or so I had to wake a senior director. One of our processes had died and I needed to get at certain of the files it produced so that I could get them to the developer for analysis. I logged on to the Unix host only to find that I did not have the appropriate rights to the files (how the hell I’m supposed to support the app with no access is a question best left to the auditors).
OK. Call our 24x7 support line. They don’t have the authority either. Got the on-call AIX support guy. Yes, he could do it, but it might violate segregation of duties rules (SOD). Mind you, this particular failure is holding up a highly critical end-of-month/quarter/year financial close process. Had to get his manager’s boss on the horn to approve moving 10 files to a /tmp directory so that I in turn could get them to the developer. Wasted somewhere in the vicinity of 45-60 minutes trying to track down all the bodies and get all the tickets approved to document this. All the while everyone along the way was looking nervously over their shoulder to see if this action would trigger audit and/or security alerts that we’d then have to spend time justifying later.
This is a typical occurrence, and, frankly, not even one of the more involved cases. I’m sorry to say that it seems like you just don’t grok what most of use deal with day in and day out.
Again, I do not say this to insult you or to be combative, but I do say it with more than a hint of sadness and despair.
Managers often take offense to comments like these.
I think the ‘manager’ title should be buried. Managers drink coolaid and immediately get bad ideas about their omnipotence. Call them a coordinator, organizer or something like that. Just do away with the twisted values that people link to managers and we have a better start. Also, take away the authority aspect, and just designate areas or responsibility and get rid of the hierarchical command and control approach.
Some hierarchies must still exist but organizations could be a whole lot flatter.
Just be careful to suggest that to your manager or your ass might be toast.
