So you’re a manager. You even think you’re pretty damn good manager. Fine for me. Do you remember Pointy-Haired Boss? Yes, that clueless manager from Dilbert cartoon. You have this guy sitting in your head. So do I, by the way.
Is that supposed to be insult? Well, not exactly. I really think every manager has this clueless version of himself in the back of his head which is used more often than we’d like to admit. You still don’t believe me. Do a simple exercise. Think about your team. Arrange members from the best to the worst. Easy?
It wasn’t supposed to be easy. The trick is how you decided that one ‘average’ person is after all better than another ‘average’ person. Some guessing I guess. Why exactly you have chosen the best one? And what a couple of worst people have done to earn their place? Is it possible that you justify their position with some past event (success or failure) which was spectacular enough they earn the place in your mind? Is it possible you didn’t take into consideration recent history because you already are strongly biased?
And now the best part, think how many things you haven’t taken into consideration. You haven’t thought about tons of important things and you were still able to say who is better and who is worse from others. And no, I don’t believe none of them are important. Isn’t that clueless?
A Confession
I worked with bunches of underpaid and overpaid folks. I saw work which was underrated or overrated just because of person who authored it or the person who judged or both. Many of decisions standing behind these situations were mine. I’m not proud of it.
What I can say is I didn’t do it on purpose. I just lacked knowledge. Sometimes I wasn’t even conscious my knowledge was insufficient to make a right call. Sometimes I should try harder or think more. I was, and I am, a clueless manager. I try to fight it but that’s an uphill battle. I have my prejudices and preferences and I don’t claim I’m able to fully ignore them.
The Bad News
I’m not the only one. I’m tempted to say that every manager is so because the only ones who would be different must be heartless robots which aren’t great candidates for managers anyway.
This means you as a manager, and your manager too and her manager and so on, are clueless to some point. Usually more than you’d like to admit. This mean there’s a chance your judgments aren’t fair or your work may be misjudged. And finally this means your subordinates can trick you along with your cluelessness to make you think better about them.
Managers were, are and will be clueless. We may fight with it but we’re likely to fail. Most of us don’t even try anyway.
Subscribe RSS feed
Follow on Twitter
Subscribe by email
13 comments… add one
I think that this can be generalized : everybody is clueless, not just managers. It’s human nature and, like you said, we aren’t managed by robots yet.
Do you want to imply that managers are more clueless than other people?
Or that being managers, they should try to be less clueless than the people they are managing?
Or am I reading stuff that you didn’t wrote?
Nice write up – I agree with Laurent that we are all clueless to a certain degree. We all have innate prejudices and limited knowledge that affects our actions and thoughts. But the difference with managers is that because they are asked (or rather their job requires them) to make decisions that impact the lives of others we are more likely to be judged as “clueless” by our imperfections.
Laurent,
Managers probably aren’t more clueless than the rest but their decisions affects more people than just themselves. Average clueless developer can screw some code up which will hopefully be caught by some automatic mechanisms you use. Average clueless manager isn’t really controlled by anyone (his manager is also clueless, right?) and his decisions affects whole teams. His biases and prejudices can hurt other people while typical developer can only hurt source code.
Tokes,
You get it right – managers are much more often forced to make decisions and they make it, no matter how clueless they are. Developers, or any other line workers, do it rarely and even then they can take a step back and ask for a decision one of their managers, which they often do.
This is by the way one of things I hear from newbie managers: suddenly they have to make all these decisions by themselves while earlier they could just pass it to their manager. This is a quite a mind-shift.
I am pleased that there are managers who realize this. Everyone in some organization must be aware what are they clueless of and must not assume that higher position in hierarchy means that they understand what the heck is going on below them. If they think they do, they will constantly be a burden to people who know what to do. On the other side, these clueless people might be grate business decision makers, but they must make decision based on more abstract data, pros/cons, costs and risks delivered to them by people who have the clue.
To bring this back in context of software development:
1.Who doesn’t code doesn’t get to speak about the code. That includes architects that don’t code and usually only frustrate people that do actual work.
2.If manager needs to sort out his developers, he should ask his team lead to do that and explain how and why he did it.
3. If managers want to better control of the development process (that he don’t understand), he should establish communication and control points and not constantly tell developers what to do.
Vukoje,
I’m surprised so few managers realize this.
Even though I do, I’m far from keeping myself far from discussing development issues. I engage most architectural discussions in the team and pretty often my arguments are taken into serious consideration. I don’t want to say it happens always for good, but I can’t say it is always (or even usually) for bad. Thus I don’t agree with “who doesn’t code doesn’t get to speak about the code.”
As far as final decision are made by people who code, and this is how it works in our team, everyone is invited to speak up. I’ve seen it a number of times when non-developer brought a valid argument which changed final decisions.
But in general I’m with you: let developers code, let managers manage.
Ok I agree, I did over-dramatized the concept. :)
Owner of my firm was a Fox programmer and I picked up some coding tricks from him. But he used to have an idea that he can code in any new technology better than us developers (programmer with superiority complex… no way :) ) . So we started treating him as he was one of us, bombing him with technical info and asking him to make decisions based on facts etc. So he changed his mind and let us code.
To loosen up architect fact. They don’t have to code every day but they can’t be technology agnostic theorists. I was led by a guy like this and it was one of the biggest frustrations in my life.
Just read a great article on the subject
http://www.artima.com/forums/flat.jsp?forum=106&thread=282344
I think we agree on this one. The final decision on every subject should be made by a person who has enough knowledge and experience to make the right call. If we talk about code (code itself, design, architecture) it should be someone who codes.
The architecture however is pretty tricky. I mean it’s pretty often case when people who have enough experience to build the right architecture tend to step back from coding which naturally reduce their knowledge about current technologies. On the other hand I’m allergic to those folks who haven’t yet created any real system but are all into new trends and they tend to make decisions basing on what’s cool, not what’s right.
I know pretty few persons who fit the role of architect in a way you describe it. And yes, this is sad.
Vukoje, I agree there needs to be a balance within a manager. There needs to be enough technical expertise to follow the conversation, know the basic “-isms” of the team’s work (be it technical support, development, project management, etc.) that comes from some level of experience yet counter balanced with an ability to step back and let the “smart people” on the team speak and have their ideas/vision/approach supported. In the later, it might not be exactly how the manager would do it, but if the approach appears to meet the need/goal and fits within some parameters the manager can support, then the manager should seriously consider supporting rather than correcting the approach.
I recently wrote in more depth about what I call “decision latitude” that loosely addresses this specific topic here: http://bit.ly/9Kt00D
This is too one sided. Its hard to comment on someone else’s position until you have been in their shoes.
Once you’ve been promoted from pure DEV, you’ll appreciate this article.
http://softarc.blogspot.com/2008/02/ten-things-developers-would-know-if.html
Javaguy44,
I don’t think it is one-sided. Most of situations I have in mind while reading this are from my managerial spells. The slight difference is I’m aware that I was (and I still am) clueless in a number of cases. Majority of managers neither are aware nor care about this.
I don’t say you should have the same code-level knowledge as every single one developer in your team. What I say is managers often lack knowledge in areas where they should know it all.
In general we suck at being managers. I guess we suck at being managers even more than we sucked at being developers.
Yeah well it doesn’t seem natural for a human being to manage other human beings. A good manager is worth more than his/her weight in gold! Especially middle level managers who are the hardest to find and replace.
Letting the guys/gals under you take decisions that will affect your very job is not something for the faint of heart. Lotsa stress if your team don’t perform too well or made a big mistake and the manager is often the one who gets replaced. So cover your ass is the norm against such eventuality which mean incompetence and corruption sets in fast and stay there.