Three weeks of engineering work. Several senior developers. An already fully booked sprint.
Management's delivery commitment to the customer?
Tomorrow.
And the engineering team's involvement in making that commitment?
Absolutely none.
Just Do Your Magic!
Imagine being told that your team needs to deliver something tomorrow.
You look at the requirements. You know the codebase. You understand the complexity. You estimate that it would take several senior engineers roughly three weeks to complete.
Except nobody asked for your estimate.
The commitment has already been made.
But don't worry! Management has full confidence in you.
"Do your magic!"
"I know you guys can pull this off!"
Apparently, confidence is now a substitute for capacity planning.
The Inevitable Happens
Spoiler alert: We didn't deliver.
Not because the team was incompetent. Not because we weren't committed. And certainly not because we weren't working hard enough.
We simply couldn't compress three weeks of engineering into a single day.
And yet, somehow, the engineering team ended up being held accountable for missing a deadline we had never agreed to.
The people who made the promise weren't the ones expected to explain why it couldn't be fulfilled.
Sound familiar?
Commitments Flow Downward, Blame Follows
This is a management antipattern I've encountered more than once throughout my career.
The pattern is remarkably consistent:
- Management makes a commitment without consulting engineering.
- Engineering explains why the timeline is unrealistic.
- The explanation is interpreted as negativity or a lack of commitment.
- The team is pressured to deliver anyway.
- Reality inevitably wins.
- Engineering gets blamed for the missed deadline.
And somehow, the lesson management takes away is that engineering needs to improve its estimation or execution.
Not that commitments should be based on actual estimates in the first place.
The Real Cost Isn't the Missed Deadline
One missed deadline is rarely catastrophic.
But repeatedly putting engineers into situations where failure is practically guaranteed does something much worse.
It destroys trust.
Engineers stop believing that their estimates matter. They become reluctant to raise concerns. Some eventually stop speaking up altogether.
Why bother explaining technical reality when the decision has already been made?
Eventually, the team learns that being realistic is punished while making impossible promises is rewarded.
And that's a terrible environment in which to build software.
Leadership Isn't Making Promises for Other People
Good engineering leadership doesn't mean never making ambitious commitments.
It means understanding the difference between ambition and fantasy.
It means involving the people who will actually perform the work before promising a delivery date.
And when something goes wrong, it means taking responsibility for the decisions that created the situation.
You can't demand accountability from engineers for commitments they were never allowed to participate in making.
This is another real experience from my Professional Antipatterns series, where I write about the dysfunctional workplace practices I've encountered throughout my software engineering career.
You can read the full original story here:
Professional Antipatterns: When Management Commits, Engineering Pays
I'm curious: Have you ever been held responsible for missing a deadline you never agreed to?
And more importantly, what happened when you pushed back?
Top comments (0)