The Thermocline of Truth (2008)
brucefwebster.com
brucefwebster.com
Daniel Kahneman wrote about The Planning Fallacy (https://en.wikipedia.org/wiki/Planning_fallacy) in 1979 and it's been studied in great detail. My personal cure (YMMV) is the Prediction Market, where people place bets on the final date (of course, you need to remove any temptation to interfere and make your own bet come true!).
Once you realize it's a human failing and we're all subject to it, you get a little more realistic. Maybe.
What are some ways to break up a physical thermocline?
1. Mixing and turbulent flow between layers;
2. Radiators that transverse layers;
3. Redistribution of heat source.
What might these look like when translated into a business "thermocline"?
1. Break up the management hierarchy and distribute responsibility in a homogeneous, egalitarian way;
2. Make sure that at every meeting, no matter the hierarchy level, members from all levels are present;
3. Make management also deal with low-level GitLab tasks on a frequent basis.
Whether the above proposals actually work is big question; however, thanks to the physical analogy, the pretty much immediately came to mind. When ideas come cheap, it's easier to keep discarding them until a truly good one comes along.
In practical terms: top management made a serious effort to ask the engineers when the project would really be done, and without the presence of middle management. The consensus was, overwhelmingly, January.
When this was shared among the top managers, they voted to keep the August deadline. Because they were committed to it.
If you're guessing that it really finished in January, you must have heard this story before :)
The moral is, you can expose them to accurate dates, but if they refuse to hear it, there's nothing you can do.
"OK, we've biting off that amount of effort for the timebox. Let's go around the room and have everyone opine on whether or not this is sane."
Obviously a small group of professionals here, but still.
The overarching point is whether the corporate culture supports communication. In my experience, comms is inverse to size. Less is more. People don't scale well or easily to large organizations.
That way the argument isn't attached to anyone's ego, and uncomfortable truths can be spoken with plausible deniability. It only takes one person to "jokingly" bring up how previous estimates were over-optimistic, for example, to which other people can nod and hum in agreement.
I've spent most of my career in Fortune 250's, but I've seen this happen in a couple of very small companies too. As someone with a personality that is honest to a fault, this has caused me a significant amount of distress in my career. More than once, I've been the lone voice in the wilderness crying about the forthcoming train wrecks, only to be ignored, and then ultimately blamed for the crash, because I was the only one that people could point to for having said anything about it at all.
In my those situations, it was accompanied by many other operational and management problems. Specifically, failures of communication and certain persons' perspectives being allowed to drown out all others the further you went up the administrative hierarchy.
What they really are is: peer pressure. If all your peers have signed up for May 1 and you "know" it'll really be September, you'll incur their displeasure (or worse) if you say that. As you found out.
I don’t know why, but something about this aside really rubbed me the wrong way.
It's the same kind of thing that causes a person who has been robbed to conclude that anyone who matches some kind of obvious characteristics of the person who robbed them to be the same kind of "other" and to diligently avoid them. You can't blame them! They got robbed! That's traumatic.
What's too bad is when the person never examines their beliefs for where they're wrong and to try and update their model of the world. Not every female engineer is amazing and not every male one has too much bravado. Not everyone who is wearing the same clothes as the mugger is a mugger. Not everyone who is wearing different clothes is not a mugger.
But also life is short and the heuristics we all use every day serve us well enough that to examine every single one would mean you couldn't do much at all with your life. It's too bad but try not to take it personally. We all do it and we rarely know in what ways we are.
Does this strike you as an odd way to respond to cut and dry sexism? Would this response be as reasonable and forgiving if the genders in the quoted aside were reversed?
Honestly it wasn't written to the person to say "it's totally OK for a person to speak this way" it was more of a "look lots of people are going to rub you the wrong way, here's a way to think about it that involves them being accidentally ignorant rather than purposefully malicious".
I'm not saying a person should have to have this attitude and "let everyone get away with it" but I can say that anyone who does have this attitude will probably have a happier personal life. The decision is up to all of us.
Here was where I started to realize that this was going to be a bit of a hand-wavy ("out-of-one's-butt") argument. Are we talking about tracking progress or estimating? This seems to conflate the two.
> Second, IT engineers by nature tend to be optimists, ...
Really? Optimists? I don't think that word means what you think it means.
This "optimism" wouldn't have anything to do with being pressured by management to give more favorable estimates, would it?
What makes both estimation and progress tracking difficult or impossible is a lack of good requirements specifications or use cases. I have never worked for a company where anyone took these seriously. Sure, they talked a good line, but never seemed to follow through. There's always an excuse. The thing is, if you don't know what you want and/or can't express it, you're unlikely to get what you want.
Estimating in IT is predicting the future, which is done "out-of-ones-butt". Tracking the progress is supposedly about the present, but it's necessarily linked with predicting the future, because you can't know how far you are if you don't know how much is ahead of you. Without that you can say only nearly useless things like, "I worked on this x hours so far." or "I wrote so many files/lines/functions".
> > Second, IT engineers by nature tend to be optimists, ... > Really? Optimists? I don't think that word means what you think it means.
Really. We are absurdly optimist. Even when we are trying to be reasonably pessimistic with our visions of the future of the project it usually turns out we were unreasonably optimistic.
And we have to be optimistic to do our jobs. Every day we are proven wrong by a machine but we need to keep believing that we can get things right to keep working.
In order to have automated metrics you would have to have a complete and accurate specification that never changes. Something that doesn't exist.
>Second, IT engineers by nature tend to be optimists
No, Management tends to demand more than can be delivered, as pressured by sales.
>Female IT engineers in my experience are generally far more conservative and realistic
Women aren't as stupid as men, and actually want something approaching work/life balance. You might want to consider older men, who have less testosterone poisoning as an additional source of wisdom.
I agree with points 3 and 4.
Management that doesn't actually understand how "the sausage is made" will always face a thermocline/impedance mismatch. The effect of a good working relationship with trust in both directions can greatly help address the obstacles it imposes.
It might help to offer some education as to how things work at the top, the pressures upper management faces, and how it drives their decision making, to the lower ranks of the org chart.
I challenge that assumption.
First you automate metrics for the specified work, then have an estimate for changes and give management more data on the choice to make changes.