programming and human factors
by Jeff Atwood
Do you manage other programmers, in any capacity? Then take Kathy Sierra's quiz:
A "yes" to any of these -- even a half-hearted "maybe" -- means you might be creating Micromanagement Zombies.
That's right, Zombies. Mindless automatons who can barely do anything except exactly what they are ordered to do, and even then, only when someone is strictly monitoring what they're doing and how they're doing it. Micromanaging the people you work with is arguably the exact opposite of what a competent team leader or manager should be spending their time doing. So if you're micromanaging at all, even the teeny tiniest little bit, step back and take a long, hard look. It's a sign of deeper problems.
Beyond that, who the heck wants to work with zombies anyway? 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? And they're not constantly trying to eat your brain? Well, figuratively speaking.
Building teams is like building software. It's easier to describe what not to do than it is to identify the intangibles that make good software development teams jell. But it's pretty clear that micromanagement is one of the biggest risks. In Peopleware, DeMarco and Lister establish seven anti-patterns they dubbed Teamicide:
Wondering what number one encompasses? You guessed it: micromanagement.
If you're the manager, of course you're going to feel that your judgment is better than that of people under you. You have more experience and perhaps a higher standard of excellence than they have; that's how you got to be the manager. At any point in the project where you don't interpose your own judgment, your people are more likely to make a mistake. So what? Let them make some mistakes. That doesn't mean you can't override a decision (very occasionally) or give specific direction to the project. But if the staff comes to believe it's not allowed to make any errors of its own, the message that you don't trust them comes through loud and clear. There is no message you can send that will better inhibit team formation.Most managers give themselves excellent grades on knowing when to trust their people and when not to. But in our experience, too many managers err on the side of mistrust. They follow the basic premise that their people may operate completely autonomously, as long as they operate correctly. This amounts to no autonomy at all. The only freedom that has any meaning is the freedom to proceed differently from the way your manager would have proceeded. This is true in a broader sense, too: The right to be right (in your manager's eyes or in your government's eyes) is irrelevant; it's only the right to be wrong that makes you free.
The most obvious defensive management ploys are prescriptive Methodologies ("My people are too dumb to build systems without them") and technical interference by the manager. Both are doomed to fail in the long run. In addition, they make for efficient teamicide. People who feel untrusted have little inclination to bond together into a cooperative team.
In the end, isn't trust what this is about? If you don't trust the people you work with -- and most importantly, actively demonstrate that trust through your actions -- should you really be working with them at all?
Yeah, nothing like having 40 developers under a single know-nothing manager there just to babysit. No career paths, no incentives, and nobody accountable except to a time tracking automaton. I just sarcasmlove/sarcasm the MBA way of running things.
sheesh on January 5, 2009 1:00 AMInstitute leadership. The aim of supervision should be to help people and machines and gadgets to do a better job. (Deming, 1993). One of W. E. Deming's, 14 princples for management.
I have seen, in my previous workplaces, managers who if they could get just get their heads around that one princple; the whole department would be so much more productive, better staff retention, etc.
I fully recommend reading about the rest of Demming's princples for management (as well as about Deming and his work. Japan would probably not be the industrial giant that it is today, if it was not for Deming and his contempory Juran)
[linkage] http://en.wikipedia.org/wiki/W._Edwards_Deming#Deming.27s_14_points
My experience as a manager of eight developers on a tightly timebound project:
Do you pride yourself on being on top of the projects or your
direct reports? Do you have a solid grasp of the details of every
project?
I wouldn't say pride myself. More like consider it part of the job. If I don't understand the details, I can't help my developers.
Do you believe that you could perform most of the tasks of your
direct reports, and potentially do a better job?
I've never asked someone to do something that I couldn't do. I'm certain that there were things that I could do a better job on than my reports (I called them developers) could, at least until I trained them and they got up to speed.
For instance, nobody on the team knew XSLT or AJAX before we started the project. (This was in 2000, before AJAX was called AJAX.) Part of my job was building and explaining prototypes using these new technologies. My guys were really smart - I doubt there was one of them who couldn't have figured all of that stuff out for themselves given time - but we didn't have time for that. They needed a head start.
(The exception was the rock-star developer we had doing the main UI. He worked in another city and dropped code off every couple of weeks whose functionality and clarity astounded all of us. There wasn't anything I or anyone else on the team could do that he couldn't do better.)
Do you pride yourself on frequent communication with your employees?
Does that communication include asking them for detailed status
reports and updates?
Again, pride doesn't really enter into it. Communication is part of the job. If I don't know what's going on with them, I can't help them.
As far as detailed status reports and updates go, does the daily meeting where we talk about what we're going to do today count? I believe the kids today are calling that a daily standup.
Do you believe that being a manager means that you have more
knowledge and skills than your employees, and thus are better
equipped to make decisions?
I wasn't merely a guy sitting in an office managing developers. I was also managing the product. This meant that yes, I had more knowledge than my employees: I had a deeper understanding of the overall product requirements than any of the developers did. That was how I set priorities. When they came to me and said we can only get feature X or feature Y working in this week's build, which one should it be? I knew the answer. That was my job.
Do you believe that you care about things (quality, deadlines, etc.)
more than your employees?
There were certainly things that I cared about more than they did. I cared about the things that were my job: reporting to the CEO, making sure the requirements were getting adequately documented, figuring out methodologies for bug tracking and automated testing (things that weren't quite as off-the-shelf in 2000 as they are today), appeasing the moronic HR department. (The HR director's biggest fear about having a satellite office was that people were coming to work in jeans. That rarely happened (not that I gave a shit), though when one of the teams made a tough deadline and their team lead rewarded everyone by bringing in Krispy Kreme, there *was* a week where everyone was wearing a paper hat.)
There were a lot of things that were wrong with this project, most notably the despicable and treacherous CEO, who supported the project right up until he was able get the parallel one that he was quietly running in his office (which he'd staffed with his sons) to a point where he could dupe the board into letting him kill our project and fund his. (Our project was on track to make its nine-month deadline; his had still not delivered in 2006.)
But if you'd asked anyone on my team if they were being micromanaged, they'd just laugh at you.
Robert Rossney on January 5, 2009 1:19 AMDid our whole team ask you to post this?
People who need to understand these things usually assume that it is intended for someone else and does not apply to them.
oh hai on January 5, 2009 1:39 AMAwesome post Jeff, a subject very close to my heart
Shift8 on January 5, 2009 1:49 AMOK, what do you do if:
o Your team regularly commits errors to make the editors of Daily WTF blush?
o They've been doing it that way their entire career and aren't very interested in changing?
o They're above average coders in the SE Asian nation you live in?
At least you can shoot zombies.
Dan on January 5, 2009 2:10 AMAt least you can shoot zombies.
Wow. Dan wins the discussion thread in TWO comments. I wish this was stackoverflow.com so I could create a badge for this.
But seriously, you're describing a fundamentally hopeless situation. If none of the people on the team are capable of / willing to learn or improve..
Jeff Atwood on January 5, 2009 2:13 AMHeh. If only all questions were so simple.
Just imagine any of those 5 points retold from the employees perspective...
xooorx on January 5, 2009 2:25 AMAwesome post, just spread the word of this article around my office. I think this one line sums up what i have learned over 2 jobs.
People who feel untrusted have little inclination to bond together into a cooperative team.
Having seen it in real life, micro managers are all around us. They seem to forget that we are humans and not zombies. Its far worse in India :), we are treated like zombie labor ... another class all together.
Dipankar Sarkar on January 5, 2009 2:26 AMSounds like the policy employed by my last place of work - and the reason I decided working for myself was best!
Bryn on January 5, 2009 2:32 AMGreat post, Jeff.
This is exactly what I experienced from my manager in my previous job - this was one of 2 reasons of me quitting. From the employee point of view, the feeling of being trusted in what you do is right is best motivation.
@Dan that's pretty hopeless, I agree. I'd really recomend to look for other people to work with, becoming a zombie because of them is not the way :)
Pawel Maczewski on January 5, 2009 2:37 AMJeff
how many managers of the type that is being described do you think
a) are likely to be reading this and
b) would buy into it if they did
Surely this is the problem
I guess this way of managing people comes from the idea that to be a manager is a step above in the career. What I want to say is that if you become a manager you get more money, you are one (or more) level higher in hierarchy, etc.
After a while managers maybe start thinking that they are better (in whatever category).
From my point of view the manager is still on the same level but just taking care for other things on a project. More to say he is not managing (controlling) the people but doing everything that his team can do the best job possible. That everyone of the team can work at his best.
Therefore I want to thank Jeff for this article which perhaps helps to make some mangers think that they are not a boss but still a member of a team.
Juergen on January 5, 2009 2:42 AMWhy does this happen so frequently?
Who's fault is this?
Why are managers so bad?
If it were one or two managers, then we could say oh - that's just THEM, they were never cut out for management. But these managers are EVERYWHERE.
So there must be some base reason people act like this.
I would argue that management is the ONLY profession in which people enter without any practical training for that position. Therefore people deal with management to the best of their raw ability. They apply the problem solving techniques they find successful in the rest of their life, and the social skills they have learnt throughout their life. For some, this works as they are natural leaders. For most this doesn't, and they become pointy haired bosses to a small or very large degree.
From what I have seen MBA managers seem to micro manage less, and MBAs do teach people to be good leaders. So is it that these “bad” managers don't have an MBA but should????
In fact, the main reason I undertook and MBA is that I have worked for many bad managers, each creating their own unique set of bad behaviours. Sure – I could learn from their mistakes, but I was certain that just as they don’t see their problems, I would also have management problems that I wouldn’t see. I wanted to learn the best practices to manage people and a business. I got everything I was after.
I now find it a large pity that so few others are interested in formally learn management skills, instead thinking that just by reading a couple of books and being able to point out the mistakes of others managers, they are somehow “qualified” to manage people. Can you imagine someone being a professional software engineer after reading a couple of Teach yourself programming in 12 hours or Complete Idiot's guide books? No? Then why is that okay for Management who get paid more and have higher responsibilities???
That's my 2 cents....
Philip on January 5, 2009 2:46 AMGreat post.
You are stating many of the things they teach in MBAs these days (I have one). It comes down to enabling staff rather than instructing. Leading rather than managing.
There was something I read/heard (might have been here), that if you are a manager and you are not hiring people smarter and more talented than you are then you are failing at your job. Your job is to seek out great talent and enable that talent.
I think many of your points need to find a happy medium. For instance, a company without any level of bureaucracy is a one person company. Some rules and processes need to be in place for a business to run.
But - the one I was thinking most about most was Physical Separation. I have seen developers who thrive in paired programming, but most need to work alone. They work in offices and cubicles near each other, and pop in on each other when needed. When do you pick one over the other? I have found that letting the developers decide on their own is the best path.
I had a talker working with me who couldn't create a train of thought without discussing it. He couldn't make a decision without first having that decision verified by others. He couldn’t write a line of code without first looking up extensive on-line help and discuss all the options. One day I happened to be in a waiting room with him and he couldn’t read an article from a magazine without discussing it with those around him.
The point is that everyone’s productivity increased when he was put into his own office. Sometimes Physical Separation is a good thing!!!!
Dan - so you're the only person in the SE Asian nation that you live in that can code properly?
Surely, the person responsible for recruitment is failing?
Sounds more plausible. I hope that person isn't you...
Jo on January 5, 2009 3:08 AMAwesome post. But, we talking about more than 85% of the total managers around the world (guesstimate). Nothing changes. In the end, it all remains the same.
Elroy on January 5, 2009 3:14 AMPhilip - for what it's worth, the Physical separation mentioned by the Peopleware authors refers to a team when the members are spread rather more widely than that:
The result is that what could be a tightly bound team is scattered over multiple floors or even in different buildings. The specific work interactions may not suffer terribly, but there is no casual interaction. Group members may grow stronger bonds to nongroup neighbors, just because they see more of them. There is no group space, no immediate and constant reinforcement, no chance of a group culture forming.
-- Peopleware, 2nd ed., p136
I like this post. I disagree with how you use the term micromanagement. Micromanagement is a good management practice if used properly. It is when managers focus in as tight as a laser beam on the critical aspect of a product or project. What most of us disdain is better-termed nit picking management. That is where a manager tries to pick nits (tiny eggs of some tiny animal that infests human hair) everywhere. Disastrous.
Dwayne Phillips on January 5, 2009 4:00 AM'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.
Mecki on January 5, 2009 4:05 AMWell said. A developer may not appreciate his manager to intervene in all his activities.
Veera on January 5, 2009 4:13 AMSteven 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).
Seriously. Read the book.
-- Lee
Lee Englestone on January 5, 2009 4:18 AMMicromanagement is a good management practice if used properly. I didn't realize your middle name was Phillip, Dwight Schrute.
Joe Chung on January 5, 2009 4:33 AMSeriously? Citing Kathy Sierra - a no-talent blogger/co-author (she's never written a book alone) that's afraid of blog comments?
I have cancelled all speaking engagements. I am afraid to leave my yard, I will never feel the same. I will never be the same.
Steven Covey on January 5, 2009 4:33 AMCiting Kathy Sierra - a no-talent blogger/co-author (she's never written a book alone) that's afraid of blog comments?
A bit unfair, don't you think? While I don't agree with the way she handled that particular situation..
http://www.codinghorror.com/blog/archives/001071.html
.. it doesn't take anything away from her excellent writing.
Jeff Atwood on January 5, 2009 4:45 AMEspecially 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.
pete on January 5, 2009 4:49 AMyeah 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.
hast on January 5, 2009 4:56 AMIt's not so simple, man.
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.
Cris on January 5, 2009 5:12 AMAs 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.
With the exception of 3a. I hate status reports.
I blame my management for that.
klietus on January 5, 2009 5:25 AMRight on the spot Jeff. I'm glad your touching items Kathy once did.
You talk more or less about what I am living now, I'm doing 'just' what the boss says and turning it all back on him. Anyway it's a toxic thing.
regards
Jorge Diaz Tambley on January 5, 2009 5:39 AMGee, I'm surprised no one's linked to this yet. Don't any Jonathan Coulton fans read this blog?
http://www.jonathancoulton.com/songdetails/Re%20Your%20Brains
Great in theory, hardly practical in real life.
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.
Ordinary Geek on January 5, 2009 6:51 AMThink 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.
GrandMasterBirt on January 5, 2009 6:53 AMIt'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?
Robert Goldman on January 5, 2009 6:57 AMThe 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.
@Robert
Do some more research. My research to date shows the opposite. It is companies run by self made men who lead to the current crisis.
It has been a push away from the conservative thinking and values entrenched in the MBA that has lead to speculative and devistating decision making.
But that said, I would be very interested to know how many people have bad managers who ARE MBAs vs how many people have bad managers wo ARE NOT MBAs.
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.
Bill on January 5, 2009 7:20 AMJeff, here's a 2009 goal for you: write a post with a) no other links to yourself, and b) no Amazon links.
Pardeep on January 5, 2009 7:21 AMManagers 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. :)
Its seems that the challenge is not so much micromanagement, but more like an engineering tradeoff. How does one keep projects moving forward quickly without forcing a drop in quality. Decisions of this nature are very difficult to make without seeing the larger picture. When I'm knee deep coding something, its important to have a second opinion.
knowist on January 5, 2009 7:28 AMAn organisation that treats its programmers as morons will soon have programmers that are willing and able to act like morons only. --Bjarne Stroustrup
Alex F. on January 5, 2009 7:46 AMThis is a very complicated topic. It really depends on the team of people you have. Some people need to be micro-managed to ensure things get done, others don't. If you fall in the former camp there is hope, however. You can slowly convert your team over into a self-managing team. The Dale Carnegie leadership course is all about learning how to do this. I highly recommend the course, but if someone won't pay for you to attend it then read How To Make Friends and Influence People.
The existence of horrible managers is inevitable in most huge corporations, but I think the key is that they only have power if they have subordinates who listen to them and act on their micro decisions. Try to find a non-zombie manager and a couple non-idiot team members and band together to create a sandbox project or environment to let the horrible manager spin their wheels on.
Basically cut off someone's head, throw it to the other side of the room, and have all the zombie's go chase it while the useful people get their work done.
Eric on January 5, 2009 8:00 AM@Jeff and Dan:
I agree, hopeless - but I also think it's pretty sadly typical of our profession. As a custom development shop, we've seen these attitudes in the majority of our client's IT/dev departments. These people don't follow blogs or news or spike new technologies and just don't care. Government IT is the worst, since they have even less motivation due to budget and HR practices.
Ha ha those South Asian dumbasses. Thank God for Dan the great for getting some work out of them!!
KM on January 5, 2009 8:35 AMI agree with Darcy. Jeff appears to be living in an ideal world. But in the real world 50% of the developers are completely incompetant. And even if you attempt to constantly hire the infamous top 10% there will still need to be some major hand holding.
The famous Unskilled and Unaware of it paper comes to mind. So many programmers want to be free to make their own decisions. They certainly think that they are capable of it. Some are. Most aren't. And even the ones that are often need to be reminded about the business side of the equation.
I've worked for both of the extremes and both were disasters. As usual, there optimal point is somewhere in between the two extremes (but not necessarily in the middle).
Matt on January 5, 2009 8:38 AMPut another way, good managers know which employees are capable of making decisions and which ones aren't. And they also recognize which decisions require additional management and which ones don't. Not every decision is life or death. Good managers let employees make their own mistakes when those mistakes don't jeopardize anyone else.
Matt on January 5, 2009 8:41 AMnice post!!! good for future managers!!!
santosh on January 5, 2009 8:45 AMI agree with Sarel, that it depends on who is in your team. Some people are better at self-management than others. Some very smart people can be incredibly lazy and unmotivated, or have a lot of technical knowledge but not be particularly good at judging task priorities.
Some of the best managers I've had have been the whip cracking type. Their style sometimes caused friction but the end result was a product out the door on time, on budget and in general of a quality the whole team was proud of. Of course, they were usually somewhat charismatic and honest...tough but fair would be the way I'd describe them.
On the flip side, some of the worst managers I've had were those who didn't make decisions for the team. They would manage with the philosophy of empowerment, but it usually ended up with a team that constant fought over 'vision'. The lack of status updates, and a lack of a singular vision for the product meant that progress was a game of tug of war within the team. The idea was fairness but it just ended up causing the team to become politicized with no 'authority' to appeal to. The best example of this are meetings where things just go round in circles and you want someone with authority to just say 'guys, we're doing it this way...let's move on'.
The point I'm making is that not all micromanagement is bad, and in my experience well implemented micromanagment / hand holding ended up with a better result than the hands off approach.
@Mecki
I couldn't agree more, just wait until someone sends you this link http://msdn.microsoft.com/en-us/library/ms229042.aspx given this is very good practice, it's quite amazing how in detail it can get to guidelines, most of the time, it's a balance of time, budget, and getting the project shipped that makes me wonder why someone should spend time reading a guideline, I guess as a reference it's good.
Sentax on January 5, 2009 9:28 AMI read a great book on business The Dilbert Principle. Basically, there are two theories on how someone gets into management:
1) Peter Principle: Successful people are promoted. This has the logical conclusion that people are continually promoted until they reach one level above their maximum capability and are no longer successful, and that's where they stay. Result - in the end an organisation filled with incompetent managers.
2) Dilbert Principle: Given a two professionals, one who is good at their job and one who isn't, who would you promote? The guy who isn't good at his job might be a good manager. The guy who is currently good at their job might be a bad manager. Game theory dictates we should promote the currently incompenent person. What have you got to loose? Therefore we continue to promote incompetent people until we have nothing but excellent professionals and incompetent managers.
he he he.
Philip on January 5, 2009 9:30 AMInteresting topic and comments. You can almost tell who are the developers and who are the managers, just by the responses.
As a long-time manager of a large development organization, I feel micro management is all about control and trust. If you are micro-managing, you probably feel you have to control everything your staff does because you don't really trust them to do it right and on time, or even to do it at all.
I would venture to guess many micro-managers typically have small staffs and don't have much of a development process in place.
Try managing an organization of 20 or more developers. You'll stop micro-managing and become enamored of the virtues of delegation in a hurry.
JL on January 5, 2009 9:57 AMALSO - they should just make all managers move furniture around and install window shades, I hear that's how Fog Creek is run.
Eric on January 5, 2009 10:10 AMHaha, found your blog on Viralogy.com. At first I thought you were referring to zombie accounts of facebook and Twitter. The fact that skimming made me think its microblogging zombies didn't help :)
This post is really interesting because I have seen so many cases where micromanaging is not the right solution. If you micromanage everyone, you see every single one of their flaws, but if you empower them and let them do what they want, you get to see their CAPACITIES. A person can never be 100% to what you want, but can probably be close to 100% of what he/she wants, so its a much better way to see them be their best self!
Happy New Year!
Yu-kai on January 5, 2009 10:42 AM1. Yes. No.
2. Most? No, but some tasks, yes.
3. No. No.
4. Definitely not.
5. Depends on the employee.
Funny thing. No one has tried to eat my brain...
Charles on January 5, 2009 10:56 AMREAD A BOOK
ESPECIALLY FRED BROOKS BOOK
JEFF STOP BLOGGING
The fail is strong with this post.
@Dan, add my condolences to the pile. I'd start looking for a shotgun and an escape hatch.
Incidentally, has anyone read Company by Max Barry? Sometimes I feel like I'm inside...
Rob Allen on January 5, 2009 11:18 AMWhile i agree that jeff seems to work in circumstances which are kind of better than the usual corporate fuckup, i do not agree to the posted statements that micromanagement is neccessary if you have unskilled workers.
Basically, if you micromanage them, you are doing their work. That little productivity which is gained by the parts they can do on their own is instantly lost by the communications overhead. Therefore, in the best case, micromanagement just hides the fact that you are doing all the work alone.
Nice post, Jeff.
It is sad we are not living in a perfect world though. When a manager has to resort to micromanaging, there is something wrong (either the manager, team, constraints)...
@Robert Rossney
What you are describing is NOT micromanagement. All those points, Jeff mentioned, apply only to a certain extent. While it would be very unwise to try to tell rock-star developers exactly what to do, it is quite different in the situation when the team consists of junior programmers, and the project is actually their first assignment.
From what you are describing it seems to me that you have been alternately assuming the scrum master's and product owner's role, if we are going to stick with the Scrum terminology:-) What else is it than removing impediments and helping the team to progress smoothly?
On the other hand here are couple of points that could be definitely considered micro-management practices:
1. Forcing the staff to fill in the hours worked on a very detailed level into some system (the more systems, the better)
2. Dictating the scope of work needed to implement some feature
3. Overriding (and lowering) the team's estimates while insisting on same or better quality and features
There is a delicate issue though. What to do with the already existing zombies:-)??
I don't need to deceive you
'Cause I feel no pain
Maybe I should just let you
Come on and eat my brain
Yeah yeah yeah
It's a simple fact that the best managers don't micromanage, they delegate the tasks to people they know can do the job without their interference. When you surround yourself with competent people, you don't need to micromanage.
Ryan Meray on January 5, 2009 11:41 AMFootball is played in teams. Software engineering is more like, well, engineering.
There needs to be designers, architects, analysts, administrators, and so on. The project manager is not the designer, architect etc, but surely it is very clear, that there needs to be some architecting and so on in the project, too. The architectures and designs tell what needs to be done and what will be done or you will be fired unless you have some better ideas that we can surely discuss about.
Silvercode on January 5, 2009 12:10 PMI think what it comes down to is what motivates the members of your team.
I find that different management styles work for different types of people, and I'll openly admit I micromanage a few of my developers, but if I didn't their work would be a disaster.
Other developers I can count on and trust and have no problem leaving them alone, I know they will deliver a quality product, and come to me with any problems early on.
You can't apply one rule to the whole team, it all depends on the personalities and work ethics of each member.
Jeremy on January 5, 2009 12:59 PM@Petr Macek
Of course what I'm talking about is not micromanagement. That's the point. This list of five easy ways to tell if you're a micromanager is not especially insightful.
Robert Rossney on January 6, 2009 2:28 AM@keppla and sod
Nobody said that close managing equates to 'doing the team's job'. (btw I very much see the manager as part of the team)
When a manager points out to team members what they have done wrong (and not in a way that would undermine their self confidence) they can learn and the manager learns what that team member can do by themselves own and where they need more guidance.
That actually builds their confidence and and usefulness. Once they have been told they usually remember when they need to do something similar. Nobody enjoys having done a full day's work only to find later on that they have done it incorrectly. So by pointing them in the right direction and making sure that they do not go off on a tangent is a very good thing and is not 'doing the team's job'.
Working in one of the world's larger cities (London), communication can be very difficult due to different cultures that migrants have. No company can afford to discard them only because it is difficult to communicate with them as they are a large part of the workforce that is available. English can be a problem in itself. That is another argument for keeping a close eye on the progress a team makes.
From reading the comments, it seems that a lot of developers suffer from hurt pride. I can let them in on a secret. When a project fails, and I think it is safe to say we have all been there, and someone has to put their hand up and take the flak for it, it is the manager who gets it in the neck. And a good manager will do so without turning on his/her team and undermining their confidence and motivation because there are other projects to be completed and the team spirit has to be kept alive. But keep that in mind next time a manager asks you to explain why you did things in a certain way or why a major bug has not been caught in testing.
Luckily no major disasters ever happened in my days as a full-time developer, but I like to think that I had managers who I would have protected their teams like that and I know I am like that for my boys and girls.
For what it is worth...
Darcy on January 6, 2009 3:04 AMI'm a coder/manager at my firm, and the CEO. But we're small so that doesn't mean much.
I only answered yes to one of those and a sometimes to another but I'm in total agreement with the article.
I think many people view Management as power but in reality, I've learned that you don't have power, you more expectation and responsibility.
Managers should make sure the employees are happy and productive and that they are on the right path towards meeting the organization's goals. That doesn't mean doing everything right it means working together to reach the goals.
Honestly, if being a manager was a reward for better work, they should give you less pay. I believe the higher up you are, the more responsibilities and effort (not necessarily work) is expected of you and you're compensated by more money to make up for that fact.
How many managers have wished they could have a seemingly worry-free position with the same pay?
Jerebear on January 6, 2009 5:07 AMJeff -
Most of the micromanagers I've met have been new, either formerly competant workers elevated to management, or outsiders with no specific technical experience. In either case (and it's entirely understandable), they tend to focus on things they know. New former coders tend to focus on all the stupid things they were subjected to as coders: lines of code counts, interminable bug reviews, etc. Outsiders are just as bad because their only common knowledge with the coders is how to test the fire alarm system.
At some point, if your senior managers are astute, they'll force your former micromanager into generating daily Gantt charts, preparing reports on vacation projections, etc., and they'll too busy to manage you.
Is there anything to gain from it? At some point, for some price, your cusromer would like tor receive a workinh system.
Not to champion or debate any points already made, but something that should be considered as a different beast altogether:
Job security vs. economic woes.
Try not to make your obsolete.
Peter on January 6, 2009 6:12 AMI only take exception to #3. Taking this one too far, is the real problem. Not taking it far enough is also a problem. Unfortunately, too many times, developers duplicate efforts of other developers or have their heads down in code and can't see the big picture. A manager's job is to remove obstacles, trust employees, and be a head coach for the team. However, this means that you have to watch the game and what your players are doing. Many times as a manager, I was able to find out that someone was trying to solve a problem that another developer was already working on or had already solved. Not sitting with a developer and finding out what's going on can be as hazardous as doing it too much.
I think it depends more on the approach, the intent, and the attitude. True, there are plenty of bad managers out there, but their job is enhance communication. That's hard to do if you don't know what's going on.
Wandercoder on January 6, 2009 7:26 AMLast (maybe).
Someone else blogged about Zombies today: http://tinyurl.com/8b7enh
Its one thing for a zombie-making manager (ZMM) to take this to heart (ZMM to-do's: Get a heart) but what about those who are being zombified, especially in a tight market?
A positive attitude will help a lot. Yesterday and today, Joyce Meyer interviewed Dr. Leaf, a brain researcher, on her show. Dr. Leaf explained how memories are basically stored as negatives or positives. The negative thoughts actually release fear-related chemicals everytime their accessed with cause something like 85% of diseases. The positive ones actually release chemicals that bring healing to your body.
Being zombified could definately be taken as a negative. Some of the steps to take are:
1. Forgive your manager.
2. Repent for your own bad attitudes, words, actions, etc. That means to acknowledge your wrongs and be sorry for them. As long as you maintain an I was justified or I deserve attitude, you maintain the negative thoughts.
3. See were you can improve your performance, by being more proactive or education
4. Realize that you have gifts abilities others don't. Look for opportunities to bring those out more.
Lastly, realize what you really deserve. Someday, you'll stand before God. Do you really want what your deserve or do you want mercy?
Point taken, though I believe a more relevant post would be how not to micromanage when you feel the urge to do so in the real world. Unless of course you recommend I fire everyone who doesn’t meet *my* standards!
Preets on January 6, 2009 10:04 AM@KM
Ha ha those South Asian dumbasses. Thank God for Dan the great for getting some work out of them!!
I think you're adding a racist undertone that isn't necessary. And it's South _EAST_ Asia. I'm not calling anyone a dumbass, I'm bemoaning a lack of ambition and professionalism.
Dan on January 6, 2009 10:30 AMIt's like being an artist in some ways.
Do you think Picasso had someone telling him what to do? No, he may have influences from people or other artists to guide him, but not telling him how to create art.
Brian L on January 6, 2009 10:37 AMVery interesting post. No matter whether you are managing programmers or any other professionals, micromanagement defeats the purpose of management.
As a manager your job is to support your team, solve problems, facilitate communication etc. Your job is not to do the teams work. Once you start doing that, you stop being a manager.
Sod
a href=http://www.managementone.comhttp://www.managementone.com/a">http://www.managementone.com/a">http://www.managementone.comhttp://www.managementone.com/a
oh i was creating Micromanagement Zombies!!!!!!
SD on January 7, 2009 1:32 AMOK, what do you do if:
o Your team regularly commits errors to make the editors of Daily WTF blush?
o They've been doing it that way their entire career and aren't very interested in changing?
o They're above average coders in the SE Asian nation you live in?
At least you can shoot zombies.
Well I have worked with people that codes like if they just got a frontal lobothomy, also that resembles their willing to improve their skills... well, basically their entire attitude in ever life matter.
Must of them are permanently crippled and no matter what you do they are not going to change.
When I have found myself in that situation here is what I've done:
First you isolate the troublesome member from the critical tasks (the kind of things that no matter how viciously programed, are not going to hurt the rest of the code). The less important or relevant the better. I call making some one a Potato Peeler.
Know, here comes the fun part, you give the rest of the team the task to meticulously peer review the code that the Potato Peeler (PP) builds. Next, every time the teams has to work extra hours you give the PP the chance to leave early. If he happens to mess something up, you give the task of fixing the issue to anyone else but him.
Suddenly everyone starts to noticeing that this guy is not contributing to the work that the rest of the team has to do and the magic element comes into play... GROUP PRESSURE.
You can't imagine how powerful group pressure is (Religions are build around it).
Suddenly you have an entire team demanding some results from the PP. That common inconformity ends bonding the team together (that's a psychological state called the common enemy perspective and again religions are build around that too). You can ignore an asshole manager but you can't do that with a whole team, right?
So either the PP starts changing his attitude in order to regain its place on the group or he succumbs to the pressure, alienating himself and eventually leaving the project. Both ends being beneficial to the rest of the team.
Believe me it works 8 out of 10 times.
Chepech on January 7, 2009 1:52 AMVery good article, it remembers me Seth Godin's 'tribes'. He separates management and leadership; you're talking more about leaders and not managers. Anyway, I strongly agree with you.
dH on January 7, 2009 2:50 AM@Darcy
Nobody said that close managing equates to 'doing the team's job'.
What you describe, i would not call micromanagement, because, as you say, it builds confidence and therefore is only temporary, after a while the managed people get what is expected, and you dont need that much control, because you created a working environment.
Micromanagement, in my terminology, is the tendency to try to literally control everything, without a clear exit strategy.
If it is like the firstposter said: there are no chances that the coworkers get better or even try, and they are producing WTFonly-code, there is no such exit strategy and you have to do all the work.
If they want to get better, and produce acceptable code, it is more like training them, i'd say.
But maybe i am just burned child with micro management, i used to Work in a company, where i felt, that i had to justify every tiny detail to an invisible, everchanging, secret plan inside the managers Head. Like in boot camp: for every action there is an equal and an opposite criticism.
It didnt matter if it worked.
There were no styles to adhere to (yes. indeed.).
The only thing in question seemed to be: would the manager have done it the same way?
Nice post Jeff. I am also reading Peopleware courtesy post from Joel. You two guys are doing great job of promoting developers. I started this company with my few friends and we were developers and now we are kind of project managers after 4-5 years.
As a founder we have great ambition for this company and would like to see our programmers enjoying their work. If we take that quiz yes we are micromanaging sometimes or most of the time but that is very dubious.
So far we were not doing it and we gave developers free hand to do whatever they wanted to do because we did not know what project management is. We trusted their instincts but what you do when client is not satisfied with the quality your developers are giving?
In fact you yourself is not satisfied with it when you see the output? You just go ahead and give the same to client?
The problem is its not developers do not want to do good work, its just that they do not know what is good.
Sometimes deadlines make them paralyzed and they get afraid to try new things as it may delay the project. Sometimes developers are not ambitious enough to try out new things on their own.
What do you call a code review process (inspired from fagan inspection method) which we have just started? is it called micro management where we are telling them what is wrong with their code?
I am confused here as I do not know whether I am right or wrong after reading this post and after reading Peopleware.
I dream of having an office like Fogcreek where programmers are treated like stars but are my programmers worth that? I am not sure. They may be and I hope they are.
I would really like if you can comment on this.
Abhishek on January 7, 2009 3:20 AMI'd rather have the zombie horde than a posse of cowboys. Only CMM Level 5 writes bug free code. That's why they write the code for our nuclear reactors and space shuttles.
Process and Big M methodology isn't zombie creation. It's development for grown-ups.
See The Zombie Horde vs. a Posse of Cowboys: http://blog.markturansky.com/archives/123
Mark Turansky on January 7, 2009 4:08 AMChepech, your method did work miracles, in 1966- 1976 China's cultural revolution, during which Mao, after officially stepping down from the leadership, used the communist internal propaganda to persecute most of the new central leaders who he found unamusing. They all ended up dead in political prison. I believe both Starlin and Hitler did similar things.
In the beginning it would seem like the bad eggs are gone. But the social fallout from the process will create a tendency to resort to such public lynching every time some people experience some frustration.
I wouldn't want to be in your organization.
Damn, I miss her ...
Jonas on January 7, 2009 6:38 AM@Mike Turansky
Only CMM Level 5 writes bug free code
Actually, if you read the article you quote carefully, NO-ONE writes bug free code. Even Part of CMM Level 5, which is a *process*, not an attribute of the coders, is extremely high levels of testing and reviewing. This is only actually suitable for very large or safety-critical organisations, where failure is disastrous, because of the terminally high overhead involved.
Also, there's a vital point that everyone involved apparently has a great deal of respect for each other's abilities.
The developers have even begun their own formal inspections of the code in carefully moderated sessions, a rigorous proof-reading they hope will confound the testers. The verifiers, in turn, argue that they deserve credit for some errors found before they even start testing.
From the verification group's perspective, says Pat McLellan, a senior manager, we're aware that if there was no independent verification group, the developers would tend to be more lax. Just the presence of our group makes them more careful.
No-one's saying that you shouldn't have standards or procedures to work to, such as regular testing and bug tracking. But again, if you read that article, *everyone*'s involved in making the process better, and making it work. That's not zombification at all.
And finally:
Admittedly they have a lot of advantages over the rest of the software world. They have a single product: one program that flies one spaceship. They understand their software intimately, and they get more familiar with it all the time. The group has one customer, a smart one. And money is not the critical constraint: the groups $35 million per year budget is a trivial slice of the NASA pie, but on a dollars-per-line basis, it makes the group among the nation's most expensive software organizations.
This is a fairly massive caveat, wouldn't you say?
And then there's this:
The most important things the shuttle group does -- carefully planning the software in advance, writing no code until the design is complete, making no changes without supporting blueprints, keeping a completely accurate record of the code -- are not expensive.
This is, if not a lie, at least an untruth. If you consider time as a resource, they can be massively expensive. And, as a commenter points out, $35 million per year to maintain a 420,000 line program which only works for a single customer is actually pretty damn expensive.
To summarize, your example won't apply to 99% of software products, and Jeff's point about having respect for the abilities of your employees still applies. Thank you however, for pointing me to a fascinating article.
http://www.fastcompany.com/magazine/06/writestuff.html
But if they (the space shuttle coders) are the best in the world and they choose to follow a Big M process, why would the average developer choose cowboy methods when the best of us choose otherwise? Big M process would, in that case, protect the average developer from himself.
My own software has always benefited from thoughtful requirements and design. Steve McConnell says requirements and design are essential to RAD.
It's a tough sell to somehow say that cowboy coders making their own choices (and mistakes) are going to somehow be a better outfit than the highest caliber of professionalism. It's to say that quality in a product is less important than the team's touchy-feely feelings and ego.
Atwood (and every other software blogger in the world) has written about egoless programming.
And it's more than the space shuttle or our nukes that require bug free software. I don't want my bank losing my money (in the computer, anyway). I don't want my plane to crash. I can go on.
Quality matters and the zombie horde can achieve it with the right process.
Mark Turansky on January 7, 2009 7:55 AMHave to admit I didn't read all previous entries, but I browsed 'em fast, and nobody seems to be asking the question which annoys me since yesterday.
Isn't there good programmers who are actually zombies and couldn't do otherwise ? Not those who read this blog. Those who open their computer at 8, do their job correctly following a strict guideline, and shut it down at 5. Those programmers won't make it on their own. But thew can get a whole lot of lines of code, and will enjoy more coding on what annoy us.
A mid-size business, having about half its staff in zombies, the other half being micro managers on a side and stand alone advanced programmers on the other side, could be a powerful pattern.
Franck on January 7, 2009 8:59 AM@Mark Turansky
And yet planes do crash (including due to software and design errors).
And banks lose money due to hacked systems left open by software and design errors, but banks desperately try to keep those facts hidden from the general public in order to maintain their trust. They replace stolen money, most of the time even before the public notice their loss.
There are no absolute bug free applications, just as there are very little guarantees in life. Realize it, accept it and do your damn best to limit the damage your bugs can do and fix them properly once they are discovered.
y draigg goch on January 7, 2009 9:04 AMToo ambiguous.
I've managed people that already were zombies. Giving them instructions like read these 20 lines of code, do not read the next one until you understand what the current one does and they still would wander off and do something entirely unrelated and unprofitable.
Then there are those with whom I can share the vision, approach, whatever you want to call it, and at the end of the week they have lots of good stuff done.
Don't put it on manager types all the time -- there are plenty of self induced programmer zombies out there already...
What's worse than a manager who does not understand what you do, one who does ....
If your manager does not understand what you do they will also not understand why things cannot be done as quickly as they want
If your manager does understand what you do then they will (usually) try and manage you by knowing your job, which devolves into micro-management
The ideal manager is the one who understands what you do but not how you do it (in detail) ... they then cannot micromanage you but are understanding of real limits, they then become a member of your team and not some external entity separate from it
Jaster on January 7, 2009 9:34 AMMy own software has always benefited from thoughtful requirements and design. Steve McConnell says requirements and design are essential to RAD.
McConnell also said that software creation is a Wicked problem. You don't know what the problems are until you've done SOMETHING.
Of course you need requirements and design, nobody said you could strip out process altogether and still produce a usable product, but if you've reached the level where people are just working by rote, with no real idea of what they're doing, and can't make a single line change without holding a meeting, then when a new problem they've never encountered before occurs, which is far more likely on the 'net than on the shuttle, they'll have no way of dealing with it. If you're trying something new, you can't predict the problems before a build. This doesn't mean NO design work, but it does mean that your design needs to be generalised, so when you iterate around again, it can be more specific.
Incidentally, this is another thing the Shuttle computer don't have to deal with, as they're working for a very established system, with very established guidelines. For a completely new system, there's a good chance that their company won't survive, because they'll have to throw away their existing proven code. It'd be pretty hard to write a brand new 420,000 line codebase if each line needed peer review.
As a manager of development teams working on varied projects, I don't see myself as a micromanager. Asessing the talent in the team and letting that flourish, putting the right people together who can communicate and develop is what it's about. I'd rather employ someone who I felt could take on my role or a different role in the company than somoeone who'll plough the same furrow.
It's about the team, not the manager. Yes, I take the flak for things if they go wrong as that's my fault, but when things go right, the team get credit. And at the end of the day, everything is about getting a product to market and if the team know what they're doing and why and then hear about how well it's done and how pleased people are with the product, it becomes less of a footnote on their CV and something that they take pride in.
As a team, I think we're quite proud of what we do and at times possibly unbearably smug sounding, but it's probably just down to enjoying what we do, without niggling interference from 'ubermanagers' without portfolio. They're the ones that create the truly dire situations when they delve into other projects.
Mogbasket on January 7, 2009 11:30 AMThis gives interesting results:
(1) http://www.google.com/search?q=lovable+fools+or+competent+jerks
(2) http://www.google.com/search?q=lovable+fools+or+competent+jerks+-harvard
And one like this:
http://www.softwaresweatshop.com/bss/5-reasons-you-want-to-work-with-a-jerk.html
But that may not exactly be the point of this post. Eventually, trust is a two-way street. And any accident shuts down one side of it, sometimes both. Curse your luck or blame the powers that be.
But you get full marks from me for speaking for our lot.
Thanks :-)
PS: Whatever your personal bias (or absence of it) Google's way of getting people to create cool stuff seems to be admired around the world and well, ignored all the same :-)
TheExperiencedOne on January 7, 2009 12:52 PM@no importance
I believe both Starlin and Hitler did similar things
As far as i remember my history class, Hitler's way of running his corporate was more based on redundancy: Every institution had another institution with a similar function, and orders given where vage, so that people had to interpret them. If the orders didnt work well, cleary the people where to blame who had misunderstood the great genius. And if someone did too well, there was always a competing institution to block him and stop him from getting dangerous.
The peer-pressure was more used against the common people, and not in a very subtile way.
keppla on January 8, 2009 1:58 AMSadly, my supervisor answered Yes for every question.
jitendra on January 8, 2009 2:48 AM@Mogbasket
Asessing the talent in the team and letting that flourish, putting the right people together who can communicate and develop is what it's about. I'd rather employ someone who I felt could take on my role or a different role in the company than somoeone who'll plough the same furrow.
I agree with what you say. But putting a good team together (and keeping it) is very difficult. Not through lack of people applying, mind you. You cannot always hire who you want, just as you cannot always turn down who you don't want.
You have economic restraints and therefore take on less brilliant people than you want or you simply cannot find that star player. And having to compromise at hiring time, makes closely managing people necessary; sometimes the entire time that certain people are on the team...
Just one remark: when you say it is not about the manager, it is about the team. I cannot stress enough that these are not two separate entities. Whether the manager also develops software (part-time, as in my case, to stay in touch) or not, the manager is part of the team, or at least should be. You only take the flak by yourself, the rest you share as you said.
Darcy on January 8, 2009 3:37 AMJeff, I embedded your image in a post on my favorite forum. I know embedding images from other sites is rude. I'm sorry.
But the next time you post something like want-ad-zombies-seeking-brains-1.png, I'd gladly do it again.
Pikadude No. 1 on January 8, 2009 5:01 AMDo you believe that you could perform most of the tasks of your direct reports, and potentially do a better job?
This is not only normal but required for a team lead in the environments I've worked in. I'm not sure if team leads manage programmers in any capacity or not, but it would seem to me that they do. It's at best objectionable to say that answering yes to this item is a bad sign. It should really be rephrased as something like
Do you believe that you could perform most of the tasks of your direct reports, and potentially do a better job, _and do you ever act on this feeling_?
mgb on January 8, 2009 7:52 AMI've been reading Coding Horror for years now, waiting for you to live up to your name. Finally a horror story! :)
Nikola Gedelovski on January 8, 2009 12:04 PMI try to work myself out of a position by growing others upward and outward.
Not to mention, I like to surround myself with excellence so I want people thinking for themselves. With smart people, the rule of thumb is get out of their way. Periodically, light a fire and guide with tests for success.
J.D. Meier on January 9, 2009 2:31 AMSupposedly managing a team of experienced scientists and programmers, supposedly because I considered them my peers or superiors, it was my job to
1) Offer advice when asked.
2) Manage the budget, and find money wherever I could to support their aspirations.
3) Get out of their way.
4) Hire really good people.
5) Offer a broad general direction to which they may, or may not, commit.
Suffice to say, at the time I came up badly on the points scoring system of management practice that was the Harvard Business School fad of the day. Never went much for business tosser fads anyway.
Strangely enough, the ensuing research group got so big, it was necessary to hire managers, my bosses to be. I agree, get the hell out of their way. When you get too old, just give way.
Shame that those up higher cannot get this simplicity. Maybe, in retirement, I should turn my attention to them, and instead of hiring good employees, use a wooden plank to fire those who wank.
Bugs on January 9, 2009 3:34 AMI was just recently promoted to a Lead at my firm after our Director was let go. She was a notorious micromanager, inspired no loyalty from her developers, had a poor understanding of our process, and the only way in which she brought the team together was through mutual contempt of her. So after she was let go, I was put in charge of a portion of the team.
So my promotion was instantly well-received, but I find myself struggling with the balance of communication and being hands off. My first change on taking charge was to get rid of the weekly one-on-ones that used to eat up 50% of the previous manager's time leaving no time for her to actually react to feedback. These were the bane of many developers who saw them as a waste of time, since their feedback never seemed to affect change, and the manager's feedback was always taken with a grain of salt. I also got rid of the weekly team meeting which had no real structure and was also considered a huge waste of time for various reasons.
Now I do weekly schedule updates via e-mail letting everyone know what the priorities of the week from me and up above are, and I check in with people on a per-project basis at certain milestones. We do peer review for larger projects, and have a really good review and QA process in place which is getting tighter and tighter as we go on.
The one thing that's lacking now is that I leave so much in the hands of the developers and the process that there's very little reason for the team to come together. What ways have you guys found to:
1. Hear individual grievances, feedback, and ideas from particular developers without instituting some kind of mandatory weekly feedback session?
2. Get the team sharing knowledge when they're not working together on one large project? I require documentation of data structures and database queries, load generating algorithms, and any network transfers for review by our systems/network experts and peer-review -- but the team isn't required to review one another's materials, so this doesn't get propogated that well.
Ideas are appreciated, but it'd be nice to hear about your experiences with good managers and things they did that you enjoyed, rather than just hearing about experiences with bad managers. As some people pointed out, some people require a lot more management than others. I have a few pretty green people on my team and to date I've been trying to let them grow by giving them larger infrastructure projects with very liberal deadlines -- but for projects whose deadlines aren't set by me, they require a lot of careful supervision and guidance to get things done on time.
Thomas on January 17, 2009 4:55 AMThe comments to this entry are closed.
Subscribe in a reader
Subscribe via email
|
|
Traffic Stats |