One insight that I’ve found pretty ubiquitous in my career is that engineers hate being made to provide estimates on things. Still, in my role selling consulting engagements and projects, estimates were almost always needed and engineering input has been essential in making them. As an engineering leader, I’ve developed a few “best practices” that I’d like to share here:
- Never blame engineers for discrepancies or “hold them to it”
Estimates are by definition subjective. It’s important that engineers feel comfortable making these estimates, don’t start to see them as “deadlines” and definitely don’t feel bad about not guessing the right number. It’s their job to make their best guess with what they know and its your job turn those insights into a formal estimate, set benchmarks and timetables based on them and adjust and communicate with the client if they need to change. If/when the estimate is off resist any urge to blame the engineer, even in jest. Engineers should be focused on making an accurate estimate, not on setting the minimum reasonable goal. Things change, and if you don’t embrace that engineers will either overly pad or feel an unnecessary stress to make these deadlines. For companies that bill hourly this is doubly dangerous. An engineer working “off the books” results in untracked and unbilled hours and means your future estimates will be just an inaccurate resulting in the same stress for the next engineer. - Track everything
Keep track of your estimates, who guessed what, what the end result was, what if anything caused the deviance. This will give you valuable metrics, allow you to understand how well each engineer guesses (I would often have my own padding ratio per person) and when shared with the engineering can lead to them become better at estimating. - Create feedback loops and knowledge sharing
Embrace the retro process, really dig into what the unknown unknowns were. This will allow the individual engineers and the organization itself to get better at making estimates. For new projects, you’ll now have the option to consult both the engineers who will do the work, those done it in the past, and the retros if those engineers are no longer on your team. - Engineers should always get a chance to review the estimate before its submitted
On my projects, I would always let the proposed engineer (if known) take a look at the final proposal before we sent it out. I would include the business and pricing information as well since I prefer to run a transparent organization but if this isn’t possible at least make sure you share the timeline and hourly estimates. This gives the engineer ownership (although once again be careful of rule #1) and adds that extra set of eyes of things you may have missed (vacations, side effects….).
These are my personal rules, they come from years of creating estimates at a cloud consulting company and of course other types of companies and product may deviate. Got thoughts of your own? Let me know on this twitter thread.
