Yaniv Preiss

In many conversations I held with senior engineering leaders from multiple company sizes and locations, a dangerous obsession has taken over. Unfortunately, it’s not an obsession with customer delight or market disruption, but with something far more mundane: predictability.

Here are some requirements I’ve seen in job ads:

• “improve delivery predictability“ (Engineering Manager)
• “This role owns execution, predictability, quality” (VP Engineering)
• “Create business value by increasing delivery throughput and predictability… Establish a predictable execution rhythm“ (Director of Engineering)

When leadership teams set predictability as the ultimate goal and demand to know exactly what will be delivered and when, they aren’t just asking for a schedule – they are making a profound trade-off: they are sacrificing impact for certainty. I’ve challenged leaders on the value of a linear roadmap (aka “features and dates”) versus non-linear, high-impact growth, and been met with a blank stare followed by ample excuses. That’s exactly the predictability trap.

1. Control vs. Value: The Stakeholder Ego

The fundamental issue is that predictability is optimized for the internal sense of control rather than results, which are always external to the organization. Leaders often use delivery metrics as their “safe place”.

Reality check: your customers do not care about how many “story points” you burned down in Sprint 4. They don’t care if your velocity chart is a perfectly flat line.

The sacrifice: when we prioritize predictability, we stop asking “What is the most valuable thing we can do today?” and start asking “What can we guarantee by Friday?” This shifts the focus from solving customer problems to fulfilling internal promises.

The excuse that stakeholders “need to know when something is ready” is often a polite mask for a refusal to manage uncertainty, operating on the flawed premise that a date on a calendar creates reality. In a complex software environment, providing a fixed date for a distant milestone isn’t “planning” but an implicit trade-off. True professional transparency isn’t found in a Gantt chart that everyone knows is a comfortable lie, but in demonstrating continuous, incremental progress.

If the CTO needs predictability to sleep at night, they are choosing the comfort of a deadline and “holding accountable” over the potential impact and profitability that also require hard work of trust building, goal setting and a culture of continuous discovery. As a CTO, I’d sleep better knowing the team has validated three hypotheses this week, rather than knowing they checked off ten Jira tickets.

Yes, there are exceptions like building a spaceship. And still, recall that Boeing 777 was built agilely. Chances are, with your B2B SaaS, you’re also not the exception. If there are seasonal deadlines, like in agriculture context, how about making sure the teams have this knowledge and prepare accordingly?

Predictability-led leaders treat software like building a bridge, which is a category error. Building a bridge is complicated – predictable with expertise, while building software for humans is complex – unpredictable and emergent.

2. From “Agile Theater” to Agile

Many organizations are stuck in what can only be described as Agile Theater. This is a performance where the script (scope) is pre-defined by Product, leadership and stakeholders, and the “agile” part is simply breaking that rigid scope into two-week chunks, and the engineers’ only mandate is deciding on how to implement.

Let’s have a look at the agile manifesto again:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

To escape this theater, and become Agile:

• Rapid feedback loops: instead of following a plan, follow the customer. If needed to change course, it can be done within days, while predictability might cover and drag it for months.
• Customer integration: especially with the rise of AI, the barrier to creating prototypes is lower than ever. There is no excuse for not speaking to customers every week to validate assumptions.
• The shift: real agility accepts that the path to value is messy and unpredictable. It trades the comfort of a fixed roadmap for the competitive advantage of being right.
• Impact roadmap: instead of pre-defined features and dates, use “now/next/later” roadmap that consists of the customer problems that will be worked on per quarter, without specific solutions.

And here is another suggestion that may seem inconceivable: switch from Scrum to Kanban. It’s not just for service teams that receive unpredictable requests from internal users. It’s for product engineering teams that want to prioritize the most impactful work items for the customer.

3. The OKR Misunderstanding: Initiatives vs. Impact

Predictability-obsessed cultures often misuse OKRs (Objectives and Key Results). They treat them as a “to-do list” of initiatives rather than a measurement of external change, that is, customer behavior.

True OKRs (Impact-Oriented)	Predictability “OKRs” (Activity-Oriented)
Goal: change a specific customer behavior by date Z	Goal: ship features X and Yby date Z
Metric example: 5000 sign-ups	Metric example: 2 features delivered on time
Nature: outcome-based and risky	Nature: output-based and “safe”

When an OKR is just a list of bets the company has already decided to make, it isn’t a goal but rather a project plan with a fancy name.

4. The High Cost of “Accurate” Estimations

Many leaders set goals for their directs to provide “more accurate estimations,” often weaponizing these numbers into hard deadlines, or requesting a lower estimate. This creates a culture of institutionalized lying, as I have written in #NoEstimations.

Estimates are not mentioned in the Scrum Guide – it’s a myth. Byproducts that often show up:

• Sandbagging: teams quickly learn to “pad” estimates to ensure they never miss a deadline, or artificially slowing down work to meet the estimate.
• Gamification: focusing on increasing story point counts or delaying bad news to the next sprint rather than solving complex, unpredictable problems.
• Punishment: when teams are punished for “missing” an estimate, they stop taking risks. Innovation dies because innovation is, by definition, unpredictable. Predictability cultures run on fear, while impact cultures run on truth.
• Peer pressure: adjust estimations to meet a norm, even when knowingly wrong, or satisfy a powerful persona.
• Rigidity: a predictable team is a team that has decided to stay blind to new information for the sake of the plan.

5. The False Dichotomy of “Tech Work” vs. “Product Work”

In a predictability-first environment, technical debt and refactoring are the first victims. Because these tasks don’t have an immediate feature attached to them, they are hard to justify in a rigid sprint.

However, this is a failure of framing. All work is product work. Refactoring that improves latency is a product improvement for the user. Repaying technical debt that allows for faster future iterations is a business value. When prioritizing work items, compare their value.

When leaders demand predictability, they place a barrier between “building the thing” and “building the thing right.” Eventually, the system becomes so brittle that predictability becomes impossible anyway, regardless of how many charts you draw.

Here lies the paradox – chasing predictability reduces predictability. As technical debt grows to satisfy a deadline, the system becomes a “Black Box” where even simple changes take an unpredictable amount of time.

Green Flag Job Ads

Here are some examples from leadership job ads that value impact:

• “Experience leading teams through rapid experimentation and pivoting based on customer feedback”
• “Measured by business outcomes (e.g., conversion, churn reduction) rather than output (story points)”
• “Ability to manage technical debt as a strategic investment in future velocity”

The Bottom Line

Predictability is a lagging indicator of a stagnant product. If you know exactly what you’re doing six months from now, it means you aren’t learning anything new from your users, and not agile by definition.

Real leadership requires the courage to embrace uncertainty. It means trading the green checkmark of a completed task for the potential hockey stick of actual customer impact, or at least a great smile on their face. In the age of AI, where execution speed is becoming a commodity, don’t measure how quickly AI can burn down story points – the only thing that matters is how fast you can learn and adapt.

Stop optimizing for predictable output and start measuring how much the work actually matters.

Tomorrow, ask your team what they learned instead of what they finished.