Thread by @tottinge

A manager had "the techies" come and put estimates on an epic.
In order to do that, the team had to work through the design of the epic.
They understood from this design the risks, effort required, uncertainty involved.
Then the managers had them do none of it, probably wisely.

This has happened a few times.
Sometimes PMs will have devs implement a bit of the epic, to see how it's received. Sometimes, it isn't the most important thing and is shelved.
This is frugal, and probably wise.

However, the development teams are depressed.
From their viewpoint, they summoned the motivation and engagement to do all this design work, all this prep, all this hard intellectual labor... and nothing has come of it.

Their time was all "wasted" from their point of view.
And when they actually got to "start" on the epic, it was shelved or deferred or cancelled -- again they feel their time was "wasted"

To hear the architects and developers tell it, "nothing ever gets done around here" and "nobody cares about our hard work."

One architect decided that the team should "go dark" with the work, because if they don't "do all of it now" then there's no telling when they'll get another chance to do the work. A big batch, rather than continuous delivery, so that PMs can't "pull the rug out."

What is being done by the PMs isn't *wrong* and how the developers experience this isn't *wrong*. But it leads to a malaise. People are unhappy and borderline miserable.

A "problem" is the difference between things as perceived and things as desired. -- @JerryWeinberg

The developer expectation that comes from designing a complicated epic, from investing all that time, is that the thing will be built and delivered. Else, why would they have done all this work?

The expectation lingers (Ziegarnik effect) and when the team designs new things, they leave allowances for the un-implemented designs they've worked so hard on -- so not to close the door on doing it.

It's a lot of context and expectation to hold in one's head.
In fact, perhaps it is over-investment.

The PMs weren't making a promise, they were just asking a question.
In doing small bits and waiting for feedback, they're validating the need for a thing.
Maybe that need is too small, or not urgent at all.
Maybe the estimate told them that it shouldn't be built.

Maybe the problem came from separating developers and product people.
Dev is assuming promises PMs aren't making.
PMs are drawing overinvestment in speculative work.
What if they were together in this?
Frugal?
Aligned?