Getting Rewarded for Incompetence
-
I have to admit that this article caught my eye with it's title. It's a story from the real world, supposedly, with the author being one of the managers in the story that was "rewarded" for his shortcomings.
I don't think that incompetence gets rewarded on a regular basis, but I'm also not naieve enough to think it doesn't happen. However the story was interesting to me because I think that it shows a couple of good things to be aware of within a software team, or most teams for that matter.
First of all, the story shows that taking time to work on detailed requirements doesn't always satisfy the needs of many of today's companies. Often IT managers want to see some progress and while racing into things with quick results isn't the answer, a blend of both approaches can really help satisfy all parties. The Agile, Scrum, and other approaches provide a blend of these two requirements.
But I think the more important thing in the story is to recognize that different people have different approaches, but also different strengths. Bob, from the story, rapidly showed progress in prototyping and results for users to look at. Steve had a more detailed approach that required less rework later on to finish. While neither managed ended up with a complete success, I think that the different strengths could have been better used by allowing each person to work to their strengths and handing off work to the other as needed.
In most places I have worked, rarely do projects start and stop together and rarely do you find experts that can handle all phases of a project. Or at least, more than one expert. Instead you will have a team of people, each of whom have their own strengths and weaknesses. A good manager will work to blend those strengths and move work between people to be as efficient as possible.
Which should work well if you ensure your incentives and rewards don't compromise the system.
Steve Jones
-
I too have experienced both kinds of the projects described in the article. I too have found that rarely does one approach work and a combination of the approaches ultimately seems best. If I had to determine a ratio for the approaches I would lean more towards the prototyping, but not by much, say 51 to 49. How's that for sticking my neck out!
The problem I have experienced with the more detailed approach is twofold. First, no matter how well you design, redesign is always required, which leads to redevelopment, etc. You can't avoid it. Second, I have seen many projects cancelled because there was the perception that nothing was being delivered. Sometimes even after spending big bucks.
So what does this have to do with rewarding incompetence, nothing!
Thanx for listening.
-
Guess you've never read "The Peter Principle" by Tom Peters. In another era, before Dilbert, it's premise was that in any hierarchy, each inidividual rises to his own level of incompetance. Good read and still valid.
Regards,
Greg Young
-
In my whole career life, I saw too many cases of incompetent people got rewarded. In one company my boss promoted a programmer with less experience and much weaker technical skill than me to be senior progammer. I asked my boss why I did not get the promotion and his answer was you just had a 1 year old son, you could not stay late to work, so I could not give you the promotion even though you deserved it more than the other programmer. The next day I sent out my resume ! They penalized me because I had a newborn ! In another company one boss gave rewards to almost all the people working under him just because those people doing their jobs and worked 8 hours a day. Another boss did not give any award to his people evey they worked overtime everyday and got the project done on time.
It is all in perspective and yes life is unfair.
-
I've experienced similar conflict between planning and producing results. In one company I even challenged my supervisor on a project - he was upset that my code had "too many errors" in it on implementation. I made a deal with him - he would get off my back and let me do proper design, rather than just slamming code in. If, within one month of implementation, we experienced no more than three code errors, he would never ask again for "immediate code", but would allow planning to proceed first. If we experienced more than three error in that first month, I would stop asking to plan projects, and would just start coding to produce immediate results.
At the end of one month, we had experienced two code errors. Did I get a bonus? No, but I was allowed to plan projects after that with only occasional reminders to the boss about our agreement. However, it did start a "personality conflict" that eventually led to my leaving the company (at an opportune time - they were giving out $10,000 bonuses due to a merger with another company). After that, I started looking for a company whose corporate culture was more in line with my personal values, and I found one - I'm still working for them 8 years later.
In my experience, users are generally happier when they get a product that works. There are times when the user focuses on "speed" - how soon a product can get up and running, but if that product does not work on implementation, they are very unhappy - it overrides their "joy" at a quick implementation, and they get pretty hot (and my company is going thru that experience right now). Educating the end users may be part of the solution, but we definitely need to find a mix of planning and quick reaction that will work for us in today's fast-paced, ever-changing environment.
Here there be dragons...,Steph Brown
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply