As an engineering manager, I’m constantly trying to wrap my head around how hard it is to estimate software timelines. No matter how we try, things end up taking longer than expected. There are a few things teams usually get bogged down with:
- Endless debugging cycles where they go down rabbit holes for days
- Code reviews that drag on forever because of bikeshedding or the same problems repeated again and again
- Debates keep happening because key architecture decisions are not documented
- Critical bugs are being found at the last minute for various reasons like lack of testing
When building software, some flexibility around planning is expected. But missing deadlines left and right is not okay. Regardless of how uncertain the work is, consistently letting down stakeholders erodes their trust.
Engineering leaders must look closely at where our process breaks down. We give our teams a lot of autonomy, but we owe it to them to constructively improve the work. Even though increased oversight goes against the agile principles, sometimes things reach a point where you need to take action to get your lead times back in check.
Improve Visibility Into the Process
First, get more visibility into what was happening during the development cycles. Instead of making assumptions, gather data to pinpoint where the team is struggling.
Start tracking stuff like:
- How long do code reviews take — From opening the PR to final approval, how much time is spent reviewing? Long turnarounds show where things get stuck.
- Number of back-and-forths — Are you cycling through review after review? High numbers reveal inefficient reviews or developers repeating their mistakes.
- Bug types — Were they from missing specs, wrong implementations, or lack of testing? This will show you where breakdowns happen so that you can figure out why.
- Initial estimate vs. actual — How far off are the estimates? Big discrepancies highlight areas where engineers are getting sidetracked.
Armed with data, you can see correlations, like how reducing the number of review rounds directly increases our lead times. This information is the foundation for constructive changes grounded in evidence, not assumptions.
Invest More in Early Analysis
Often, engineers need to slow down a bit at the start to clarify requirements and think through technical stuff before jumping into coding. Rushing causes headaches down the line.
Require API contracts and data schemas designed upfront. Start doing short design reviews to talk through potential architectures first. Engineers could write a doc laying out options and trade-offs for discussion instead of silently making decisions independently and then struggling to follow through. This collaborative process helps avoid rabbit holes down the line.
Of course, over-architecting can get pretty far. To balance the depth of analysis with speed, set some limits:
- Cap design reviews at an hour, so they don’t drag on forever.
- Limit tech specs to a few pages — don’t get overly detailed because people get lost in extensive documentation.
- Build lightweight prototypes to test complex concepts.
- Adopt a “good enough for now” mindset over endless optimization.
With the right checks in place, the engineering team won’t go overboard with implementation. It takes some restraint, but the investment pays off.
Increase Communication of Blockers
Developers often hit roadblocks but don’t tell about them, spending days grinding through problems in technical areas that are not so critical for end users.
To get issues out in the open, you can try a few things:
- Conduct daily standups. I have yet to try them out, but many engineering managers use them to get everyone to call out blockers.
- Host office hours a few times a week. Focused on addressing roadblocks one-on-one to give private space to people uncomfortable sharing problems in a group meeting.
- Ask for regular status updates and require calling out anything blocking.
- Use retros to uncover recurring issues people are facing quietly. Bringing them into the open and addressing them together.
By drawing out blockers instead of hiding them, you can swarm problems as a team much quicker. This makes every individual feel more relaxed about sharing the difficulties they face. Removing the stigma around asking for help accelerates the delivery time.
Enhance Planning
Even when requirements are crystal clear, engineers struggle to estimate, which is perfectly normal. But it doesn’t mean that we should stop trying. Imperfect planning is better than no planning at all. Otherwise, the work drags on forever, and there is no accountability. Here are a few things to try:
- Require breaking features into tasks. This provides way more clarity about how the work will be approached and progressing.
- Ask for estimates for each task. Developers hate estimates because it’s hard, but there’s no accountability without them. Highlight that updating estimates is okay, but there should be a valid reason, which must be communicated upfront.
- Track estimate accuracy over time — compare actuals vs estimates to reveal padding or sandbagging tendencies.
- Apply buffers to overall timelines based on past variability — account for unknowns without padding every task.
Getting better at estimation is key to improving predictability. It’s a challenge, though, because there’s a lot of resistance from engineers who hate to work against the clock. Account for uncertainty to set realistic schedules.
Consistently Missing Deadlines Erodes Trust
As engineers, we know estimates are tricky — they’re guesses, not commitments. However, consistently missing deadlines and inflating lead times slowly erode stakeholder trust.
As leaders, we must balance empathy for uncertainty with accountability on delivery timelines. Careful oversight and analysis of what happens during development is the way to maintain that balance.
By building processes to surface data, we can spot optimization opportunities — from requirements to testing to reviews. More visibility enables realistic commitments.
Of course, increased visibility shouldn’t come at the cost of autonomy or trust. The goal is transparency, not top-down micromanagement. Engineers want to do great work — we just need to ensure our processes are not slowing them down.
Shortening lead times takes dedication to incremental, data-driven enhancements across how we develop, design, test, and deliver. It’s a long game but well worth the effort.
Originally published on Medium.com
