The CTO's Timeline Tightrope

The Hidden Cost of Forcing Software into Quarterly Boxes or EOS Rocks

I'm sitting in our quarterly leadership meeting, watching our CEO draw boxes on the whiteboard. Each box represents a "rock" in our EOS system—those critical priorities we've committed to completing this quarter. The product team has already filled most of them with ambitious feature requests, each with a neat deadline that perfectly aligns with our quarterly boundaries.

My stomach tightens. I know what's coming next.

"So, Etienne," my CEO turns to me with that familiar expectant look, "can your team deliver all of these by the end of Q3?"

The room falls silent. Every executive stares at me, waiting for the answer they want to hear. I've been here hundreds of times before, trapped in this perpetual estimation dance. I want to be a team player, to confidently say "absolutely!" But the engineering reality I live in doesn't fit neatly into these quarterly boxes.

"Well," I begin cautiously, "some of these features haven't been fully specced yet, and there are technical dependencies we haven't explored. I can't give you a definite timeline right now."

I see the disappointment ripple across the table. The COO sighs. The VP of Sales slumps slightly. And my CEO's expression hardens just enough to make it clear: this answer isn't acceptable.

"We need commitments, not maybes," he responds. "The board expects these features. Our customers are waiting. What's so difficult about giving us dates?"

And there it is. The CTO's estimation trap. How do you explain the inherent uncertainty of software development to business stakeholders who crave certainty? How do you bridge this fundamental gap in understanding without coming across as difficult or obstructionist?

I realize in this moment that my technical correctness isn't helping anyone. The company needs direction, not disclaimers. But rushing into artificial deadlines will only lead to burnout, technical debt, and inevitable disappointment when we miss them.

Something has to change, and it has to start with me.

The Rock and the Hard Place

The Entrepreneurial Operating System (EOS) has transformed how thousands of companies organize their priorities with its straightforward approach to quarterly "rocks." For many organizations, this system creates clarity and focus. Yet for technology leaders, these rigid timeboxes often create a unique tension.

Unlike other business functions where effort often correlates directly with outcomes, software development follows different laws. The most famous attempt to capture this reality comes from Fred Brooks in his essay "No Silver Bullet,"¹ where he distinguishes between essential complexity (the inherent difficulty of the problem) and accidental complexity (the difficulties that arise from our tools and approaches).

The uncomfortable truth is that software estimation remains notoriously difficult despite decades of advancement in development methodologies. A McKinsey study found that large IT projects run an average of 45% over budget and 7% over time while delivering 56% less value than predicted.² Even at smaller scales, the Standish Group's CHAOS Report consistently shows that less than 35% of software projects are completed on time and on budget.³

The question isn't whether estimation is difficult. It's why we continue pretending it isn't.

Different Worlds, Different Languages

The fundamental challenge lies in the different mental models that executives and engineers use when thinking about work:

Business leaders operate in a world where:

• Commitments are expected to be kept

• Predictability enables planning

• Time is the fixed constraint

• Scope can be clearly defined upfront

• Projects have clear start and end points

Technology teams operate in a world where:

• Discovery happens throughout development

• Unknowns reveal themselves progressively

• Quality trade-offs have long-term consequences

• Dependencies create cascading impacts

• Work is never truly "done"

This mismatch creates what I call the "Certainty Theater"—where CTOs feel pressured to provide precise estimates they don't believe in, and companies make business commitments based on these artificial certainties.

The cost? According to a 2021 study by Haystack Analytics, 83% of developers report experiencing burnout, with "unrealistic deadlines and expectations" cited as the leading cause.⁴

Finding Solid Ground

After years of struggling with this disconnect, I've discovered that the solution isn't about becoming better at estimation but changing the conversation entirely.

In that leadership meeting, I took a deep breath and tried something different.

"Instead of promising all these features by quarter's end," I said, "let me show you what we know we can deliver, what we're confident about, and what remains uncertain. Then let's talk about the business priorities so we can focus our certainty where it matters most."

I pulled up a simple chart with three columns:

1. High Certainty (90%+ confidence) — Features with clear requirements, known technologies, and minimal dependencies

2. Medium Certainty (60-90% confidence) — Features with some unknowns or dependencies but familiar patterns

3. Low Certainty (<60% confidence) — Features with significant unknowns, new technologies, or complex integrations

For each item, rather than a single date, I showed confidence intervals: earliest realistic delivery, most likely timeframe, and latest probable completion.

"The question isn't whether we can fit everything into Q3," I explained. "It's which of these matters most to our business goals, and how we can maximize value delivery while maintaining technical quality."

The energy in the room shifted. Instead of a yes/no standoff, we began having a nuanced conversation about trade-offs and priorities. The CEO still wanted certainty, but now we discussed business impact rather than arbitrary deadlines.

This small shift in approach—from binary promises to confidence-based prioritization—changed everything.

