Why Engineering Timelines Collapse the Moment You Question Them
Five weeks became five days. Lessons from my first time managing engineers, on tradeoffs, politeness and understanding the work.
My first experience managing engineers taught me something I wish I’d understood earlier: timelines are often far more negotiable than people make them sound.
We were building a hardware prototype and needed to replace a camera module. The engineers estimated five weeks: three for sourcing and another two for mechanical work.
Five weeks sounded ridiculous to me, so I started digging.
I found the same component available locally within two days, although at a significantly higher price. A few hundred dollars to save three weeks and unblock testing? Seemed like an obvious tradeoff.
That brought the estimate down to about a week.
Then I looked into the mechanical work. Turns out, three of those days were allocated to sanding, polishing, and cosmetic finishing.
For a prototype we just needed to test, who the fuck cares?
We removed the unnecessary work, and what started as a five-week estimate became five days.
Same engineers. Same prototype. Nothing particularly clever happened.
We just questioned the assumptions behind the timeline.
What I got wrong
Looking back, my biggest mistake wasn’t trusting the engineers. It was assuming they’d naturally optimize for the same things I was optimizing for.
They were trying to deliver something properly finished, minimize risk, and avoid surprises. All perfectly reasonable.
I wanted to test the prototype as quickly as possible.
Neither side had explicitly agreed on what mattered most.
And that’s where I think a lot of engineering delays come from. Not necessarily incompetence or laziness, but people optimizing for different things without realizing it.
As a manager, it’s your responsibility to make those tradeoffs clear.
Is spending another week polishing this actually worth it? Can we pay more to get the component tomorrow? What happens if we ship without this?
If you don’t ask, people will make those decisions for you, often without even realizing they’re making them.
Politeness isn’t leadership
Another mistake I made was being too hesitant to challenge estimates.
I didn’t want to come across as someone who micromanages engineers or questions their competence.
But there’s a difference between questioning someone’s ability and questioning their assumptions.
Asking why something takes three weeks isn’t disrespectful. Neither is asking what we’d have to sacrifice to deliver it in three days.
In fact, I think it’s disrespectful to everyone involved to let weeks go by because nobody wanted to have an uncomfortable conversation.
You can be kind and respectful while still being demanding.
And you should be.
Understand the work you’re managing
I also learned that you can’t effectively challenge a process you don’t understand.
You don’t necessarily need to be the best engineer in the room, but you need to understand the work well enough to distinguish a real constraint from an assumption.
Otherwise, how would you know that three days of mechanical work were just cosmetic finishing? Or that a component supposedly taking three weeks to source was available locally?
I initially relied too heavily on estimates without understanding what went into them.
That was on me.
Now, when someone tells me something will take weeks, I’m much more interested in understanding why than negotiating the number itself.
What exactly needs to happen? What’s actually blocking us? What can we skip? What would it take to get something working tomorrow?
Sometimes the estimate turns out to be completely reasonable.
Other times, you discover that half the timeline was never necessary in the first place.
The actual lesson
I don’t think engineers should be expected to work longer hours or rush through important work just because someone wants things done faster.
And I certainly don’t think every estimate is padded.
But I do think teams waste an enormous amount of time on things nobody explicitly decided were worth doing.
Unnecessary polish. Conservative assumptions. Waiting on suppliers when alternatives exist. Work that makes the result nicer without making it more useful.
My biggest takeaway from managing engineers for the first time was that speed often comes from making better decisions, not working harder.
Five weeks became five days because we understood what actually mattered and stopped spending time on everything else.
I wish I’d learned that earlier.