You’re sitting in the quarterly business review. The sales VP is staring at you across the conference table, voice rising: “You said I’d have this feature by March 15th. Why don’t I have it? My team has been promising customers this functionality for months.”
The project ran late. The estimates were wrong. Again. You watch the CFO’s expression harden as trust evaporates in real time. The response is always the same: better planning, more detailed estimates, stricter accountability for commitments.
Every software leader has been in this conversation. The project ran late. The estimates were wrong. Again. The response is always the same: better planning, more detailed estimates, stricter accountability for commitments.
This is the trap that’s killing software teams across the industry. The pursuit of predictability through estimates and velocity tracking doesn’t just fail. It actively makes things worse. It creates the dysfunction it’s supposed to prevent.
I’ve spent 20+ years watching teams destroy themselves chasing false certainty. The harder organizations squeeze for predictability, the more unpredictable they become. The more they demand accurate estimates, the less accurate estimates get. The more they track velocity as a performance metric, the less value gets delivered.
The chase for predictability in software development is not just difficult or misguided. It’s futile. And it’s time to stop.
The real problem starts upstream
Before we talk about why estimates fail, let’s acknowledge where most “predictability” problems actually originate: missing strategy, absent context, and broken priorities.
Teams get jerked in different directions because leadership hasn’t made the hard choices about what matters most. They pile on work without completing anything because there’s no shared understanding of value. They make decisions in the dark because business context never flows down to the people doing the work.
When executives demand “when will this be done?” they’re often really asking “should we be doing this at all?” But instead of having that strategic conversation, they demand a number and pretend it represents certainty.
You don’t fix chaos with tighter estimates. You fix it with alignment and clarity.
Why leaders turn to control mechanisms
The desire for predictability is understandable. Budgets need approval. Stakeholders need updates. Boards demand timelines. When uncertainty rises, predictability becomes a management proxy for control, accountability, and efficiency.
The fear driving this is real: blown budgets, missed deadlines, disappointed customers. But estimates and velocity tracking aren’t solutions to these problems. They’re security theater that creates comfortable illusions while the real issues fester.
Here’s what actually happens when organizations chase predictability:
- Teams start gaming metrics to “look predictable”
- Engineers pad estimates to protect themselves
- Quality suffers as corners get cut to hit arbitrary deadlines
- Innovation dies as teams avoid ambitious work
- The best people leave because they’re tired of defending inaccurate guesses
The pursuit of false certainty destroys the things that create real value.
Software is research, not manufacturing
Software development is fundamentally R&D work. Every project involves a unique combination of people, technology, constraints, and business context. Even “repeat” projects play out completely differently because the environment is never identical.
This makes software complex, not complicated. And the distinction matters.
Complicated problems have knowable solutions. Build a bridge, manufacture a car, process tax returns—these are complicated but ultimately predictable because we understand the underlying mechanics.
Complex problems are emergent and unpredictable. You can’t analyze your way to certainty because the act of building software changes what you’re building. Requirements evolve. Technology limitations surface. User needs shift. Team dynamics matter more than individual skills.
When we treat software like manufacturing—measure twice, cut once, follow the blueprint—we apply the wrong tools and create the wrong expectations. We try to force complexity into the shape of simplicity, which Heinz von Foerster called “trivialization.”
The planning fallacy destroys even expert estimates
Kahneman and Tversky’s research on the planning fallacy shows that humans systematically underestimate time, effort, and cost while ignoring past experience. We anchor on initial optimism and focus on best-case scenarios.
The cruel irony is that the very people best positioned to know how hard something is are also the ones most likely to underestimate it. Experienced engineers fall into this trap as much as anyone else. They get caught in the “inside view” of their current plan instead of the “outside view” of what actually happened in similar past projects.
This creates a toxic cycle:
- Missed estimates create pressure for more accurate estimates
- Pressure leads to corner-cutting and technical debt
- Technical debt makes future work even less predictable
- Teams start padding estimates and gaming velocity
- The whole system becomes optimized for looking predictable rather than being valuable
Every organization I’ve worked with goes through this cycle. The response is always the same: more estimation rigor, better tracking, stricter accountability. It never works because it’s treating the symptom, not the cause.
The tyranny of estimates and velocity
Story points and velocity aren’t just ineffective. They’re actively harmful when misused. And they’re misused almost everywhere.
Estimates become commitments. Velocity becomes a performance target. Teams that can’t hit their projected story points get labeled as underperforming. Retrospectives focus on “why didn’t we deliver what we committed to?” instead of “what did we learn and how do we improve?”
I’ve watched teams spend entire sprint planning sessions arguing whether something is a 5 or an 8, as if that precision matters when they’re building something they’ve never built before. I’ve seen organizations compare velocity across teams, turning an internal metric into a competitive performance indicator. I’ve seen perfectly capable teams lose confidence because their estimates were consistently wrong.
The real damage isn’t just the wasted time in estimation meetings. It’s the behavioral changes that destroy team effectiveness:
- Story inflation: Teams artificially increase story points to make velocity look better
- Risk aversion: Teams avoid complex, high-value work because it’s harder to estimate
- Quality degradation: Technical practices get sacrificed to hit artificial deadlines
- Innovation paralysis: Creative solutions get killed because they don’t fit the plan
When velocity becomes the goal, velocity becomes a terrible metric. This is Goodhart’s Law in action: when a measure becomes a target, it ceases to be a good measure.
Replace estimates with adaptive planning
Instead of fighting complexity with false precision, successful teams embrace approaches that work with uncertainty, not against it.
Use timeboxes for learning, not just decisions. Instead of “we’ll ship feature X by Friday,” try “we’ll spend two weeks validating our assumptions about user behavior, running experiments on the core workflow, and prototyping three potential solutions.” This creates urgency around learning while keeping implementation flexible. The key is being specific about what you’ll discover, not what you’ll deliver.
The objection here is predictable: “Without hard deadlines, teams will just take as long as they want.” This misses the point of timeboxing entirely. A well-designed timebox has clear learning objectives and forces decisions at the “last responsible moment,” the latest point you can make a decision without compromising the outcome.
Teams don’t need artificial pressure to work hard. They need clarity about what they’re trying to learn and why it matters. A two-week spike to “figure out the architecture” will expand to fill the time. A two-week spike to “validate whether our current database can handle 10x traffic and prototype two alternatives if not” has natural constraints that prevent endless exploration.
Shrink the work until size doesn’t matter. Use a simple scale: small, too big, or no clue. When everything is small and valuable, estimation becomes pointless. If a story is “too big,” slice it. If it’s “no clue,” do just enough investigation to remove the uncertainty. This eliminates most estimation theater while increasing flow.
Track throughput, not points. Count completed stories over time. This metric is as accurate as story point velocity for forecasting purposes but, without all the ceremony and estimation overhead. You eliminate planning poker sessions, story point inflation debates, and cross-team velocity comparisons while reducing pure waste. Historical throughput data becomes the foundation for probabilistic forecasting that’s based on what actually happened, not what teams hoped would happen. The key point is that it takes much less time, is easier to calculate, and results in the same amount of planning accuracy as story pointing.
Forecast with ranges, not dates. Monte Carlo simulations on real throughput data give you: “There’s a 70% chance we’ll complete this work between March 10-22, with a 90% confidence interval of March 5-30.” This is both more honest and more useful than “we’ll be done by April 8th,” which is what you tend to end up with after all the padding, sand-bagging, and buffers are added.
Reduce work in progress. Less parallel work means more flow and faster completion. Teams that start less and finish more consistently outperform teams that juggle multiple priorities. Resist the urge to start more work and keep your team at full utilization. Instead, do the difficult work of prioritizing and identifying the most valuable work for the team to focus on. And then do it again and again and again.
Optimize for learning, not execution. Software development is learning work. The practices that support learning - pairing, TDD, frequent feedback, collaborative requirements - don’t make individual stories more predictable. They make teams more adaptive, which is more valuable.
This shift requires different accountability measures. Instead of asking “did you deliver what you committed to?” start asking “how quickly are you learning?” and “how good are your decisions getting?” These metrics actually predict long-term success, unlike adherence to arbitrary schedules.
Of course, these approaches only work if your teams can actually ship frequently and maintain quality simultaneously. Many organizations struggle with basic engineering practices that would enable rapid, safe delivery. If your teams are drowning in technical debt and can’t ship with confidence, you might need to start by reducing cognitive load through better development practices before attempting organizational changes.
When you ship frequently, predictability becomes irrelevant
The best antidote to “when will it be done?” is “we shipped value yesterday and we’ll ship more tomorrow.”
If the train leaves every 5 minutes, no one asks for a schedule. When teams deliver working software frequently, stakeholders stop obsessing about distant deadlines. They can see progress, provide feedback, and make decisions based on actual results rather than projected plans.
This is where real predictability comes from, not accurate estimates, but consistent flow. Teams that focus on reducing cycle time and increasing deployment frequency naturally become more reliable because they’re working in smaller, more manageable increments.
The organizations still clinging to quarterly roadmaps and annual budgeting cycles are setting themselves up for failure. The world doesn’t move in neat cycles anymore. Competitive landscapes shift monthly. Customer needs change weekly. AI capabilities evolve daily.
Leaders who can’t adapt their organizational systems—HR, budgeting, performance management, resource allocation—aren’t just missing opportunities. They’re creating competitive disadvantages that compound over time. Yes, changing embedded systems is hard. Yes, there are political and structural barriers. But you’re the captain of this ship, and the buck stops with you.
The excuse of “our ship is hard to turn” rings hollow when competitors are sailing past you with more agile approaches. The organizations that figure out fluid team structures and adaptive leadership models aren’t just theoretically better. They’re measurably outperforming their traditional competitors.
Redefining predictability for the real world
Here’s the shift that needs to happen: stop asking “when will this be done?” and start asking “what’s the smallest valuable thing we can deliver?”
Real predictability in software isn’t about hitting arbitrary dates. It’s about:
- Consistent value delivery: Teams that ship working software regularly, regardless of story point velocity
- Responsive cycle times: Fast feedback loops that let you course-correct quickly
- Transparent progress: Visible outcomes that stakeholders can evaluate without consulting a burndown chart
- Adaptive capacity: The ability to respond to what you learn without throwing out the entire plan
When executives demand accountability, give them real accountability: “We committed to improving customer activation by 20%. Here’s what we’ve learned so far, here’s what we’ve shipped, and here’s what we’re trying next.”
Teams that master this approach develop what I call shared consciousness: distributed decision-making capability that eliminates traditional bottlenecks. When everyone understands both the why and the what, they can adapt quickly without constant approval cycles.
When they demand timelines, give them probabilities: “Based on our historical throughput, there’s a 70% chance we’ll complete this by the March board meeting, 85% by mid-March, and 95% by month-end. What confidence level do you need for your decision?”
When they demand estimates, give them ranges with context: “Similar work has taken us anywhere from 1-6 weeks, with most falling between 2-4 weeks. The wide range reflects the uncertainty we’re dealing with. We’ll give you an update every week with what we’ve learned and how that changes the forecast.”
The organizations that get this right
The companies that have figured this out share common characteristics:
They’ve stopped pretending software development is predictable in the traditional sense. Instead, they’ve built systems that thrive with uncertainty. They measure outcomes, not outputs. They fund teams, not projects. They optimize for learning speed, not execution speed.
They still do planning, but it’s adaptive planning based on real constraints and actual options. They still communicate with stakeholders, but the conversation is about value and trade-offs, not artificial precision.
Most importantly, they’ve accepted that in a complex domain, adaptability beats predictability every time.
Stop chasing the mirage
If you’re a CTO trying to shift organizational expectations, this isn’t easy. You’re fighting decades of embedded practices, stakeholder assumptions, and system designs built around false certainty. But the shift starts with naming the truth: predictability through estimation isn’t coming. It never was. Adaptiveness is the only real option.
The futile chase for predictability is killing software teams. It’s creating dysfunction, destroying trust, and preventing the very outcomes organizations actually want.
You can’t estimate the unestimatable. You can’t make complex work simple by demanding more detailed plans. You can’t improve unpredictable systems by measuring them more precisely.
But you can build teams that deliver consistent value through uncertainty. You can create systems that respond quickly to what you learn. You can optimize for the things that actually matter: customer outcomes, team satisfaction, and business results.
The choice is simple: keep chasing the mirage of predictability, or build the adaptive capacity to thrive without it.
Predictability isn’t the goal. Value delivery is. The sooner we accept this reality, the sooner we can get back to building software that actually matters.
If this resonates, share it with a fellow leader still chasing the mirage.
Essential reading
- Thinking, Fast and Slow by Daniel Kahneman: The foundational research on cognitive biases, including the planning fallacy that destroys estimation accuracy. Essential for understanding why humans are systematically bad at predicting future outcomes.
- NoEstimates: How to Measure Project Progress Without Estimating by Vasco Duarte: Practical guidance on moving beyond story points and velocity to outcome-focused delivery. Shows real teams successfully operating without traditional estimation practices.
- Lean Software Development: An Agile Toolkit by Mary and Tom Poppendieck: The definitive guide to applying lean manufacturing principles to software development, including eliminating waste and optimizing for learning cycles rather than predictable outputs.
Research evidence:
- Understanding sprint velocity fluctuations for improved project plans with Scrum: a case study: Case study proving velocity fluctuations stem from hidden complexity, not team performance. Teams met only 64% of commitments, with complex work achieving 20-100% predictability versus 81-100% for simple tasks.
- Managing complexity in projects: Extending the Cynefin framework: Extends Cynefin framework showing why estimation-based planning fails in complex domains. Demonstrates software projects require probe-sense-respond approaches, not plan-execute-control methods.
Resources:
- Cynefin Framework
- Focused Objective Tools: Collection of articles, tools, and spreadsheets on story counting throughput forecasting with monte carlo simulations