This article is for leaders who want honest plans from teams without pressuring them into false certainty.
Most teams do not need a leader to pressure them into overcommitting.
They’ll usually do it on their own.
That may sound surprising. We often think of software developers as skeptical or cynical. But in my experience, developers are often deeply optimistic. They believe in making things better. They’ve seen how technology can improve lives and change businesses. That optimism is part of what makes them good at what they do.
It also shows up in their estimates.
Ask a team how much they can do in a sprint, a quarter, or by the end of the year, and most teams will choose a bit too much. Sometimes a lot too much.
That doesn’t mean they are careless. It means they are human.
And that is exactly why leaders need to be careful. If a team is already prone to overcommitting on its own, any added pressure from above can push that team into dramatically overcommitting.
I learned this the hard way early in my career. When I was first promoted into leading a team, I thought deadlines would be pretty simple. My management philosophy, if you could call it that, was this: ask team members for estimates, assume those estimates are optimistic, and then hold people to their own optimistic estimates.
That did not work.
The problem was not that my team was irresponsible. The problem was that I was treating optimism like a contract.
Teams Are Already Optimistic
This is the first thing I want leaders to understand: overcommitment usually starts before a leader says a word.
Software teams often make reasonable plans based on incomplete information. They do their best. They look at the work in front of them. They make assumptions about what will go well. They imagine a path through the work and estimate based on that path.
That is normal.
But because they are optimistic, they often lean toward the best or near-best case without realizing it. And because software work contains uncertainty, even a sensible plan can fail.
Think about driving across town for an appointment. You consider the distance, the time of day, and the usual traffic. You conclude that 30 minutes is enough, and most of the time you’re right. But one day a train blocks the tracks for 10 minutes, and suddenly you’re late.
Your estimate was not foolish. It was the best estimate. It just failed in that instance because of bad luck.
The same thing happens to teams.
Sometimes a team really does plan poorly. But sometimes the team chose the most likely outcome and still missed because uncertainty showed up in an inconvenient form.
Leaders need to make room for that reality.
How Leadership Pressure Causes Teams To Overcommit
Because teams are already optimistic, pressure matters more than many leaders realize.
Sometimes leaders apply pressure intentionally. They want more, they want it sooner, and they say so directly.
But pressure also shows up unintentionally.
A leader can create pressure with a question, a tone of voice, or even body language. I once worked with a leader named Erin who was a genuinely upbeat and positive person. As she walked through the office, she would greet people with questions like, “Getting a lot done today?”
She did not mean anything harmful by it. In fact, her bigger concern was quality. She wanted the team to slow down enough to do good work. But what the team heard was daily pressure about productivity.
When I pointed this out, she changed her greeting to something deliberately silly: “Staying bug-free today?”
That small change mattered. It signaled what she actually cared about. And because it was almost humorous, it broke the old pattern.
That example sticks with me because it shows how easy it is for leaders to communicate one thing and be heard another way.
Even a simple “How are things going?” can feel like pressure if team members hear it as, “Tell me you’re on track.”
What Pressure Does To Teams
Pressure does not remove uncertainty. It changes how teams behave around uncertainty.
When teams feel pressure, they tend to choose their most optimistic estimate instead of their most realistic one. They become less willing to expose risks. They stop looking very hard for what could go wrong, partly because discovering bad news becomes uncomfortable.
The risks do not disappear. They just go underground.
That is one of the most dangerous effects of pressure. It doesn’t just distort what teams say. It distorts what they are willing to examine.
Sometimes pressure also pushes teams toward longer hours. In a true crisis, working a bit extra this week may be fine. But that is not a long-term strategy for sustained productivity. Eventually, excessive effort leads to fatigue, mistakes, and lower quality.
And once quality starts slipping, teams often make the situation worse by rushing. They start saying things like, “We’ll clean that up later,” or “We can do that in another sprint.”
Urgency is fine. Rushing is not.
I like the distinction often attributed to John Wooden: be quick, but don’t hurry. That is exactly what leaders should want from teams. Move with energy, but not with panic.
Forecast vs. Plan vs. Commitment
One reason leaders and teams get into trouble is that they use the same words to mean different things.
A forecast is a prediction about the future.
A plan is what we expect to do based on that forecast.
A commitment is what we are confident we will do, with enough margin to make that credible.
Those are not interchangeable.
A team may estimate individual backlog items and, from those estimates, assemble a sprint plan or a three-month milestone plan. That plan can be thoughtful, disciplined, and useful. But it is still not a guarantee.
A commitment is different. A commitment requires margin.
If I think I can drive across town in 30 minutes, that is a plan. If I need to truly commit to being there on time, I might leave 40 minutes early. The extra time is not waste. It is the cost of certainty.
Leaders understand this idea in other parts of business. A company may internally forecast earnings of $5 per share. But when it communicates externally, it might commit more conservatively to $4.50. Same business, same leaders, same reality. They understand that commitment requires room for things to go wrong.
Software development is no different.
So yes, leaders can ask for commitments. They can ask for commitment to a sprint, to a feature, or to a multi-month goal. But they need to recognize that committed scope must be smaller than planned scope, and planned scope must usually be smaller than optimistic scope.
How Anchoring Pushes Teams Into Overcommitment
One of the most common ways leaders cause overcommitment is through anchoring.
Anchoring happens when a leader frames the answer before the team has done its own thinking.
A leader asks, “Can you deliver these features in three months?”
That sounds innocent enough. But it is not neutral. The team has now heard both the amount of work and the desired timeframe. They know what answer the leader is hoping for. They want to be helpful. They want to please people. So instead of independently determining what is realistic, they start searching for a path to yes.
I saw this vividly years ago when I was a VP of development at a public company. My boss asked whether a certain product could be delivered by the end of the year. We needed revenue in the current year, and that product could help.
I went back with my team and worked through the plan. Our initial answer was something like mid-February. We cut some things, revised the plan, and managed to get a plan that said mid-December. Great, we thought. We would meet the business need.
What I had failed to account for was that our customers would not make beta testers available in November and December. They were too busy. That caused the release to slip into January.
Now step back and look at what happened. On an 11-month effort, we missed by only a couple of weeks. That is actually pretty good planning. But because the whole point was to get revenue booked that year, the outcome was a failure.
And I think the failure began with the question.
Had my boss asked, “When can we get this?” I likely would have returned with February or March. That would have led to the correct business decision: don’t do the project for this purpose. But “Can you do it by the end of the year?” anchored us to a desired answer, and we (I) found a way to almost get there.
Almost was not enough.
Ask For Truth, Not Reassurance
The best leaders make it clear what they are asking for.
Do they want a forecast? A plan? A commitment?
They also make it safe to tell the truth.
That safety does not come from saying, “Bring me good news.” It comes from asking questions that invite reality:
- What assumptions are you making that may not hold true?
- What could derail this plan?
- What dependencies are built into this?
- Is this your optimistic case, most likely case, or pessimistic case?
- What should I know about the thinking behind this?
Those are very different from questions that imply, “Please reassure me.”
The difference matters. A healthy check-in is not one that makes the team say everything is fine. A healthy check-in is one that helps the team surface what may not be fine.
And when a leader hears bad news, the most important first response may simply be: “Thanks for telling me.”
That one sentence tells the team that truth is valued.
Want a practical version of this? Download the Overcommitment Toolkit for Leaders. It includes a short diagnostic, a simple guide to forecast vs. plan vs. commitment, and 10 better planning questions.
Planning Should Be A Shared Problem
This is the leadership habit I most want to change.
Too often, leaders treat planning as the team’s problem alone. The leader asks for a plan. The team provides one. Then the leader either accepts it or says, in effect, “That’s not good enough. Hit the date anyway.”
That is not planning. That is pressure.
Planning should be a dialogue.
A team should present its plan. The leader should acknowledge the effort that went into it. And if the leader hoped for more, the response should be something like: “I was hoping for more, sooner. What can I do to help us achieve that?”
That changes everything.
Now the conversation becomes collaborative. Perhaps one large feature can be removed. Perhaps a lower-priority outcome can move to a later release. Perhaps a couple of extra weeks changes the risk dramatically. Perhaps adding a person helps. Perhaps the mobile app can come later.
The point is not that every problem has an easy answer. The point is that the answer should not be forced entirely onto the team.
Planning is a shared problem.
The Cost Of Repeated Overcommitment
When teams repeatedly overcommit, the first damage leaders notice is usually missed goals.
The deeper damage is loss of credibility.
If a team fails to achieve its sprint goal or milestone sprint after sprint, eventually no one trusts the next plan. That is hard on everyone. It is hard on leaders because they stop getting usable information. It is hard on teams because even when they finally tell the truth, nobody believes them.
Repeated overcommitment teaches the organization to distrust reality.
That is why this issue matters so much. This is not just about making one sprint go better. It is about preserving the ability of a team and its leaders to have honest, useful planning conversations.
What Leaders Should Ask Instead
If you are a leader, here is the simplest shift I can offer.
Stop asking questions that reveal the answer you want.
When a leader asks, “Can you do this in three months?” the team has already been anchored. They now know the date the leader wants, and many teams will begin looking for a way to make that answer come out yes.
A better question is: “Here is what I need. When can you do it?”
Let the team answer that question first. Then compare their answer to your hoped-for date. If the answer is later than you want, don’t turn that into pressure. Turn it into a conversation.
Then follow that with questions like:
- What are you assuming will go well?
- What could derail this?
- What dependencies matter here?
- Is this a forecast, a plan, or a commitment?
- What can we do together to improve the outcome?
Those questions do not reduce accountability. They improve it. They help teams think more clearly, speak more honestly, and plan more credibly.
That is what leaders should want.
Teams do not overcommit because they are irresponsible. They overcommit because optimism is natural, software work is uncertain, and leadership behavior shapes what teams feel safe saying.
The best leaders do not squeeze harder. They create the conditions for truth. They distinguish forecasts from commitments. And they treat ambitious delivery as a shared problem to solve together.
That is how you get better plans. And, over time, better outcomes.
Want Help Putting This into Practice?
Download the Overcommitment Toolkit for Leaders. It includes a quick diagnostic to spot overcommitment patterns, a guide to separating forecasts from commitments, and a set of better planning questions you can use to get more honest answers from teams.
Last update: April 14th, 2026
