Marco Rogers
Yesterday we had a great conversation about engineers and delivering estimates. I wanna talk about the other side of it too.
For managers and leaders. What do you expect out of engineers when it comes to estimates? How do you evaluate whether you're getting good estimates?
What do you *do* with the estimates you receive from engineers? How does it impact other work activities and timelines?
Finally, how does the ability to give confident estimates factor into how you evaluate your engineers?
Paul Cantrell
@polotek
My spitball into this conversation: managers and engineers alike need to learn to stop thinking about estimates as single numbers and start thinking in •ranges•.
“Could take anywhere from 2 to 14 weeks” is not a prompt to demand more precise estimates (or just take the average of the max or whatever); it’s a prompt to have a conversation about what uncertainty and risk is present, how to manage, how to handle the range of possible outcomes, etc.
Marco Rogers
At tech startups, we have lots of conversations about managing our "runway". We make payroll through a combination of business revenue and funds raised via VC or loans. If that runs out, nobody gets paid. We either have to raise more funding or make enough revenue on our own to keep paying everybody.
A lot of conversations are happening to make sure you continue to get regular paychecks. And your estimates about when you can deliver work are a very real part of those conversations and plans.
Marco Rogers
I'm really trying to improve the way we discuss these issues so that engineers can hear the message. So let me push myself to unpack this statement even further.
What do I mean by "project business metrics"? In the case of tech starts, what that means is we are not profitable. If we run out of money, you don't get a paycheck. So we need to have a forward-looking projection for how much revenue the business will make. Next quarter, and the one after that, and the one after that.
Marco Rogers
Number one is debatable. But I don't care to debate it today. It tends to make people angry. 😂
Number 2 I will absolutely agree with. I think it is part of the management role to help teams organize their work and to manage distractions. However, I don't think that is a solo management task. Engineers need to collaborate on how to be effective at manage distractions.
I am very opposed to the popular "shit umbrella" philosophy of engineering management.
https://im-in.space/@Chip_Unicorn/112374023229088372
Marco Rogers
Confidence intervals are great. The important thing is that they should get refined and narrowed over time. As you get further along, you should become more confident about the delivery timeframe.
I think this practical execution piece is often lacking in estimation processes. If you only deliver a confidence interval once or twice over the course of the project, that's not useful. If the interval never changes, that's not useful.
https://tech.lgbt/@risottobias/112373995567079983
Marco Rogers
Just to remind you of context, my experience is B2B SaaS at tech startups. These are relatively short turnaround cycles. Other types of businesses can have much longer cycles between engineers delivering a thing and other departments picking it up. But the core tension is the same.
If we don't know when the thing will ship, we don't know when other people's work kicks off. And we can't project what will happen with business metrics. That's why estimates matter.
Marco Rogers
So when I receive estimates from engineers, I work with PMs or go-to-market teams to sketch out agreed upon timelines for them to be ready for handoff. Those teams usually have goals driven quarterly KPIs or OKRs.
So for example, "We're on the hook for $2MM in new revenue next quarter. If we can get this new thing from engineering, I can tell my team to push it in sales calls."
Marco Rogers
If we say something is going to be done around this time, and it's not, that impacts other people's real work. This is a core truth that I often struggle to get engineers to engage with. When we say that dates matter, they picture mustache-twisting managers inventing arbitrary deadlines. That does happen sometimes. But it's not at all the norm. The norm is running a business where your work isn't the only work that matters. Coordinating all these activities requires people to commit to dates.
Marco Rogers
I'll give some my own answers. The reason I need estimates from engineers is so we can do planning. It seems simple. But engineers sometimes don't often have an understanding of where their work is situated amongst other business activities.
In the case of B2B SaaS products, when engineering is close to shipping something new, other departments gear up to receive the handoff and make it turn into revenue. That usually means marketing pushes, sales calls, customer success follow-ups, etc.
Marco Rogers
Generally fewer takes on the management side of estimates. I think that's mostly due to my reach on mastodon being still pretty nascent. I appreciate the people who shared their thoughts in the replies.
FWIW, I expected to hear answers on how managers thinks about receiving estimates from engineers. And I did. What I didn't hear about yet is "here's what I do with the estimates once I get them."
I asked that question explicitly to try to create a bridge for engineers to understand the why.
Marco Rogers
Here's the thread from yesterday.
And to be clear. When I ask how you evaluate your engineers, I'm asking explicitly about performance reviews and ultimately promotions/raises.
I know that's a difficult topic to talk about in public. I hope we can get some candid discussion going. I'll share my own thoughts a bit later just like I did yesterday.
https://social.polotek.net/@polotek/112367263499188111
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.