One evening a chat arrived from my manager. It was not a question. It was an announcement, in four messages:

Nothing in it asks about the current sprint, about capacity, about risk, or about whether “it” was even understood by the people expected to build it. The commitment had already been made. The chat was the notification.

This is the same person as the CTO from the Spec Kit workshop, the one who answered a demo of spec-driven development with “we’ll go with agentic development”. I mention it once because it matters for the rest of this post: this was a pattern, not a one-off.

What happened

“It” was a large extension of a multi-service system. A customer required it before they would sign a deal. Doing it properly needed serious planning and big refactors, and realistically it was at least three weeks of work for several senior engineers.

The email went to the coworker who owned the customer contact, so the promise went straight to the customer side. And “deliver tomorrow” meant exactly that: done the next day. Three weeks is fifteen working days, so the promise was off by a factor of at least fifteen per engineer, before counting that the estimate needed more than one of them.

Nobody had free hands to absorb it. Every engineer was already fully planned for the sprint, and the product was growing and changing aggressively. Nobody on the team was asked before the email went out.

Four messages, read closely

Each line of that chat does a specific kind of damage:

• “I’m gonna send an E-Mail tonight to [REDACTED] and others committing to it”: the decision is made by the one person who does not do the work, at an hour when nobody can push back. A commitment replaces the estimate instead of following it.
• “so we have to make sure we deliver tomorrow”: “we” here means “you”. The risk is transferred to the team, while the authority to make the promise stays with the manager.
• “but yeah, do your magic!”: engineering is reframed as magic, and magic has no cost, no trade-off, and needs no planning. If it works, it was trust. If it fails, the magic was weak.
• “I have full trust”: it sounds like support and works like a trap. Trust given without asking anything is not trust. It is blame loaded in advance. (The message got one heart reaction. Someone had to be polite.)

Steve McConnell draws the line that this chat erases in Software Estimation: Demystifying the Black Art. An estimate is a prediction of how long a project will take. A target is a statement of a desirable business objective. A commitment is a promise to deliver defined functionality at a specific level of quality by a certain date, and it can match the estimate or be more aggressive or more conservative than it. His point is that the three get confused, typically when someone asks for an estimate but means a commitment to a target. Here nobody even asked for the estimate. The target went straight into the commitment.

The team worked in sprints, and the Scrum Guide is explicit about what happens during a Sprint: “No changes are made that would endanger the Sprint Goal”, and “Scope may be clarified and renegotiated with the Product Owner as more is learned.” It also says “The Sprint Backlog is a plan by and for the Developers.” An overnight external commitment skips all three: it endangers the goal, it renegotiates nothing, and it rewrites the Developers’ plan without them.

Who committed to what

The deadline was missed, as anyone who had looked at the work could have predicted.

The engineering team was then scolded for committing to something it could not deliver. The scolding came from the manager himself, the CEO, the director of engineering, and the vice product manager. The manager was furious that “we” could not do it. The arithmetic did not come up.

We pointed out more than once that the commitment had been the manager’s, not ours. It was as if nobody heard it. His own part in it was never acknowledged, so in the official version of events he did nothing wrong. The team was blamed for committing, in a story where the only commitment was a chat message that said “committing to it”.

Then came the punchline. The customer realized the product was far from the quality they needed, and the missed deadline gave them a convenient reason to cancel. The deal the overnight commitment was meant to save was never really there. We got all of the damage and none of the upside.

Ron Westrum’s typology of organizational cultures, which DORA builds on, has a row for exactly this. In a pathological, power-oriented culture, messengers are punished, responsibilities are shirked, and failure leads to scapegoating. In a generative culture, failure leads to inquiry. DORA’s research finds that a high-trust culture that emphasizes information flow is predictive of software delivery performance, which is a measurable reason to care beyond fairness.

A manager as a morale sink

The missed deadline was one incident. The habits behind it outlast any single incident, and each of them pulls morale down on its own.

• Proximity to power as immunity: the manager sat close to the top, so the failure was reframed as an engineering planning problem. The person who made the plan was never part of the conversation about why the plan failed.
• Credit up, blame down: on success the story is “I committed and we delivered”. On failure it becomes “the team can’t estimate”.
• Rewarding the visible over the valuable: a promise in an email is visible to the people who matter. The work that keeps a sprint healthy, such as refactoring, reviews, and saying no, is not. It is the same root as being measured by commit count and as a promotion that never came: rewarding what is easy to see.
• Learned helplessness: after a few rounds of this, engineers stop pushing back and stop estimating honestly, because why bother. They start padding, or quietly looking elsewhere. The promotion post made the point that matters here too: the quiet engineer is the one you are about to lose.

Gallup’s Randall Beck and Jim Harter report that managers account for at least 70% of the variance in employee engagement scores across business units. Team morale, in other words, is to a large degree a property of the manager.

How I got out

The first step was escaping the manager. I went to higher management and asked to move to a team he was not in charge of, and I got out from under him directly.

The second step was escaping the company, because it did not stay one manager’s habit. Over time the same pattern spread to every team: commitments made above, delivered below, and blamed below. The signs were hard to miss:

• many people were leaving, and the general mood was bad in a way everyone could feel
• higher management presented things as already delivered that did not exist, and that no team had been consulted about
• “immediate” tickets for various customers arrived in the middle of sprints
• priorities changed day by day and sometimes hour by hour, owned not by one person but by a group of managers, so planning ahead was impossible

That last one is exactly what the Scrum Guide guards against when it says “The Product Owner is one person, not a committee.” Priority by committee means nobody owns the order of the work, so everyone can change it.

Culture follows the top. When a habit lives at CTO level, it becomes the company’s operating model, because every manager below learns that this is how commitments are made and how failure is explained. My read is that this is how a culture slides toward the pathological end of the Westrum typology: through what its leaders reward and what they punish.

I left, and I landed a Principal role. The job search and the promotion story that came before it have the details, so I will not retell them. I was lucky, and I know it. Not everyone can leave: the market, a visa, a family, or plain timing can make it impossible, and this is not a post telling anyone to just quit.

The best fix I found for a manager like this was distance. That is not a recommendation to the company. It is a description of what it loses.

What a good version looks like

Same evening, same urgency, different chat:

The stakeholder needs X by tomorrow. Before I reply: is it doable without blowing up the sprint? What would we drop? If not, what can we realistically promise?

The fix isn’t a manager who never commits under pressure. It’s a manager who asks first, even when the answer has to come back within the hour:

• Ask before committing: a fast answer from the team is still an answer from the people who know the work.
• Commit to a range or a partial: promise what the estimate supports, not what the target wishes for.
• Make the trade-off explicit: name what slips to make room, and own that in the email to the customer side.
• Own the miss: if it goes wrong anyway, “I committed without checking capacity” in the retro is one sentence, and it returns a lot of trust.
• Let the team say no: trust that cannot hear a no is not trust.

Why this is an antipattern

Committing a team on its behalf, overnight and without asking, and then attributing the failure to the team’s planning, is an antipattern because the intent is to look responsive to stakeholders and the effect is to destroy the only thing that makes responsiveness sustainable: honest estimates and a team that trusts its manager. It incentivizes engineers to stop estimating honestly, to stop pushing back, and eventually to leave. The cost is concrete: a broken sprint, a missed or degraded delivery, a team blamed for a plan it never made, and morale that a manager with more authority than accountability keeps draining. When that manager sits at the top, the habit stops being one person’s and becomes the company’s, and the people who can leave, do.

The rest of what I work on lives at lezli01.is-a.dev.