12/12/2010 5:36:58 PM #

I find these type of managers are very common in the IT world, possibly because they used to write code themselves 10 or 20 years ago and remember their own coding career with rose colored glasses.

Craig |

12/15/2010 1:34:04 PM #

I think this is an excellent post and agree with much of it, but I'm going to put in a word for "these type of managers" (PHBs) that's a bit more complicated than simply writing them off as either being stupid, evil, self-serving, or (at best) just not understanding development. I think it's more complicated than that, and that just encouraging leaders to "trust your folks" both isn't likely to work, and in fact may not be a good idea at all.

First, there are a couple of forces acting on management that need to be considered:

1. In general, I think you need to start out with the assumption that these are generally reasonably good--sometimes outstandingly good--folks, but folks who didn’t get where they are by just accepting things as givens, especially things like "can’t be done" or "isn’t realistic." They’re achievers with a history of finding ways to get things done. A simple "Trust me--won't happen" won't work. That's not something they'e likely to belive about the world.
2.  I think it's generally true of everyone that no matter what you do, you want to think it matters. Managers are no different, and saying "No matter what deadlines or priorities you set, the baby is going to take nine months" doesn’t sit well even if it's true--you’re basically saying "Your leadership is totally ineffective and irrelevant, and if you went to your office for 9 months and played solitaire it wouldn’t change a thing." See point 1--that’s not something they’re likely to believe about themselves and their place in the world.
3. Another general human universal: the mind is infinitely adaptable to finding credible that which it finds necessary--that’s how terminal patients find courage. At all layers of middle management, there’s a terrible pressure to find credible whatever--for possibly completely unrelated reasons--HAS to be true. Conversely, we simply don't need much evidence--or any really--to deny that which is unthinkable (that CAN’T be a tiger in that tree; my girlfriend would NEVER be unfaithful, there HAS to be a God, etc.) If we need a 15% growth margin to survive, or I need to show a 10% productivity gain to get a promotion or hang on to my job, then I’m going to believe that those things are possible, and therefore that anything necessary for those must be possible as well. Basically--arbitary management goals aren't arbitrary, and you need to understand their source and motivations.
  And if those pressures lead to unrealistic situation assessments, that’s not peculiar to management either. It’s us in general. You simply see it in management when decisions start getting made and policies start being set based on what the manager believes needs to be the case rather than what you believe to be the case. But again, remember point 1: the management team has a tendency to believe that what they want can and does make a difference. They have to believe that.
