My first real experience managing engineers taught me this:
Timelines collapse the moment you interrogate them.
Politeness is not leadership.
Here’s a mistake I made early on.
Not because I didn’t know better.
Because I didn’t enforce what I already knew.
We needed to swap a camera module component in a hardware prototype.
I was given a timeline of roughly five weeks.
Three weeks to source the component.
Another one to two weeks for mechanical iterations.
On paper, it sounded reasonable.
Instead of accepting it, I checked sourcing options myself.
The same module was available in one to two days from a different supplier.
They had local stock.
They also demanded an unreasonably high price for expedited access and shipping.
Several hundred dollars for a part that normally costs a fraction of that.
I made the tradeoff explicit:
"A five-week delay blocks v0 testing and model iteration.
Paying a premium to unlock that time is much cheaper."
Once that constraint was stated clearly, the timeline changed immediately.
Sourcing dropped to two days.
Mechanical work was quoted at five.
Then I pushed again.
When I broke down the mechanical work, three of those five days were allocated to sanding, polishing, and cosmetic finishing.
For a v0 prototype, none of that mattered.
Once scope was stripped to what was actually required to test functionality, the timeline collapsed again.
What was framed as five weeks became five days of real work.
Nothing magical happened.
No new capabilities appeared.
No constraints were lifted.
The only thing that changed was that vague timelines were no longer allowed to stand.
This wasn’t an engineering failure.
It wasn’t a skill issue.
It wasn’t incompetence.
It was a leadership failure.
In the absence of clear constraints, teams naturally optimize for safety and risk reduction.
That’s rational. It just isn’t optimized for speed.
Deciding when to trade money for speed, when to accept risk, and when polish is waste is not an engineering responsibility.
It’s a leadership one.
When leadership doesn’t intervene, timelines quietly stretch.
Momentum bleeds.
And teams ship weeks later what could have shipped in days.
Unchallenged timelines aren’t neutral.
They’re expensive.
When someone gives you a timeline, it often sounds confident:
- “We’ll need a few weeks to get this right”
- “Let’s plan a month so we don’t rush”
- “We should do this properly, not hack it”
- “We’ll ship after one more pass”
These are rarely estimates.
They are risk-adjusted positions.
They bake in safety, uncertainty, rework, and personal comfort.
They are designed to survive scrutiny, not to optimize speed.
When I stopped treating timelines as facts and started treating them as starting points for interrogation, something consistent happened.
Work framed as weeks consistently dropped to days.
Same people.
Same constraints.
Same problem.
The difference wasn’t effort or capability.
It was removing hidden padding and unexamined assumptions.
I used to think I was being respectful by not pushing.
What I was actually doing was outsourcing responsibility.
Questions like:
- “When do you think this will be done?”
- “Does this feel reasonable?”
- “Are we on track?”
Sound collaborative.
Operationally, they are useless.
They invite vague answers, defer decisions, and let timelines drift without friction.
Leadership is not about being agreeable.
It’s about forcing clarity early, when change is cheap.
Asking uncomfortable questions up front is not micromanagement.
It’s timeline enforcement.
If you don’t challenge ambiguity, it doesn’t disappear.
It quietly turns into delay.
This was one of the biggest shifts for me.
High-level milestones feel productive.
They are where timelines go to die.
When you ask:
- “When will this ship?”
- “What’s the delivery date?”
You’re not asking about work.
You’re asking for a placeholder.
That gives people room to drift, polish, and disappear into “quality”.
If you want real timelines, you have to pull the work into the open and force specificity.
Bad framing:
“The feature will take about three weeks”
That statement hides everything that matters.
Better framing:
- Which exact user flow blocks launch?
- What is the one thing users must be able to do?
- What breaks if we skip everything else?
- What can ship in X days that unlocks real feedback?
Once you decompose it, a pattern shows up quickly:
Most value arrives early.
The remaining work is refinement, edge cases, and comfort.
People don’t delay maliciously.
They delay because no one draws a hard line.
Bad framing:
“Sourcing and assembly will take five weeks”
That bundles fundamentally different delays into one safe answer.
Better framing:
- What is the slowest component?
- Is it slow because of physics, or because we chose the safest supplier?
- What changes if we pay more?
- What steps take hours, and which ones are actually days?
Once decomposed, “five weeks” usually turns into:
- a few days of real work
- weeks of waiting
- days of indecision
Those are different problems.
They require different interventions.
Milestones collapse once the work is visible.
One mistake I made early was treating every delay as the same problem.
They aren’t.
In status updates, everything sounds reasonable.
In practice, delays fall into two very different categories.
People delays sound like:
- “We’re still thinking”
- “We want to clean this up first”
- “It’s almost ready”
- “We don’t want to ship something half-baked”
These are not execution problems.
They are decision problems.
Fixing them requires:
- narrowing scope
- defining MVP brutally
- killing polish
- forcing tradeoffs
External delays look like:
- vendors
- dependencies
- reviews
- approvals
- shipping
- waiting on someone else
These are not decision problems.
They are logistics problems.
Fixing them requires:
- parallel paths
- money
- alternatives
- ordering earlier than feels comfortable
Teams often hide people delays behind external ones.
If you don’t separate them, everything looks justified and nothing moves.
Velocity doesn’t die loudly.
It dies when leadership fails to classify delays correctly.
This was the most painful realization.
Most delays aren’t caused by lack of ability.
They’re caused by lack of constraints.
When I clearly said:
- “This is MVP, not v1”
- “This improvement is not worth a week”
- “We’re optimizing for validation, not elegance”
Suddenly:
- decisions got faster
- scope shrank
- execution improved
Speed didn’t come from working harder.
It came from stopping unnecessary work.
Pace does not emerge naturally.
In the absence of constraints, teams move at their comfort level.
If you don’t set the pace, the slowest reasonable pace wins by default.
This one was on me.
I started managing before I truly understood how the system worked.
I trusted people to self-manage timelines correctly.
That was naive.
Leadership doesn’t require doing the work.
But it does require understanding it well enough to challenge it.
That means:
- knowing how work actually flows
- knowing where time is lost
- knowing what can be skipped
- knowing which “rules” are real and which are cultural habits
Not to micromanage.
To recognize bullshit when it appears.
If you don’t understand the process, you can’t tell the difference between:
- a real blocker
- and a comfortable delay
And if you can’t tell the difference,
you can’t protect momentum.
I don’t ask:
“When will this be done?”
I ask:
- “What would we ship if we had to launch in 72 hours?”
- “What breaks if we remove this?”
- “Which part is actually hard?”
- “What are we polishing that users will never notice?”
- “What decision are we avoiding?”
If someone can’t answer clearly,
the work isn’t blocked.
The decision is.
Momentum is fragile.
Protecting it is not an engineering responsibility.
It’s a leadership one.
Leadership isn’t about being nice or aggressive.
It’s about being clear, demanding, and fair.
Timelines don’t become real on their own.
They become real when someone is willing to interrogate them.