Do Managers Prey on Developer Pride?
Filed Under Human Factors
It is well known fact that most developers suffer from a disease called egotism. The question I am currently pondering is if managers (either intentional or subconsciously) prey on this sense of pride.
A number of my previous articles seem to all have a reoccurring theme: developer over estimates, manager over commits, developer works late and takes blame.
There are many phases in the development lifecycle where this phenomenon occurs, and if compounded can be recipe for disaster.
Phase 1: Estimation
Managers know that developers suck at estimation – unfortunately, developers do not. As a result, developers compensate their inability to predict the future with an egotistical, artificial, low, single point estimation. Developers always will be held responsible for estimations not given in ranges and probability.
Phase 2: Perceived progress
While the project is in transit, again, it is the developer who is asked to give an estimate of perceived progress and velocity. Developers would rather give a optimistic report and use the Gut Instinct equation. “90% complete – 90% of the time”, and again the problem compounds.
Note: I wish people would start using Agile or SCRUM so this topic is mute…but I digress.
Phase 3: Fictitious end-game velocity
The project is now in trouble because developer’s suck at estimation through all phases of the development lifecycle. What is a developer to do? That’s right, work until 3 AM every night and never tell any one. Again pride comes into play here, and the result is managers come to find late nights the expectation rather than the exception.
It is my perception that during a project the developer ego grows to compensate for the lack of true insight. Consequently, the manager is presented with a best of both worlds option – the project outcome is on the shoulders of the developer and the manager is allowed to commit to fictitious schedules based on bad information.
What is your opinion? Are managers blind to this behavior? Do they allow it because it benefits them? Do we allow it because we are egotistical or narcissistic?
10 Responses to “Do Managers Prey on Developer Pride?”
We’ve probably all seen this, many of us from both sides of the fence. To me this is why the collaborative (agile) approach to estimating is superior. The estimates tend to be better (less inaccruate) and as the entire team commits the second problem is solved too.
@Jason
I have found exactly the opposite to be true (with some exceptions of course).
Managers tend to taint the estimation process by estimating numbers that fit within the clients budget. As a result, developer estimates are then negotiated farther away from reality and towards the fictitious budget.
Again a play on developer pride (intentional or not).
I do believe that any good manager, software or not, does take pride in their team. Now, I am not saying that you should beat your team into crazy hours and such, but I do think it is important to have a partnership with your team, which in a sense, does turn into pride.
Let me regress a bit. As a new parent I am proud of my little one discovering new things such as rolling over and learning how to sleep through the night. In the same way I have taken pride in my team solving difficult problems and being able to tell a client that we successfully solved a problem they needed help with.
I feel that the real enemy is the estimates themselves. Now, being on both the development side and business side I do understand the want/need/desire for some estimate on what it will take to accomplish a task. But I think that companies, when they desire estimates, do not allow enough time or effort for estimates and after they are produced estimates are not taken for what they are, estimates.
Although not a perfect solution, I think that a good manager should get (write-up, hire a business analyst, etc) a basic set of business requirements that outline the business need. From there it should be passed onto the lead development staff (experience is huge in this space) for a high level estimate, without any knowledge of the client’s budget, and return a range based on man hours. That estimate should then be used as guidance rather then the bible for the project. As the project kicks off there should then be modifications to the estimate with newly learned roadblocks, client modifications, etc.
@Jeremy
You are dead on the money saying that estimates have to be done without knowledge of the budget. If you are tainted with that knowledge your estimations are leaned towards that direction, which are enviably low.
If you haven’t already read Steve McConnell’s Software Estimation: Demystifying the Black Art book. A lot of info on that exact topic is in there.
Although this doesn’t go directly to your post, an interesting part in most of my experiences, even when the estimates didn’t match up with the budget and I was allowed to talk to the client about the situation the client understood why the estimate was different then the budget. Furthermore as changes take place in the project (making a change in estimate required) I have found the clients to be very understanding of the consequence of the change (granted they are easier to work with when given a few different options with the pros and cons of each backed up with some facts).
Sometimes I am amazed at how our perception of the client makes us “afraid” to let them know how much it actually takes to solve the problem. Maybe the real question is not “do managers prey on developer’s pride”, but why don’t developers value their time like other professions?
I think the bigger problem is that when the estimates don’t meet up with reality (and by definition, this will happen) it is only the developers who can fill in the gap. The rest of the team is left waiting. The danger here is that people start to blame the developers right when they are working hardest, leading developers to question what they are working so hard for in the first place.
@mccoyn
I have to disagree. I think the problem isn’t that the estimate is off, it is the unwillingness of clients/managers/etc to accept and COMMUNICATE that estimates will almost always be off. As I wrote earlier, when I prepped the client into understanding what the estimate was, and then I came back to tighten the estimate (which could mean it was higher) I freely communicated the revised numbers to the client which they normally understood and accepted. As we continued to move throughout the project estimates continued to become more accurate, and change orders began to increase in the required effort to implement them. (Can anyone say Kick-off meeting with your client after the sales team had gotten a hold of them to level set expectations?)
With that said I am not saying that all clients understood. And of-course it is always easier when the estimates where closer. As long as we don’t clue clients into an unreal world of exact estimates and limitless changes the longer we all will endure the hardship. Nobody said that it was going to be easy, and if you don’t have a manager that is willing to be honest with the client about things like estimates that maybe they should be looking for an easier job.
Agile (or one of it variations) is currently the best answer we have at managing the convergence of the fluid nature of development and it’s effect on estimate accuracy.
But the topic is Managers and I have seen 2 basic types.
Inflators – Mostly perm, non contract type jobs. These managers try and protect their employees (and themselves) by building in a “fudge factor”. Often as they get more used to their developers’ estimating skills, they adjust this FF. (My estimates got cut in half, while my closest peer’s got tripled. Go figure….)
Ignorers – Pre-bid contract work. Doesn’t matter what you say, the budget dictates the estimate communicated to the client.
——-
As far as ‘playing to our egos’, definately. I had a manager who couldn’t stand me because my sense of accomplishment didn’t rely on his approval. He would goad the other developers into working long hours to accomplish his (ridiculous) estimates/deadlines. I would bust my a$$ when I fell behind my own benchmarks, not his.
As adults, the developers have to better value their and everyone’s time. It’s your job to tell me the manager when I’m off in my expectations. When I ask for an alternative, I want something that is seriously thought through, as my reputation is the first to suffer when the developers get it wrong. They don’t have to go back and beg for more budget and face the embarrassment that will be heaped on them as upper management says “I hired your to get this done – are you incompetent?”.
I always ask people to play the mental game of “what if you only had half the time?” to focus on what is important. Hopefully this cuts ego out of the equation, so you don’t get cut out of the salary budget.
Some constructive criticism: it’s not “mute”,it’s
“moot”.
In any case, nice blog, and you make a lot of good points.