We do not lie to make work feel safer
False certainty is expensive. Honest constraints make better plans.
A common meeting moment:
Someone asks for a date.
Not because they’re irrational. Because they have to tell someone else something, and “I don’t know yet” is hard to move upward.
If you’re not careful, you answer the question they asked instead of the question they need answered.
The question they need answered is usually something like:
- What can we commit to without pretending unknowns aren’t real?
- What will we know next, and when?
- What are we choosing not to do?
Constraints
Estimation happens under pressure.
A budget exists. A stakeholder is anxious. A team wants to start building. The easiest path is to give a number and move on.
But software doesn’t cooperate.
Unknowns are real. Integrations hide complexity. Legacy systems behave in ways that don’t show up in a spreadsheet. Data is messier than the exported CSV. “Just one endpoint” turns into three internal systems and an auth handshake.
There’s also an incentive problem: teams are rewarded for confidence, not accuracy. When a plan breaks later, the narrative becomes personal (“why didn’t you think of that?”) instead of technical.
False certainty is expensive in three ways:
- It creates a schedule that can’t absorb reality.
- It pushes risk to the end (where it’s costliest).
- It makes re-scoping feel like failure instead of normal planning.
And there’s a quieter cost: people stop trusting updates. Once that happens, the only way to make work feel safe again is to lie louder. That’s how projects get ugly.
What we changed
We started treating constraints as first-class inputs.
Instead of producing a single confident date, we try to write down:
- what we know
- what we don’t know yet
- what would change the plan
- what we are choosing not to do
This sounds simple. It’s surprisingly hard.
It’s also the difference between comfort and plan. A date without discovery is usually comfort.
Layered scope (a practice, not a trick)
So we scope in layers.
A short discovery phase is not a sales trick. It’s an engineering practice. It’s where we find the failure modes, validate assumptions, and identify the few things that will dominate schedule and risk.
At the end of discovery, we try to be able to say one of these sentences honestly:
- “We can ship version A by X because we proved the integration and we know the data shape.”
- “We can’t defend a date yet; the next week is about collapsing the top risk.”
- “This isn’t feasible inside the constraint; here are the two options that are.”
That last sentence matters. A lot of timelines are really scope conversations that no one wants to have in public.
The format we use in meetings
When someone asks for a date, we answer with four parts:
- The commitment we can make today (often a small discovery milestone).
- The range we believe is plausible (not a point).
- The dominant unknown (the thing that will move the range).
- The next checkpoint (what will be different after it).
A template we use (copy/paste):
- What we know: …
- What we don’t know yet: …
- What we’re doing next: …
- Next update: … (date + what will be different)
An example answer to “when will it ship?” that doesn’t lie:
- We can commit to discovery by Friday.
- Today, the plausible shipping range is 4–8 weeks after discovery.
- The thing that moves the range is the data mapping (we don’t know if field X exists reliably yet).
- On Monday we’ll come back with a narrower range and a clear scope boundary.
It’s not poetry. It’s a way to keep the room aligned.
Keeping the plan live
After discovery, we make commitments we can defend, and we keep the plan live.
If reality changes, the plan changes.
We try to change it early, in small moves, while choices are still cheap.
That means saying uncomfortable things out loud:
- “This integration is harder than we thought; we can trade scope for time.”
- “This data is not in the shape we assumed; we can either clean it or change the feature.”
- “We can hit the date, but it will be a cutover with risk. Are we accepting that?”
We don’t treat those statements as failures. We treat them as the work.
Results / Measurements
The cleanest result is fewer mid-project resets.
When constraints are explicit, it’s easier to trade scope for time without drama. It’s also easier to re-plan without anyone feeling blindsided.
In practice, we look for:
- fewer “surprise” scope additions that should have been discussed up front
- fewer emergency cutovers caused by optimistic integration assumptions
- fewer late-stage rewrites driven by an early plan that hid complexity
- fewer status updates that change tone instead of changing information
A proxy we like is how often we have to answer: “Wait, I thought that was included.”
If that question shows up late, the scope boundary wasn’t real.
Sometimes the measurable outcome is that a project doesn’t start.
We’ve lost work by being honest. That’s cheaper than building the wrong thing under a false plan.
Takeaways
Honesty in scoping isn’t a personality trait. It’s cost control.
If a timeline can’t be defended yet, the correct move is not to invent one.
The correct move is to learn enough to defend one.
And if you can’t name the constraint you’re honoring, you’re not planning. You’re negotiating.