8 ms·

The issue is that you are being asked to estimate something that has never been done before. Even houses always go over time and money and that is fairly straig

The issue is that you are being asked to estimate something that has never been done before. Even houses always go over time and money and that is fairly straight forward. These days, I only give estimates in terms of units but without numbers. Hours, days, weeks, months, quarters or years. Some relatively small number of those units. If you want a quote it will take an extra 1/4 of the estimate worth of time for an exact timeline. I really wish we would treat sales people the same way. "How much money is this contract for? What date will it be signed?"

corry 6y ago
'I really wish we would treat sales people the same way. "How much money is this contract for? What date will it be signed?"'. In well-run sales teams, that is exactly what happens. There is a constant move towards more accuracy and tightness in forecasting. In poorly run sales teams, the reps basically set their owns quotas (padded, of course, to mitigate against massive uncertainty) and then are very imprecise at managing the WIP. Which sounds like a poorly run engineering team too. In sales, though, at least there is a very objective measure ($$$ closed) at the end of the period. Also, the period is fixed typically (months, quarters, etc). Engineering is obviously different... what's the measure? LOCs? Obviously not... Edit: just to be clear, I'm saying that well-run sales teams and well-run engineering teams probably have a lot in common, not that they are exactly the same.
- didibus 6y ago
  I think you're talking about goals, which isn't the same as estimates. A well run sales team, like a well run dev team do benefit from goals. Like increase X by Y. That's because it can guide your decision process of what you'll spend your time on and what you won't. It can also push for focused innovation around a particular area. But I think OP meant what if you asked the sales team: How much time will it take you to close the deal with X? Would they be able to estimate that? Which is different from asking them: "Try and close X Y% faster than it took us to close Z last time." The former would be asking for an estimate, the latter would be setting a goal.
  - xyzelement 6y ago
    Sales team certainly understand the sales cycle and different velocities involved. Eg - two jobs we ago sold to finance playera from small hedge funds to huge asset managers to central banks and finance ministries. You could sell more small hedge funds by knocking on more doors but you understood that the big players took months and years to decide. And of course we always tried to hone the sales org and process to arm the sales people with tools and data to move faster. We certainly held them much more accountable than devs. It's actually not a fair comparison - software development is often like golf - the only limit to your velocity is you while sales can't really move faster than customer's process in many cases. (Yes I obviously know dev processes can have external dependencies too)
    - didibus 6y ago
      Moving faster and increasing impact of deliveries, those are goals you can work towards, that do not involve needing to estimate anything. The question is: do you for every sale provide an ETA of when you think the sale will close, with projected key milestones along the way and their dates, all before even beginning engaging the would be customer?
      - xyzelement 6y ago
        // do you for every sale provide an ETA of when you think the sale will close, with projected key milestones along the way and their dates, all before even beginning engaging the would be customer? No because that's kind of useless. With software, the estimate is (or should be) part of the go-no-go decision for the project. "Oh, it's gonna take us 10 years to build this? Maybe we should reconsider"
    - tikhonj 6y ago
      > the only limit to your velocity is you I have never seen this to be the case outside small, self-contained projects. Even with a fixed scope (its own can of worms), major slow-downs often clearly come from outside the team—unexpected or unreasonable infrastructure limitations, problems with the products of other teams, shortcomings of internal or external tools and libraries, unclear or inconsistent evaluation of the work by its eventual users... etc. Moreover, in cultures tied to estimates-as-quotes (or estimates-as-deadlines), there is often significant pressure for "product" teams not to try to fix these problems, even for themselves. It would be net faster for us to write our own version of X than to try to integrate the work of team Y? But they've already done the work, why would you want to do something redundant? In a world where technical teams have clear ownership, this is less of a problem. Team Y giving you problems? Work around it the best way you can. Infrastructure not supporting your needs? Hack together your own on top of lower-level pieces until it's ready. But organizations with cultures that give technical teams the space to do this also have far less issues with estimates—both in having better estimates and being able to handle estimate uncertainty gracefully.
- chasd00 6y ago
  i think well run teams in general have a lot in common. Not just sales or engineering but all well run teams.
- ballenf 6y ago
  > at least there is a very objective measure ($$$ closed) at the end of the period. That is far from an objective measure standing alone, unless every salesperson generates all their own leads and the distribution of potential leads is random. But generally your more experienced members will get the bigger potential customers. So now you're back at square one trying to judge their success in relation to the anticipated likelihood of their leads.
- sooheon 6y ago
  "$$$ closed at the end of the period" causes negative externalities at the expense of value delivered in the long run (overpromising, misleading, mispricing). This isn't unique to sales/engineering, I've heard of it playing out the same way in "factory" law firms where sales-lawyers and delivery-lawyers are separate.
