'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.
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.
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)
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.
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?
// 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"
Yes, it's like that. You have to move deals through many stages. There's expectations of timing into each stage in addition to quota. Most places will fire even senior sales people if they don't perform for a few quarters.
"$$$ 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.
> 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.
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.