4. Even a manager aware of all this and who strives to stay in touch with "the real" is still vulnerable to the confirmatory bias (http://en.wikipedia.org/wiki/Confirmation_bias). Additionally, there are inherent sociological forces that conspire against a manager who wants to know the truth: organizations are quite phenomenally adept at hiding the truth from bosses. And in light of that, just ‘trusting’ your immediate subordinates is probably the worst thing you can do. People filter information--and that’s unavoidable. So it’s very hard for accurate news to travel up hill in any organization. Arguably, taking the word of your direct reports at face value all the time is asking for disaster--especially in a long chain of reports. At each transfer point, information is being lost.

But the take-away here--for me at least--isn’t all bad. Because the truth is that there isn’t a direct f(x) relationship between power/danger and honest communication: equality doesn’t guarantee communication, and inequality doesn’t actually prevent it--it just makes it somewhat less likely unless the power relationship itself is acknowledged and treated honestly.

If you trace out the implications of the statement that at every step along the way, people face tremendous pressure to "provide feedback to their superiors that their superiors want to hear," (http://en.wikipedia.org/wiki/Celine%27s_laws) then it becomes a truism that the guy at the top is necessarily the least informed member of the organization. Most of the people shading the truth to him don’t even know the truth themselves.

But the pyramids still get built, and that's in some part due to the fact that good managers don’t just trust--they walk around and look.

bobD

bob dawson |

12/20/2010 12:27:44 AM #

That post describes nearly every firm I've ever worked for. In fact, the commonality of that situation is what changed my politics.

I think part of the problem is that developers don't actually realize how long it will take them to create something. They always underestimate, because they think only in terms of the time it would take them to type the code. Managers see this and eventually just dismiss the always-wrong developer estimates out of hand. So now their estimates are completely untethered, and they tend to drift toward the marketing and business needs of the company. Eventually that is ALL the drives the estimates. By this point the devs are totally disillusioned and dispirited and the inevitable departures of key devs kills the whole thing. This causes upper management to replace the "obviously incompetent" middle managers, and the whole cycle restarts.

I've actually been at firms where they did not even bother renaming the database they were reusing from the prior bankruptcy.

John Jacobson |

12/20/2010 9:59:37 AM #

Good points in this post, Nick.

IMHO, you mix two topics in this story:
Leadership and estimation.


As a former officer, you know that a good leader should use the style of leadership that the situation requires.  Sometimes you need to give your soldiers an order without any further explanation, and you need your soldiers to follow that order without questioning it.  (Sounds like brainwashing, but in the battlefield this might be the only way to survive.  I'm not sure if this kind of leadership is really needed in business life?)
On the other hand you might have a complete different situations that allows you to give your team a case and some terms, and let them decide all by themselves how to solve that case.  These are the extremes, and there is a variety of styles in between.

To succeed as a good leader, you need to choose the appropriate style, and you need to carry out the whole specter of leadership styles very well.



When it comes to the estimate, an estimation is an ESTIMATE, not some gut feeling that should be negotiated.

As a software planner, you need to make this clear to the executives.  The estimate is based on objective facts and some analytic work, not on any subjective gut feeling.  
Don't negotiate the estimates. Negotiate the commitments that forms the estimate.  (I.e. features, people, etc)


The estimate may be wrong. Or should I say: The estimate is always wrong (even the pregnant lady can't plan the delivery date accurate).  But the whole point is that the estimation isn't a target you work towards during the development process.  Estimation is a process.  You need to follow up your estimation regularly and compare them to the actual progress.

If only 20% of the work is done after 3 months, there is no way in h___ you will manage to deliver in 8 months.  Your team will not suddenly work twice as fast during the next 3 months, just to compensate for the delay in the previous months.
At this point you need to make a decision and adjust the facts in the estimation.  Fewer features, more people, postponed delivery, or even cut off the whole project.

An estimate should be a tool in the executives toolbox.  They need good estimates to make the right decisions, they don't need optimistic estimates.




And one last, little tip:  Don't make single point estimates!  Instead you should say that it is a 95% probability that the project will be done in 12-16 months, and that the estimation will be more accurate as you progress in the project.  I guess that we all know the cone of uncertainty...

Jørn E. Angeltveit |

12/21/2010 3:53:14 PM #

Those who forget the past is condemned to repeat it.

Most of time, tasks are given but no record is taken of how the solution was made and how that situation was dealt (and how much time).

So, the estimates are always skewed because there's not a objetive record where the estimated can be analised.

Example:
-> Code for drawing an edit widget on the screen.
   There are any widget similar to what's planned to be made in recent past (ours or of a retired team) ? How much time it took? What were the issues with it?
   Gut feeling: 15 days.
   Past development: 45 days
   Most probable: 25-35
   (Of course, all these numbers are taken from thin air, but I've saw this situation and inverse one on the past).

Without that kind of data, how you estimate 25-35? Maybe just from your personal experience. Or you simply believe and gives an fat margin: 20 days.

Without an past experience recorded, all you can do is guesses - you can guess very well, you can guess poorly and you can guess pretty awfully.

With the records, you can sharp your estimates using the past and reduce the risk - and let it goes to the really new developments (which, in the context, are the widgets that were not even tried in the past).

A little off-topic: that's what I liked when worked on a job that used StarTeam (it's a shame it's so expensive) - you can track everything and compare timings using the client queries...

My estimates got much better with that help.

Fabricio Araujo |

12/12/2010 3:05:40 PM #

Pingback from topsy.com

Twitter Trackbacks for
        
        Nick Hodges | Listening
        [nickhodges.com]
        on Topsy.com

topsy.com |

12/12/2010 5:44:03 PM #

Pingback from sjover.com

Delphi básico » Nos deja la semana 51 – 2010

sjover.com |