dkarl 6y ago
> Even houses always go over time and money and that is fairly straight forward. This is an incredibly important point. I was "raised" in commercial software at a time when there was a lot of condescension internally towards ourselves as an industry because we couldn't do estimation and planning, and building was the favorite comparison. A $100 million building couldn't run late or over budget. That would be unimaginable, and it doesn't happen because those people are too serious and professional to let it happen, not like us unserious, immature software doofuses. Turns out that was a complete lie, but at one time it warped the profession, because it made people believe the answers already existed, right around the corner, something you would figure out pretty soon just like last year you didn't know regular expressions and now you did. The problem with that was that when somebody walked in with a button-down shirt, oozing confidence and saying they knew exactly how to consistently deliver software on time and bug-free, those people weren't laughed out of the room. Elaborate heavyweight processes, and their "lightweight" (hah!) cousins, could sell themselves as proven, established solutions. We could believe that bullshit because we had been fed the lie that other industries had conquered these problems.
- meheleventyone 6y ago
  It doesn’t even have to be a big construction project to hit budget and schedule issues. Rebuilding our house had us going right back to the drawing board having to get new plans drafted and approved. It worked out much better in the end but the unforeseen cost and time overrun was quite anxiety inducing at the time. But yeah the idea anyone has magically solved accurately predicting the future is completely bonkers.
  - gugagore 6y ago
    I like to remember "plans are useless but planning is indispensable". The plan is useless because of the challenge of predicting the future. But the planning is useful because trying to predict the future gets you asking good questions.
    - TeMPOraL 6y ago
einpoklum 6y ago
> These days, I only give estimates in terms of units but without numbers. Hours, days, weeks, months, quarters or years. Then you must be either an independent contractor or have some magical source of job security. I couldn't get away with this kind of estimate.
- withinboredom 6y ago
  Probably more to do with personality mix than circumstance. I've had bosses where I could say things like that and get away with it. I've also had bosses where if I said something like that, I'd be packing up my desk.
  - einpoklum 6y ago
    Ok, granted, an enlightened boss might accept that kind of estimate, I suppose. And without the higher-ups breathing down his/her neck.
Ma8ee 6y ago
I used to work for a company that sold custom business systems. When the customers did their parts, i.e., signed of specifications and did their acceptance testing within schedule, we usually delivered within estimate and in time. This was of course applications built with boring technology where 80% was simple CRUD. But the market for this should not be underestimated.
lesdeuxmagots 6y ago
Sales teams do EXACTLY that. Go into salesforce and you’ll see the estimates. Potential deal with client Foo will be for $X, to be signed on Y day, with Z% chance of closing. On an individual level, it may be more precise than it is accurate, but it’s a fairly standard and important part of sales operations. And yes, the estimate dates are often just ways to express orders of magnitude (put next Friday as estimate dates not because it’ll definitely close next Friday, but bc it’ll probably take about 2 weeks). The % chance of closing are typically pre determined by what stage of the deal you’re in. However, when applied across dozens, hundreds, thousands of potential deals, it allows the organization to understand their sales pipeline and sales velocity fairly accurately. Of course the numbers are gamed a bit. And some sales people are much worse at estimating than others, or less consistent about keeping the numbers up to date. But the benefit of these practices are massive.
bluGill 6y ago
Houses have been done before. Enough time that we are good at those estimates. Once you have built the same house a dozen times you can estimate to within a couple hundred dollars. Contractors do this all the time for spec houses. Spec meaning that they are building it and the planning to sell it once it is complete. I know several contractors who do this all the time. They have never had someone order a spec house and come in anywhere close to the estimates. Everyone goes over the light fixture budget ($600) by at least $3000. Similar for the kitchen and bath fixtures. It isn't unheard of to double the cost of the house on seemingly minor upgrades.
pwillia7 6y ago
They do treat sales people that way. Sales is ruthlessly managed and expectations are very important, especially at a public company.
andi999 6y ago
At least for government projects the 'wrong' estimates are intentional. Admins always take the cheapest quote, so to earn money everything happening during construction has to be 'out of scope'. Like winter, or different soil layer than specified, or whatever.
hertzrat 6y ago
Estimating in terms of units is mostly for internal teams with a fixed payroll. It can work really great in that context. But imagine that you are asking for project funding. The person across the table logically wonders: how much do you need? You yourself logically wonder: how much do I ask for? In that environment, can either party really accept “who knows” or “5.5 units” as the answer unless money is not a concern for anybody?
- snarf21 6y ago
  In my opinion, the estimate gives them a sense of scale. If some small number of months would cost too much, then you know and can start to have an investigation project of a week to better help define what should be in and what shouldn't.
