Plato Elevate Winter Summit has been announced (Dec 7th-8th)

🔥

Back to resources

Don’t Let Yourself Be Held Hostage by Estimates

Deadlines
Prioritization

14 September, 2020

Marian Kamenistak
Marian Kamenistak

VP of Engineering at Mews

Marian Kamenistak, VP of Engineering at Mews, discusses how constant delays are usually caused by things other than inaccurate estimates.

Problem

Oftentimes I would hear stakeholders or PMs complaining that the engineering team repeatedly fails to complete their work on time. They would push even harder on deadlines assuming that that would help. In reality, it only creates additional tension that helps no one. They would also try to add artificial buffers which further complicates the problem.

However, estimates themselves are rarely a problem and constant delays are usually caused by things other than inaccurate estimates. Therefore, don’t let yourself be held hostage by estimates!

Actions taken

I tried to underline that estimates shouldn’t be understood as commitments, but should be interpreted more broadly to include the value of the development process and shouldn’t be exposed and discussed outside of software development.

If a team repeatedly fails to deliver on time, it is believed that their estimates are imprecise or inaccurate. Only using the right insights could help us establish what the problem is really about. I would typically find out that the delivery system is not functioning properly. Namely, during a sprint planning, a team would commit to a number of issues to be implemented, but a great number of unplanned things -- from bugs to different types of blockers -- would emerge that couldn’t be anticipated. The solution would be to identify possible unplanned or ad hoc issues and clearly define under which circumstances they could interrupt the implementation of the planned activities. That would include defining all of those unplanned issues; for example, what would constitute a blocker, etc. If a team has to deal with a few ad hoc issues monthly, things would likely go according to a plan. But, if the unplanned issues constitute up to 20-30 percent of the output that would cause serious problems and consequently delays.

Also, PMs and tech leads should have a clear insight into the type of work a team is completing; for example, how many features or bugs they were working on, how much support they offered or helped with customers, etc. If you have a comprehensive insight, you could adjust your expected ratio and incorporate that into the next sprint planning. This approach would help with estimates since it would provide guarantees for the output as included in the roadmap. If the team and a PM would act transparently and inform stakeholders regularly on the status of the features, the result would be understanding and support. If we would notice at any point in time that the possibility of a delay increases, we should immediately inform stakeholders about it. The worst-case scenario would be to keep the information about possible delays till the very delivery day.

Another thing I encountered was a lack of communication between product and engineering. Product would usually hand over the requirements and engineering would deliver on those. Not only that it is rather a Waterfall-ish approach, but it hinders the productivity of engineering. Instead, product and engineering should have an opportunity to design things together, which would additionally help engineers understand the complexity and all edge cases and thus increases the possibility that the estimates would be correct.

Only after those other issues are addressed I would look at the accuracy of estimates. We could create a matrix that reveals the variation or differentiation of estimates. If the variation is high, then the team is clearly not making estimates right. To fix that we could implement the estimation checklist that identifies what should be part of estimates -- code review, QA, deployment, etc. and it should not only include the implantation but design as well.

Lessons learned

  • Most of the time, estimates are not the problem. The problem is, however, that engineering acts as a black box. Specifically, in the case of under-estimated work, I ask engineers to update the stakeholders promptly.
  • It is not the estimates that matter the most, but whether a PM has chosen the right features a team should be working on and that would benefit customers and bring us the most revenue. Therefore, instead of focusing on estimates, we should focus on prioritization.

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader


Related stories

Working From the Ground Up

23 November

Adam Hawkins, Site Reliability Engineer at Skillshare, uprooted an entire product and built it back up again with the help of his team.

Deadlines
Toxic Atmospheres
Adam Hawkins

Adam Hawkins

Site Reliability Engineer at Skillshare

Why Overloading Product Teams Never Work

23 November

Adi Purwanto Sujarwadi, VP of Product at Evermos, shares how he identified the symptoms of his overworked product team and worked towards defining conflicting priorities.

Managing Expectations
Product Team
Deadlines
Stakeholders
Adi Purwanto Sujarwadi

Adi Purwanto Sujarwadi

VP of Product at Evermos

Demystifying the Cult of the Founding Engineer: Talking to Customers and Discovering “Hidden” Talent

23 November

Albert Lie, former Founding Engineer and Tech Lead at Xendit, didn’t know what it takes to become an early engineering hire and not a lot of people around him experienced this unknown and arcane path. He had to learn it the hard way from the pitfalls he encountered along the way and he has been creating numerous frameworks to measure his growth and keep burgeoning in this role since then. He codifies and expresses the systems he put in place surrounding the balance of customer inquiry to product building and growing the engineering team.

Alignment
Meetings
Feedback
Hiring
Prioritization
Albert Lie

Albert Lie

Former Tech Lead at Xendit

Succeeding as a New Product Manager

5 November

Sydney Russakov, Senior Product Manager at LinkedIn, shares how she aced her role as a new PM in a different team.

Remote
Internal Communication
New PM
Prioritization
Sydney Russakov

Sydney Russakov

Senior Product Manager at LinkedIn

How to Encourage Innovation in Your Team

5 November

Prasad Gupte, Director of Product at Babbel, shares how he drove innovation through structure, collaboration, and autonomy.

Innovation / Experiment
Product Team
Collaboration
Prioritization
Prasad Gupte

Prasad Gupte

Director of Product at Babbel

You're a great engineer.
Become a great engineering leader.

Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.