10 reasons why software managers tend to suck.
A developer perspective:
Most project managers, program managers, product managers, development managers are not pointy haired bosses, most are trying to do a good job, but:
-
1. Software Managers are not in control.
- The most important factor in developing software is the quality of the programmers.
- The best programmers are up to 28 times better than the worst programmers (in quality as well as productivity)
- The working environment has a profound impact on productivity and quality.
- Estimation is usually done by the wrong people.
- Estimation usually occurs at the wrong time.
- Software estimates are rarely corrected as the project proceeds.
- One of the two most common causes of runaway projects is poor estimation.
2. Software Managers know less than the people they are managing.
3. Software Managers are not in control.
4. Software Managers don’t get to do the fun stuff.
5. Software Managers are not in control.
6. Saying something is so, does not make it so.
7. Software Managers are not in control.
8. Software Managers cannot estimate how long things will take.
9. Software Managers are not in control.
10. We know software management is hard, because there are so few good software managers.
The factor that most controls the development is not the management, it is the developers, there is a massive range in the ability of developers, it is difficult for another programmer to gauge this difference and nearly impossible for a non-programmer. Unhappy developers are unproductive, especially the good ones.
Nearly all developers are highly motivated to produce good software, a lot of management activity negatively affects this, so a light hand is good. Almost all developers know more about the software and what they are doing with it than anyone else. (this is the details of the stuff they are buried in every day).
The best thing that a software manager can do, is get the best developers he (sometimes she) can get hold of and remove as many obstacles as possible from them getting the job done.
There is nothing you can do to make it work, you have to help it work.
To many managers, getting rid of the arrogant, undisciplined, over-paid, technology-obsessed, improperly-dressed etc. programmers would appear to be a significant added benefit.
Bjarne Stroustrup The C++ Programming Language 3e, section 24.2.4
2. You know less than the people you are managing.
Detailed software knowledge has a half-life of about 3 years, if you are a manager you out of date.
When someone is working all day everyday in the details of the product, when they run the software time and again during the day, when they are thinking in real detail about how it works day in day out, they know the software. Management simply cannot apply this level of attention to every part of the product.
Software development has chaos theory as its in-laws, you often need to know the details to make the right decision.
Management and developers are motivated by different things, some managers do not understand this.
Software developers are motivated more by problem solving, intellectual challenge, technical development, being proud of their work than they are directly by money or promotion (Nine Things Developers Want More Than Money). Many developers are positively averse to office politics.
Think maslow’s hierarchy of needs. Think self-actualization.
4. You don’t get to do the fun stuff.
Every single, ex-developer I have ever spoken to misses development. Every single one. You may be better, you may be interested, you may want to keep your hand in, but you are not available, you need to focus on being a good manager. It is regrettable, but you need to live with it. Some mangers eventually go back to development, most do not.
True happiness comes from the joy of deeds well done, the zest of creating things new.
You cannot really tell what developers are actually doing, if you say do it this way and they agree, how do you know what they actually do.
If you work “with” the developers, then they will work “with” you.
6. Saying something is so, does not make it so.
For a lot of management you can say something is so, and proceed with the assumption that it is, even when it isn’t it is unlikely to be provable, so it can simply be asserted. It is not so in software, if the estimate for development is nine months then it is nine months. If a customer absolutely positively must have it in six months, then it won’t happen, you either have to remove a lot of functionality (perhaps half, things being non-linear) or convince the client it will take nine months.
The most likely outcome from this clash of timetables is that the developers (and prior to that the manager) will cave in, accept the new date, rush the development which will end up taking nine months anyway (if your lucky) and be in a worse condition because its been rushed.
Developers are analytical & critical thinkers, they are far more concerned with actually correct than politically correct.
They are going to argue and discuss things and sometimes disagree with you and each other.
The truth does not change according to our ability to stomach it.
8. You cannot estimate how long things will take.
Estimation should be performed by the people who are going to implement the functionality. However most estimates are produced by management or marketing and typically adjusted by politics, rather than prudence. This is just lying to yourselves, don’t do it.
Estimates are frequently determined before requirements, they are aspirations or at best guidelines. Estimates have to be based on requirements (and may require significant investigation, such as functional specifications, use cases, prototypes etc), in any case it is likely that either requirements will have to slip or the overall schedule will. You can either explain this to the customer at the beginning of a project or the end, its up to you.
I have always found that plans are useless, but planning is indispensable.
If your developers never cause you any problems, then they don’t know what they are doing. You have the wrong developers, your pretty much sunk regardless.
You can have an easy life getting nothing done or a more “interesting” life doing something useful. You choose.
10. We know software management is hard, because there are so few good software managers.
In my time I have worked with the many and varied of the software world and this is how it measures:
Developers:
36% Good
32% Average
32% Poor
Software Managers:
13% Good
23% Average
64% Poor
In the case of the software managers, that 13% good figure translates to three people out of nearly 15 years of experience.
My three good managers have been:
Mike Bates (BJSS)
Boyd Moffat (Three-X Communications)
Don Kavanagh (Morse)
I know software management is hard, because there are so few that are good at it.
If you think your management doesn’t know what it’s doing or that your organisation turns out low-quality software crap that embarrasses you, then leave.
Edward Yourdon, Rise and Resurrection of the American Programmer
| Add Bookmark: |
|
|
|
|
|
|
|
|
|
|
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
I can't believe it's not better 
Nice post. You say that there are so few who are good at software management. I think the reason for that is that it’s hard to say if a manager is good, unless you’re a programmer. And if you are a programmer, you’re biased – obviously, you’d like an easy job and lots of money, and you’d like the manager to get out of the way, which isn’t always right.
We need more objective measures to decide the quality of managers.
While I clearly accept I am biased, my perspective is from a view of results.
Its not that a programmers job should be easy and have lots of money, a programmers job is to deliver, there are poor programmers as well, there are just a lot less of them.
What I think makes a software managers job hard, is that the normal human gut instincts are all wrong. Management are *not* in a senior job, they are in a *different* job (despite how it looks). So they need to mesh with the abilities of their co-workers nor try to direct everything.
There are plenty of things that management need to focus on, that don’t necessarily have anything to do with actual development.
See also The Development Abstraction Layer.
Its not that I don’t have respect for either the job or the people, its that I am lamenting the fact we don’t have enough good ones.
My principal goal is to deliver great solutions to peoples problems, anything that helps me do that is GOOD, conversley anything that stops me doing that is BAD.
*an easy job and lots of money* see point 3
I have added links to the bullet points, to the very fabulous “Facts and Fallacies of Software Engineering” by Robert L. Glass.
Read this book, its really good.
I am one of those software managers that was offered (and accepted) the position because I was the top developer on the team and wanted to make a difference. I, as many out there, was tired of having poor software managers and watching them fail miserably, and thought I could do better. I had been through some pretty rough projects and wanted to see if I could make it better for future developers than I had it (kind of like how parents want better lives for their children).
Obviously, I have met the task with a lot of failures, for many of the reasons you listed. I knew it wasn’t going to be easy, and it hasn’t been. I have tried my best to protect the teams I’ve managed, and like to feel that I’ve made a small difference in many of their careers. Some of them have left, but I have had the joy of knowing that they stayed as long as they did because I was their fighting for them up to the minute, and I had their respect.
I’m still at it two years later, and some days it just feels like it’s pointless. I have found that there are many outside forces that set you up to fail, and they challenge there is trying to cut them off at the pass and prevent them from doing too much damage. I do have those moments, however, when it feels like I’m getting through to people outside of our development world. I’ve been able to build up trust with some of our organization’s leadership and have been given the benefit of the doubt in a few cases that have helped us dodged a few bullets. Those days make it feel like it’s worth it.
On a different note, in regards to your point 4: You don’t get to do the fun stuff, that is especially true. What has helped for me is to continue your passion outside of work. I continue to do quite a bit of development outside of the corporate world that keep that itch scratched. What I have found is that those types of personal projects, the ones that don’t have all the constraints and headaches in the business world, end up being more enjoyable anyway (even if you don’t make any money with them).
All in all, nice post and hopefully more developers in those situations will try to take on the impossible and attempt to make a difference in their own worlds.
Kris,
Glad to see, there are good people out there fighting the good fight.
I am intending to follow up on this article, I really do think software management is much harder than most people think, mostly because of point 10.
Things have been pretty rough for me these last couple of weeks, but I will get an update out shortly.
Managers don’t suck. It’s the responsibilities of a manager which makes him/her suck. Managers are not morons, but they eventually turn into morons (of the worst category) as time passes by and they keep performing those horrible tasks which they have to, on a daily basis. Managers are not out of control, but they go out of control because they want more, faster, better in less time to get ahead of their competition, primarily in the form of other competing managers.
Managers don’t view people as people. They view people as chunks of “deployable person-hours”, with a few critical parameters like “skill”, “friendliness”, “willingness to slog” etc. etc.
It’s important to realize, that at the end of the day, Managers are extremely selfish creatures, but like shrewd businessmen, they will camouflage their selfish interests in a way that will appear beneficial to the self development of the people working under his/her supervision. I’ve seen a lot of managers do this very skillfully (people manipulation, if you will), and I’ve also played a number of tricks to have them contradict themselves on a different occasions, when they clearly went against what they had said previously.
In short: Don’t ever trust your manager, but instead backstab him/her as and when you have the chance to, with a smiling face and professional attitude of course, do everything it takes to project him/her as worthless: highlight his failures and incompetencies to his colleagues in subtle ways, and if possible, to the people senior to him (chances of this are difficult, but nonetheless, you should never miss and opportunity), and of course: On a daily basis, bring out one point bad about him to your own colleagues, without being obvious that you’re after him. Caution must be practiced while doing all this, otherwise things could go wrong for the subordinate himself/herself.
But if you develop a well crafted scheme of doing the above, and follow it without fail and intelligently, there’s nothing that can stop your manager from facing the inevitable. Just be careful, list out all the weaknesses, and pounce in as and when you can.
But keep in mind that while you’re doing this damage to him/her, you need to develop a stronger relationship with him/her to stay out of any suspicion. Have lunches together if possible, complement him/her often (when no one else is around), help him/her on multiple occassions -> and there’s your chance: screw up something majorly which will show up at a later time wihtout bringing up the fact that it was you…..or without making it possible for the manager to get back to you during the time of wrong execution.
There are more than a hundred ways to get a manager thrown out…..but all of them take time and persistence. If both are present, then the manager will slowly grow aware and begin to believe he’s incompetent, and a failure….and in no time so will the people around him/her……and then the inevitable will have to happen…..
So far, I tied this religiously with three managers……two have already quit (one last year and one this year)…..and one is having a very difficult time…….
Always remember: Mindgames are the best weapon of choice in this corporate hell, and if you want to survive, throw away the good in you outside office, and learn to play them. The world is not nice, you know.
Peace.
Software managers need to turn their thinking upside-down…
http://kw-agiledevelopment.blogspot.com/2007/07/agile-managers-need-to-turn-their.html
Kelly Waters
http://www.allaboutagile.com