Human Skills 003 - Estimation and other friction points
Discover more from Human Skills
Human Skills 003 - Estimation and other friction points
with James Rohrbach
How do we make working relationships between engineering and business stakeholders really work? Especially when it comes to high-stress common friction points like estimation?
James Rohrbach is a multiple-time tech entrepreneur, CEO, and investor who has experienced both good and bad relationships with his engineering teams.
In this interview he shares a business perspective on what makes for good working relationships across specialties, how to foster good communication, and a deep dive into estimation as one of the most common sources of friction between business and engineering.
What makes working relationships across specialties work well?
The working relationships were productive when all the stakeholders were grounded in the question of why and were approaching the conversation from the perspective that your why might be different than somebody else's why.
So I might have, from my perspective as the business person, a commercial need to say, "well, we need to build this or design it this way because X". And that X might be, it's the most profitable or it's going to be the fastest growing or it's got the highest addressable market or it's going to be the most attractive to investors or acquirers. There could be any number of reasons.
And similarly, the other stakeholders, as an example technology, might say "Well, I want to build it this way or build something different. And here's my why. We don't have the resources to build this other thing. This thing isn't that interesting. We have this new technology that would be highly differentiated."
And I think if looking forward, I would want to ground even more of our conversations in these first principles. What are the unspoken assumptions driving why you have the position that you have, and then to find common ground from there. And when that's not there and people are just saying, well, this is the way that, this is what we need to do without context, that's when the conversations get unproductive.
Why are development estimates important to the business?
From a business perspective, the reason that estimations are important is because deadlines are real. And deadlines are real even if there's not a, "oh man, this is going to be deployed to a bunch of students at the beginning of the school year, which is the day after Labor Day. And so if this isn't working, we can't go live", that's like a real deadline. But there are also deadlines that I think in the eyes of a non-business stakeholder can be perceived to be not real, but that actually are and can be equally critical for a business.
A lot of what my job as a CEO is... I say my job has three components: set the vision, always make sure there's money in the bank, and hire and retain great people. And for all of those, but particularly on the 'always make sure there's money in the bank', the way that you do that is by making commitments and then delivering on those commitments.
And that can either be an investor where you say, "here's what our roadmap is, we're going to continue to check back in with you and demonstrate progress against that, so you have conviction that we can execute towards our next raise"
Or it can be a client where we say, we're not ready for you yet, but we're gonna have this prepared by X time.
And making those commitments and then delivering on them is not just about, "oh, well, we missed it, it's not a big deal, or oh, well, we said this thing, but it's just words, there's no actually exogenous condition."
That's what builds the conviction and the momentum in the third party stakeholders that actually power your business, whether by providing revenue or providing investment capital.
How do you approach conversations about estimation?
What I often tell people - what I often tell business people when they're complaining to me about a missed deadline or whatnot, is I say, "Hey, remember the last time you built a financial model and you're like, oh yeah, I'll have this done in an afternoon and then two weeks later it's done?"
Everybody's bad at estimating because it's extremely difficult to do. One, it's hard to do because humans can't predict the future and two, it's especially hard to do because when you're building something new for the first time, the amount of stuff that comes up that you can't predict and is going to get in the way...
And the more complex it is, the more risk there is that those things will arise. And to your point, when you're dealing with multi-stakeholders, now you have a whole team that's working on it. I mean, the idea that you can estimate with accuracy, unless you have a track record of doing so in the exact type of environment that you're working in, is I think fundamentally false.
And it's not just engineering teams and technologists who get that wrong, business people get that wrong all the time too. And I think it's important to approach those conversations with the sense of 'estimating is just difficult for developing products and technologies, estimating is difficult for basically doing anything'.
Okay, so now you establish that as the baseline of understanding. And then you have to talk about, all right, well, let's do the best that we can, and then build an enormous amount of buffer on top of that, and then stay very, very closely aligned on it.
It really takes all three of those pieces. And I've seen this go wrong by not having all three of those pieces in lots of different ways.
So if you just say, "well, we don't know, so we're not even going to try to estimate, we're just going to say it's going to be three months," then you haven't actually done any of the thinking really at all to try to articulate, like, "Should it be three months? or maybe it's going to be six..." Let's do some initial scoping here.
Then you obviously have to add buffer. I've done some work in real estate and in construction... you'll add a contingency that's maybe 10 or 20 percent. But when you're talking about developing a product, like your contingency buffer might be 2X. It might be double the time that you thought it was gonna take you.
And so it's critical that you're intellectually honest about that, and you know what? That might be a really hard conversation. Because the business person may say, "I understand, but we're gonna run out of money in six months, and so if we don't get this thing live and you start to get some customers on it, we don't have six months."
But the answer to that conversation isn't that, "okay, well, I guess I'm just gonna tell him it's gonna be three and we'll do the best that we can." Or "maybe we'll get lucky this time and not have to use the contingency budget", because when does that ever happen?
It's like, okay, well then let's collectively scope this way down. And let's agree on what the true minimum viable product is going to be, and really go with that. And if we find in this amazing place that we can build more than that, wonderful, but let's not take that as the base case.
Recommendations from James
Article: The plague of rationalization