Making Uncertainty Visible

Through this journey, I've learned that effective estimation isn't about becoming more precise—it's about becoming more transparent about uncertainty itself.

Software development will always contain unknowns. Rather than hiding this reality, successful CTOs make uncertainty visible and manageable. Here's the framework I've developed:

1. Establish Confidence Levels

For each significant initiative:

• What do we know for certain? (requirements, technologies, team capabilities)

• What are the known unknowns? (potential challenges we can anticipate)

• Where might unknown unknowns hide? (areas of highest risk)

Create visual representations of certainty levels for each component of your roadmap. This makes the abstract concept of uncertainty tangible for non-technical stakeholders.

2. Build in Stages, Not Leaps

Rather than attempting to estimate entire projects upfront:

• Break work into discovery and delivery phases

• Estimate only what's visible from your current vantage point

• Re-estimate regularly as new information emerges

Basecamp's Ryan Singer describes this as "shaping work"—defining the boundaries and appetite for a project before committing to specific timelines.⁵

3. Define Value Milestones

Instead of promising everything by a fixed date:

• Define the minimum viable increments of value

• Commit to delivering value progressively

• Establish check-in points for reassessment

This approach, similar to the Scaled Agile Framework's concept of Minimum Viable Solutions, focuses stakeholder attention on value delivery rather than arbitrary deadlines.⁶

4. Shift the Probability Conversation

Help your organization move from:

• "When will it be done?" to "What's our confidence level?"

• "Can you commit to this date?" to "What would increase our certainty?"

• "Why is it taking so long?" to "How can we reduce scope to increase certainty?"

Companies like Automattic and Stripe have embraced probabilistic roadmapping, where timelines are expressed as ranges with confidence intervals rather than fixed dates.

Leadership Beyond Estimation

Implementing this approach requires more than techniques, it demands a different kind of leadership from CTOs. You must:

1. Teach Persistently — Help your organization understand the fundamental nature of software development complexity

2. Show, Don't Tell — Use data from your own delivery history to demonstrate patterns of uncertainty

3. Focus on Outcomes — Shift conversations from feature completeness to business impact

4. Build Trust Through Transparency — Be honest about what you know, what you don't know, and how you're managing risk

The most effective CTOs I've met aren't necessarily the best estimators—they're the best translators between technical reality and business needs.

The New Normal

Over time, my leadership team adapted to this new approach. Our quarterly planning sessions transformed from contentious deadline negotiations to collaborative value-mapping exercises. We still use rocks in our EOS implementation, but now they represent value increments rather than feature completion dates.

The CEO still wants certainty, that's inherent to the role, but now understands how to get the kind of certainty that actually matters: confidence that we're delivering the highest-value capabilities as efficiently as possible.

Our development team's morale improved dramatically once they stopped working against impossible deadlines. Burnout decreased. Code quality improved. And counterintuitively, our actual delivery speed increased because we were spending less time managing expectations and more time creating value.

Taking the First Step

If you're a CTO caught in the estimation trap, I encourage you to:

1. Examine Your Process — How much time do you spend generating estimates versus delivering value? What's the accuracy of your past estimates?

2. Change the Visualization — Create and share certainty-based roadmaps that make uncertainty visible rather than hiding it

3. Start Small — Choose one significant initiative to apply confidence-based estimation approaches

4. Gather Data — Track the accuracy of different confidence levels to improve your calibration over time

5. Build Allies — Find business stakeholders who understand the value of this approach and can help champion it

The challenge of software estimation has existed since the field began. What's changed is our understanding of how to manage this complexity rather than pretend it doesn't exist.

By embracing uncertainty rather than fighting it, you can transform the estimation conversation from a source of friction to a strategic advantage. You'll build greater trust with stakeholders, deliver more reliable outcomes, and create a healthier environment for your engineering team.

The tightrope remains—software will always resist precise estimation—but by changing how we frame and manage that reality, we can create a better way forward for everyone involved.

Remember: your job isn't to predict the future with perfect accuracy. It's to help your organization navigate uncertainty while delivering maximum value. And that begins with having the courage to talk honestly about the nature of software development itself.

1. https://en.wikipedia.org/wiki/No_Silver_Bullet#:~:text=%22No%20Silver%20Bullet%E2%80%94Essence%20and,hardware%20development%20(Moore's%20law).

2. https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/delivering-large-scale-it-projects-on-time-on-budget-and-on-value

3. https://www.csus.edu/indiv/v/velianitis/161/ChaosReport.pdf

4. https://www.usehaystack.io/blog/83-of-developers-suffer-from-burnout-haystack-analytics-study-finds

5. https://brianrhea.com/podcast/shape-up-with-ryan-singer-of-basecamp/

6. https://framework.scaledagile.com/epic/#:~:text=Analyzing%20an%20epic%20includes%20defining,requires%20creating%20a%20new%20epic.