How I Improved Our Project Estimates by 67% Without Changing the Team

We Stopped Guessing & Built Systems And It Changed Everything

I’ve been a CTO for over 20 years and I’ve seen every project estimation tool come and go without making any kind of difference at all.

Finally, I got sick of it and decided to attack the situation head-on and built internal systems that dramatically improved project estimates.

In fact, the confidence in Engineering from the rest of the company shot up massively after this and all it took was a few structural changes.

It’s not easy but it can be done with enough commitment.

This system is especially good for mid-market companies who struggle with predictability on Product & Engineering.

9 Pillars of the System

Pillar #1: Get the ELT Thinking in Points

One of the most impactful changes I made was getting the Executive Leadership Team (ELT) to think in agile points instead of hours or gut-feel guesses.

Why? Because I needed them to have a reference library of projects & points so stakeholders could wrap their head around my teams estimates more easily.

And because points abstract away the noise. They focus on relative complexity and effort and in doing so avoid stakeholders getting bogged down in “hours level” details.

Points are harder to argue with, easier to pattern-match, and naturally promote tradeoff thinking: “If this is a 30-pointer, what do we cut or delay to fit it in?”

To make this shift stick, I built a simple reference library: 10 real projects from the companies past, each with point values assigned.

• 3 projects were small, which for us meant < 100 points

• 3 projects were medium, so 100 to 400 points

• 3 projects were large, so 400 to 1000 points

• 1 project was an XL beast at 1000+ points

I did this to empower the ELT with a shared understanding and vocabulary. Soon, instead of asking, “How long will this take?” they were saying things like:

“That project feels like a 30-pointer — can we fit that in this quarter?”

It worked because it was concrete, reusable, and anchored in reality.

The business didn’t need to become agile experts — they just needed a common yardstick.

Pillar #2: Pattern Match Until Your Eyes Bleed

You know the least about a project when you first start it — and that’s exactly when most teams are forced to produce an estimate.

So we stopped trying to invent estimates from scratch and started pattern matching like our lives depended on it.

We’d organize the new project down into big chunks and then compare each piece to something we (or others) had done before.

It turns out, a shocking number of “new” projects aren’t new at all.

We got obsessive about it:

• Looked at internal builds, commercial third-party tools, and open source projects

• Talked to external CTOs, friends at other companies, and even open source maintainers

• But the most accurate data came from our own project history — because it matched our people and our context

Eventually, we compiled a reference set of 100+ past projects, covering every size, shape, and mess. We logged it in a spreadsheet, assigned point ranges, tagged key traits, and made the VPE the owner of that doc.

It became our estimation compass — a godsend.

We no longer guessed. We pattern-matched with confidence.

Pillar #3: Make an Agreement w/ the Business on Deadlines

One of the biggest shifts we made was getting on the same page with the business about what a project deadline actually means.

Most deadlines are treated like fixed dates but in reality, they’re often soft. They’re based on assumptions, guesses, or even vague hopes the business has.

The problem is, no one says that out loud. So engineering thinks, “we’ll refine this later,” while the business hears, “this is a promise.”

To close that gap, we introduced two key changes.

First, we stopped giving single-point estimates and started using ranges — like “mid-July to early August.” The bigger the project, the bigger the range.

That one shift alone reduced pressure and gave us space to learn and adapt.

Second, we started categorizing deadlines like this:

• Soft deadlines were rough targets — helpful but expected to shift.

• Hard deadlines were real and immovable — often tied to investor expectations, customer commitments, regulatory dates, or external launches.

Here’s the surprising part: once we created this shared language, it gave the business a new way to talk to engineering about their needs.

Instead of pushing for everything as urgent, they could say, “This is soft, not hard,” or, “This is soft, but let’s try.” It turned vague pressure into a more focused conversation.

We also realized our team had to get better at understanding what was driving the business urgency. Was it a board meeting? A new customer rollout? A big marketing event?

Once we started asking those questions, we gained clarity and so did the business.

No more guessing what people really meant by “deadline.”

Pillar #4: Lean into “Fake” Business Deadlines

Here’s the truth: what Engineering thinks is “fake” deadlines aren’t fake to the business.

They’re tied to board meetings, marketing campaigns, partnerships — real drivers, even if they’re disconnected from engineering reality.

So I stopped fighting them. Not by caving in but by reframing how I responded.

This required a mindset shift. I stopped seeing these deadlines as problems, and started seeing them as negotiation anchors.

When the business said “We need it by Q3,” I didn’t say “That’s impossible.” I said:

• “Yes — but here’s what that gets you.”

• “Yes — but we’ll need 2 extra teams.”

• “Yes — but we’ll need to cut scope or boost the budget.”

I leaned in, but with caveats.

Affirm first. Add constraints second. That was the playbook.

Over time, we built credibility. The business started expecting tradeoffs instead of miracles. And we chipped away at unrealistic asks, one conversation at a time.

You don’t fix deadline dysfunction with a fight. You fix it with strategy, nuance, and just enough pushback to build trust.

Pillar #5: Make a Tradeoff Framework

