I enjoyed this, although I don't think the word "thermocline" is really necessary or adds much.
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.
I find analogies to physical systems help me generate "non-obvious" questions.
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.
Perhaps. Although someone at a company no longer in business told me about an active attempt to fix this problem by doing what you call (1) Mixing and (2) Radiators. There was a goal of August for the software project.
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.
The article and discussion here all seem to assume that everyone is acting rationally in service to the stated goal(s) of the project, and that problems with the timeline are just honest mistakes. Unfortunately, in my 25 years, I've witnessed a nauseating amount of political infighting that sought to undermine projects in attempts to build and/or preserve internal power for respective managers. This behavior employs the 2 things readily at-hand for ruining estimating: bad-faith technical decisions, and good, old-fashioned feet dragging.
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.
This essay and your last point really resonate with me. I've been surprised at the extent to which raising reasonable concerns, as a preventative or cautionary exercise, becomes equated with sabotage by some. I can think of projects initiated by colleagues that I would not have started because of obvious issues, but that I was nevertheless supportive of because I felt they were worth trying ("I wouldn't do this because of X but if A wants to try I'm on board and will help because if it works it would be good"), that failed, and then I ended up salvaging and cleaning up, but then was accused of sabotaging it from the start.
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.
You're absolutely right; they're not "honest mistakes" but they're not dishonest either. Even anonymity will not work unless the population is so large that they won't know the lone voice is you.
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.
One Agile move I've seen done (among higher-trust teams) is to craft and sprint plan and then float the question:
"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.
Perhaps a better technique would be to go around the room and require everyone to come up with the best argument for why the plan isn't sane, regardless of whether they actually believe their argument.
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.
> (NOTE: my use of male pronouns is deliberate; it is almost always male IT engineers who have this unreasonable optimism. Female IT engineers in my experience are generally far more conservative and realistic, almost to a fault, which is why I prefer them. I just wish they weren’t so hard to find.)
I don’t know why, but something about this aside really rubbed me the wrong way.
It's the classic "look at the coarsest metric and use it to make some kind of a judgement" that basically everyone does. Not getting eaten by a lion is way, way more valuable than occasionally running away from nothing for no reason so human animals can't help themselves. It's in the firmware or hardware. You have to recognize it's happening in your software and decide to look for better clues to overcome what the firmware is doing.
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?
It depends on if you're talking about the "oppressed people can't be racist" kind of theory of oppression, or the "the rules are the rules" kind of oppression.
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.
Probably just the blatant sexism. I wouldn't want to work with someone who thought I was less competent merely because of my gender. I also wouldn't want to work with someone who thought I was hot shit merely because of my gender.
It's not just the blatant sexism but the blatant double-standard sexism. I wouldn't mind working with someone who made a fair assessment of the areas where I would likely be better or worse than average on account of my sex. But getting only the negatives sucks.
> ... IT software development profession largely lacks — or fails to put into place — automated, objective and repeatable metrics that can measure progress and predict project completion with any reasonable degree of accuracy. Instead, we tend to rely on seat-of-the-pants (or, less politely, out-of-one’s-butt) estimations by IT engineers or managers that a given subsystem or application is “80% done”...
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.
> Are we talking about tracking progress or estimating? This seems to conflate the two.
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.
>First, the IT software development profession largely lacks — or fails to put into place — automated, objective and repeatable metrics that can measure progress and predict project completion with any reasonable degree of accuracy
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.
When all managers suddenly change their "green" report to "red", it is because no one wants to be the first to admit defeat, so they informally coordinate, even with the vaguest of hints, to all do so at once.
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.