aidenn0 6y ago
If you give a bonus for getting done on time/early, construction will finish pretty darn close to the estimates. Construction is underbid at least partly because the incentives are setup for underbidding. A lot of the rest is Planning fallacy[1], particularly with individual contractors, but larger contracting businesses can absolutely come up with realistic estimates based upon past experience. 1: https://en.wikipedia.org/wiki/Planning_fallacy https://en.wikipedia.org/wiki/Planning_fallacy

corry 6y ago

'I really wish we would treat sales people the same way. "How much money is this contract for? What date will it be signed?"'. In well-run sales teams, that is exactly what happens. There is a constant move towards more accuracy and tightness in forecasting. In poorly run sales teams, the reps basically set their owns quotas (padded, of course, to mitigate against massive uncertainty) and then are very imprecise at managing the WIP. Which sounds like a poorly run engineering team too. In sales, though, at least there is a very objective measure ($$$ closed) at the end of the period. Also, the period is fixed typically (months, quarters, etc). Engineering is obviously different... what's the measure? LOCs? Obviously not... Edit: just to be clear, I'm saying that well-run sales teams and well-run engineering teams probably have a lot in common, not that they are exactly the same.

didibus 6y ago
I think you're talking about goals, which isn't the same as estimates. A well run sales team, like a well run dev team do benefit from goals. Like increase X by Y. That's because it can guide your decision process of what you'll spend your time on and what you won't. It can also push for focused innovation around a particular area. But I think OP meant what if you asked the sales team: How much time will it take you to close the deal with X? Would they be able to estimate that? Which is different from asking them: "Try and close X Y% faster than it took us to close Z last time." The former would be asking for an estimate, the latter would be setting a goal.
- xyzelement 6y ago
  Sales team certainly understand the sales cycle and different velocities involved. Eg - two jobs we ago sold to finance playera from small hedge funds to huge asset managers to central banks and finance ministries. You could sell more small hedge funds by knocking on more doors but you understood that the big players took months and years to decide. And of course we always tried to hone the sales org and process to arm the sales people with tools and data to move faster. We certainly held them much more accountable than devs. It's actually not a fair comparison - software development is often like golf - the only limit to your velocity is you while sales can't really move faster than customer's process in many cases. (Yes I obviously know dev processes can have external dependencies too)
  - didibus 6y ago
    Moving faster and increasing impact of deliveries, those are goals you can work towards, that do not involve needing to estimate anything. The question is: do you for every sale provide an ETA of when you think the sale will close, with projected key milestones along the way and their dates, all before even beginning engaging the would be customer?
    - xyzelement 6y ago
      // do you for every sale provide an ETA of when you think the sale will close, with projected key milestones along the way and their dates, all before even beginning engaging the would be customer? No because that's kind of useless. With software, the estimate is (or should be) part of the go-no-go decision for the project. "Oh, it's gonna take us 10 years to build this? Maybe we should reconsider"
  - tikhonj 6y ago
    > the only limit to your velocity is you I have never seen this to be the case outside small, self-contained projects. Even with a fixed scope (its own can of worms), major slow-downs often clearly come from outside the team—unexpected or unreasonable infrastructure limitations, problems with the products of other teams, shortcomings of internal or external tools and libraries, unclear or inconsistent evaluation of the work by its eventual users... etc. Moreover, in cultures tied to estimates-as-quotes (or estimates-as-deadlines), there is often significant pressure for "product" teams not to try to fix these problems, even for themselves. It would be net faster for us to write our own version of X than to try to integrate the work of team Y? But they've already done the work, why would you want to do something redundant? In a world where technical teams have clear ownership, this is less of a problem. Team Y giving you problems? Work around it the best way you can. Infrastructure not supporting your needs? Hack together your own on top of lower-level pieces until it's ready. But organizations with cultures that give technical teams the space to do this also have far less issues with estimates—both in having better estimates and being able to handle estimate uncertainty gracefully.
chasd00 6y ago
i think well run teams in general have a lot in common. Not just sales or engineering but all well run teams.
ballenf 6y ago
> at least there is a very objective measure ($$$ closed) at the end of the period. That is far from an objective measure standing alone, unless every salesperson generates all their own leads and the distribution of potential leads is random. But generally your more experienced members will get the bigger potential customers. So now you're back at square one trying to judge their success in relation to the anticipated likelihood of their leads.
sooheon 6y ago
"$$$ closed at the end of the period" causes negative externalities at the expense of value delivered in the long run (overpromising, misleading, mispricing). This isn't unique to sales/engineering, I've heard of it playing out the same way in "factory" law firms where sales-lawyers and delivery-lawyers are separate.

dkarl 6y ago