Tradeoffs are at the heart of project estimations because estimation is never just about effort alone — it’s about negotiating on timelines under a set of constraints.

Most leadership teams talk about tradeoffs all the time, but they rarely know what’s actually on the table.

They don’t know the full range of options, they can’t weigh scope versus timeline versus headcount, and they don’t have a framework to compare one tradeoff against another.

So the conversation stays vague nd estimates stay shaky.

Every project operates within limits: time, people, money, and pressure from the business to deliver quickly.

There’s rarely such a thing as a clean, theoretical estimate. You’re always estimating inside a pressure cooker.

So when someone asks, “How long will this take?”, they’re not really asking for a number. They’re asking, “Can I get everything I want, exactly when I want it, without changing anything else?”

That’s not just an engineering question, it’s a tradeoff question.

To fix this, I built a tradeoff framework in Excel.

I listed out both primary and secondary tradeoffs: things like speed vs. scope, team size vs. timeline, risk vs. confidence, and structured them in a simple “give this / get this” format.

We brought the spreadsheet into every estimation conversation.

Product, engineering, and the ELT could all see the same set of levers and tradeoffs, laid out clearly.

It turned hand-wavy conversations into real, concrete decisions that helped us make the right kind of estimates.

Pillar #6: Realize Requirements Will Never be What You Want

At some point, I had to come to terms with a hard truth: product requirements are never going to show up in perfect condition.

They won’t be as clear, complete, or thought-through as I want them to be — and waiting for that to magically change was wasting time.

Most product teams are stretched thin. They’re juggling strategy, customer feedback, internal stakeholders, and usually doing it all without enough headcount.

So instead of getting frustrated, I started empathizing. I stopped blaming the input and started thinking about how Engineering could bridge things (of course I adjusted our capacity accordingly!)

That meant stepping in to help fill the gaps.

I didn’t write every requirement, but I did shift the mindset — from “we’re blocked” to “let’s help shape this.”

I pulled in engineers who were naturally strong collaborators, the ones who liked working with product.

Together, we started participating earlier, asking better questions, and shaping the work with product instead of waiting for handoffs.

Eventually, requirements became a shared responsibility. Product felt supported. We felt informed. And the quality of both the specs and the estimates improved across the board.

Pillar #7: Send Your Engineering Team to Estimation School

Early in my career, I made this mistake: I assumed good engineers were naturally good estimators. They’re not. Estimation is its own skill and a rare one at that.

In fact, some of the best estimators I’ve worked with didn’t come from engineering at all. They came from product, QA, even project management.

What they had in common wasn’t a background, it was a mindset. They understood scope, risk, and how to break down ambiguity into something measurable.

So I started assessing. I looked closely at my team and figured out who had the instincts, the track record, and the curiosity to get better at estimating.

I found a few solid estimators and had them teach others. I even brought in outside experts to run workshops.

We treated estimation like any other skill — something you invest in, not something you hope for.

Not everyone’s going to be great at it, and that’s fine. Focus on the leads or a few trusted voices per team.

Give them the tools, the patterns, and the responsibility. A few well-trained estimators can lift the quality of planning across the entire org.

But you have to be proactive. If you’re not actively teaching your team how to estimate, don’t be surprised when they keep getting it wrong.

Pillar #8: Create a Product Steering Committee Feedback Loop

I know it sounds bureaucratic — but it’s not if you run a steer co well.

One of the biggest problems with estimates is that they go stale the minute something changes… and something always changes.

To fix that, I set up a monthly Product Steering Committee.

Nothing fancy. Just a recurring forum where product, engineering, and leadership could review ongoing initiatives and adjust timelines based on new information.

The goal wasn’t to micromanage. It was to keep our estimates “alive.” If scope shifted, if resources changed, if priorities moved we talked about it.

And we always made sure that any change in estimate was tied to a clear driver: new scope, lost velocity, shifting dependencies, etc.

This created a simple but powerful loop: estimate → reality → feedback → update.

It kept everyone aligned, and it made sure no one was surprised when timelines moved because we moved them together.

Pillar #9: Build a Capacity Model to Capture Admin Overhead

One of the most common estimation mistakes is forgetting how much time your team doesn’t have.

Most teams throw around ideal estimates — as if everyone is coding 40 hours a week, fully focused. But that’s not real life.

Meetings, PTO, context switching, onboarding, internal reviews — it all adds up. And if you don’t account for it, your estimates will always feel optimistic, no matter how carefully you plan.

To fix this, I built a simple capacity model in Excel.

We tracked each team member’s real availability — subtracting for recurring meetings, company holidays, vacation time, and known non-dev obligations.

We also included administrative overhead like:

• Weekly stand-ups and planning

• Sprint ceremonies

• One-on-ones and performance reviews

• Incident response rotations

• Internal demos or exec briefings

Once we added all that up, we could see our real capacity — not theoretical headcount, but actual usable hours or points per sprint.

This gave us a more honest foundation to build from.

—

OK, I hope this helped.

With persistence you can implement all of these in a few months depending on the size and complexity of your organization.

If you need any help on this go ahead and email me at bobby@technocratic.io

And in the meantime, keep the shark swimming. 🦈