> Even houses always go over time and money and that is fairly straight forward. This is an incredibly important point. I was "raised" in commercial software at a time when there was a lot of condescension internally towards ourselves as an industry because we couldn't do estimation and planning, and building was the favorite comparison. A $100 million building couldn't run late or over budget. That would be unimaginable, and it doesn't happen because those people are too serious and professional to let it happen, not like us unserious, immature software doofuses. Turns out that was a complete lie, but at one time it warped the profession, because it made people believe the answers already existed, right around the corner, something you would figure out pretty soon just like last year you didn't know regular expressions and now you did. The problem with that was that when somebody walked in with a button-down shirt, oozing confidence and saying they knew exactly how to consistently deliver software on time and bug-free, those people weren't laughed out of the room. Elaborate heavyweight processes, and their "lightweight" (hah!) cousins, could sell themselves as proven, established solutions. We could believe that bullshit because we had been fed the lie that other industries had conquered these problems.

meheleventyone 6y ago
It doesn’t even have to be a big construction project to hit budget and schedule issues. Rebuilding our house had us going right back to the drawing board having to get new plans drafted and approved. It worked out much better in the end but the unforeseen cost and time overrun was quite anxiety inducing at the time. But yeah the idea anyone has magically solved accurately predicting the future is completely bonkers.
- gugagore 6y ago
  I like to remember "plans are useless but planning is indispensable". The plan is useless because of the challenge of predicting the future. But the planning is useful because trying to predict the future gets you asking good questions.
  - TeMPOraL 6y ago

einpoklum 6y ago

> These days, I only give estimates in terms of units but without numbers. Hours, days, weeks, months, quarters or years. Then you must be either an independent contractor or have some magical source of job security. I couldn't get away with this kind of estimate.

withinboredom 6y ago
Probably more to do with personality mix than circumstance. I've had bosses where I could say things like that and get away with it. I've also had bosses where if I said something like that, I'd be packing up my desk.
- einpoklum 6y ago
  Ok, granted, an enlightened boss might accept that kind of estimate, I suppose. And without the higher-ups breathing down his/her neck.

Ma8ee 6y ago

I used to work for a company that sold custom business systems. When the customers did their parts, i.e., signed of specifications and did their acceptance testing within schedule, we usually delivered within estimate and in time. This was of course applications built with boring technology where 80% was simple CRUD. But the market for this should not be underestimated.

lesdeuxmagots 6y ago

Sales teams do EXACTLY that. Go into salesforce and you’ll see the estimates. Potential deal with client Foo will be for $X, to be signed on Y day, with Z% chance of closing. On an individual level, it may be more precise than it is accurate, but it’s a fairly standard and important part of sales operations. And yes, the estimate dates are often just ways to express orders of magnitude (put next Friday as estimate dates not because it’ll definitely close next Friday, but bc it’ll probably take about 2 weeks). The % chance of closing are typically pre determined by what stage of the deal you’re in. However, when applied across dozens, hundreds, thousands of potential deals, it allows the organization to understand their sales pipeline and sales velocity fairly accurately. Of course the numbers are gamed a bit. And some sales people are much worse at estimating than others, or less consistent about keeping the numbers up to date. But the benefit of these practices are massive.

bluGill 6y ago

Houses have been done before. Enough time that we are good at those estimates. Once you have built the same house a dozen times you can estimate to within a couple hundred dollars. Contractors do this all the time for spec houses. Spec meaning that they are building it and the planning to sell it once it is complete. I know several contractors who do this all the time. They have never had someone order a spec house and come in anywhere close to the estimates. Everyone goes over the light fixture budget ($600) by at least $3000. Similar for the kitchen and bath fixtures. It isn't unheard of to double the cost of the house on seemingly minor upgrades.

pwillia7 6y ago

They do treat sales people that way. Sales is ruthlessly managed and expectations are very important, especially at a public company.

andi999 6y ago

At least for government projects the 'wrong' estimates are intentional. Admins always take the cheapest quote, so to earn money everything happening during construction has to be 'out of scope'. Like winter, or different soil layer than specified, or whatever.

hertzrat 6y ago

Estimating in terms of units is mostly for internal teams with a fixed payroll. It can work really great in that context. But imagine that you are asking for project funding. The person across the table logically wonders: how much do you need? You yourself logically wonder: how much do I ask for? In that environment, can either party really accept “who knows” or “5.5 units” as the answer unless money is not a concern for anybody?

snarf21 6y ago
In my opinion, the estimate gives them a sense of scale. If some small number of months would cost too much, then you know and can start to have an investigation project of a week to better help define what should be in and what shouldn't.

aidenn0 6y ago

If you give a bonus for getting done on time/early, construction will finish pretty darn close to the estimates. Construction is underbid at least partly because the incentives are setup for underbidding. A lot of the rest is Planning fallacy[1], particularly with individual contractors, but larger contracting businesses can absolutely come up with realistic estimates based upon past experience. 1: https://en.wikipedia.org/wiki/Planning_fallacy https://en.wikipedia.org/wiki/Planning_fallacy