A better comparison to software I think would be construction of a novel building. Try constructing a geodesic dome house with no experience, and little knowledge of the issues you might run into, but then you’re asked for accurate estimates and then pressured to shorten them.
I need to write 10 more lines, code for 10 for minutes, etc.
Or my personal favorite, bugs fixed!
This isn't the case for sales, different incentive, different result.
A program is not just a program. A bug fix is not just a bug fix. They are not fungible, while sales, definitionally due to the exchange of money, are fungible.
I'd claim that businesses are biased toward chasing a highly fungible sales model, to the point of eliminating the need for a salesperson altogether, and so naturally sales tends to the right.
And a phone call doesn't mean a sale closes.
See conversation upthread.
Every time the probability is non null. Small, but not zero.
Law of big numbers always help scammers. And mediocre sales.
Whereas with code, deleting code and writing less code is very much preferred because each line of code written increases the complexity and risk in the system.
This is why business teams who are shirking discovery and instead focusing on the anti-pattern of trying to increase engineering productivity is such a massive mistake. Not only is the team pooping out code that doesn't fill a need (and hence won't be monetized), but they are also rapidly increasing complexity and opening the business to future liability when the code causes customers to seek remediation.
The quarter driven nature of most companies amplifies this bad behavior. This is why we see this revolving door of executives who come in, drive some bad initiative to incompletion, declare success and move on before their chickens come home to roost.
Everyone in this thread is trying to point out to you that your assumptions about sales are the same as the LoC assumption that equivalently clueless people make about software.
At some level. But numbers aren't created equal and sales reps aren't usually supposed to be calling numbers out of a telephone book. Depending on the type of sales rep, they're hopefully reaching out to people who have been qualified to some degree. The email I got from a sales rep at my own company on Friday afternoon asking for a call about my requirements? That wasn't a well-qualified lead for whatever reason.
You can absolutely work to find other creative solutions to the same problems, or understand what scope is acceptable to cut to meet some goal. That's very different from "I want you to do exactly the same work but just do it faster".
There's plenty of decisions devs make that impact how quickly they deliver a solution.
What’s the incentive for a developer to inflate their estimate? The only reason I have to inflate an estimate is if I know some non-engineer boss-type is going to swoop in and try to convince me to lower it.
Deliver under estimate and get a bonus, raise, influence, or just plain old "well done"
Be lazy and only work half the time while delivering "on time".
Only work on the project half the time, spending the other half on something more worthy/interesting.
This is actually a pretty common motivation for devs who work under legacy management.
Under-promise. Over-deliver. I'm not doing software development most of the time but it absolutely works out better for everyone concerned if I get things done on or ahead of schedule without mostly having to resort to a lot of unnatural acts to do so. If there's a real need for something faster, I'll tell people I'll do my best and (usually) I can get there absent blockers from dependencies. But I try to manage things so that I can meet/beat estimates sanely. It probably helps that people think I work quickly even given some sandbagging.
The problem is that sales can be objectively measured by management. In units.
How does management measure development output?
It can be done, but it take an experienced eng leader to do it.
It’s fun to think you’re special and easy to do when you’re paid a shitload of money.
It is very much unlike operating an established manufacturing facility. But, about two thirds of dev work has a lot of parallels with creating a new manufacturing facility that manufactures a new kind of thing using new materials and techniques. The primary parallel is that a new facility requires a lot of discovery. Whereas if operating an existing facility constantly required a lot of discovery that disrupted operations it is likely the business team would pivot to something more lucrative.
Sadly most developers work in companies that have a manufacturing management system, which is inappropriate for managing development work, primarily because of pressure+timeline patterns typically applied via silo on silo kingdom building.
You really think 2/3 of developers are closer to Columbus setting out for the New World than people cleaning out clogged sewer pipes for the 999,999th time?
For "it's just kluding APIs bro" kind of arguments, I invite you to look at no-code and low-code products and report us how well they work. Is it easy to "kludge together APIs" in this fashion and does it produce viable products? Why? Why not? If it's so easy that it's close to being automated, why can't we have a UI like Photoshop to create API consumer apps?
What cannot be automated has to be exhaustively thought by someone.
An example of IT work is installing MS Office on a laptop by hand.
An example of dev work is integrating VBA into excel so that office users can automate excel using VBA.
As for the Manhattan Project, you might want to think on the difference between the words complexity and difficulty. And then you might consider that when working with nuclear material to create the world's first nuclear bomb, you would want to keep the complexity as low as possible, sheerly out of self preservation.
Then you push it out into the field and you get flooded with calls on it not working. Turns out it only works in your version of Excel on Windows without some particular set of patches installed. Manhattan Project was easy, they didn't have to worry about any backwards/multi-platform compatibility.
If software caused mushroom clouds each time it had a problem in the field, nobody would let MBAs run software projects!
It's Computer Stuff. It's all the same.
If they are in the majority of developers being mismanaged to crank out software that nobody wants, then have them code in an open office space with bullhorn wielding circa 1890s speed bosses yelling at them to type faster. It really makes no difference as most legacy business teams shirk their responsibility to get out of the building and figure out the real needs anyway, so might as well let the devs work on their craft until a real opportunity to make a difference comes along.
If you asked the sales team about a specific deal and they said "We estimate a 70% chance of closing the deal. It'll bring in about $5m in ARR."
If management responded "Could you make that 80% and $7m ARR?" I think that would be a closer analogy.
Sure it might be possible to improve the odds of closing and jack the price up at the same time - just like it might be possible to complete that feature in half the time - but somebody will have to make some major changes or concessions somewhere to make it happen.
Not really, because those are not estimates. Also, consequences are different. With programmers, consequence is typically very buggy and hard to maintain software.
With sales, the consequence is a lot of fraud, followed by firing of every who is not comiting fraud and then even more fraud.
P.S. Not really, you covered it nicely under fraud
The best case is to:
- line up the work in order of priority, taking into account prerequisites
- have sufficient stories in a ready for dev state
- during crunch time, be strategic about ticket assignment (you pay for this in the long term with a less-well-rounded team, so be careful)
- make sure to evaluate every feature to ensure that there are no "nice to haves" mixed in (when under time pressure), or move them to bottom of backlog
- selectively consider consulting with other teams, outside experts (but be sure to really time box this tightly and cut it off once work is under way)
- remove extraneous meetings & distractions; empower devs to decline meetings / block calendars
- borrow from the future by raising the bar on refactoring (ie, only when cost-benefit clearly pays for itself before deadline)
- be very careful that you don't make this approach the standard way of working
Legacy management steeped in manufacturing has entered the chat!
The truth is it really doesn’t matter how many features you deliver, or how many cars you produce.
The real impact is from managerial decisions on customers and products. A car company that does not produce as fast as it could, but produces high-quality, is still going to sell everything that they can make. Same in software. I would argue this is Microsoft and Apple’s model.
If people want it, they can even raise the prices and it won’t make any difference if they make more of them. The same truth exists in software, but everyone wants to talk about productivity because management wants to feel like they’re getting a good deal for the money.
But they’re focused on the wrong aspect of their business. It’s the same as the car business. In software, we say that sometimes you have to slow down to go faster.
Asking meteorologists for sunshine is unequivocally unreasonable, so what you are saying here, I believe, is that the analogy does not apply to sales people, and arguably not in the case of devs either - which I agree with, up to an ill-defined point where wishes lose any contact with reality in any circumstance.
This would be perfectly true if you replace it for a sales estimate, instead of quota.
The problem here is incompetent managers lying to inexperienced developers to get them into an expensive contractual obligation. It's borderline fraud, and yes, that means working with that manager is something to be avoided.
But going to a developer and plainly demanding him to finish the work on some time can be as perfectly fine as doing the same with sales people.
Depending on the economic climate and the situation of the company in the marketplace this may be accurate.
If you've got good sales people that are already selling as hard as they can't you won't be able to squeeze much more out of them if the economy tanks and nobody wants your product.
I'm sure there are sales people who have quit due to "the beatings will continue until the morale improves" situations where their quotas keep going up, which cuts their bonuses, effectively acting like a salary cut, in a bad company.
https://www.justice.gov/opa/pr/wells-fargo-agrees-pay-3-bill...
This isn't to argue that we should just believe developer estimates unconditionally. That's a bigger rabbit hole that I'm too tired to go down right now.
Sales quota is a target, estimate is not a target.
> And yet sales people aren’t writing article after article about how self-set quotas are sacrosanct, should only settable by sales people themselves, and how clueless management is to try to get more performance above the no-brainer target.
You mean you've never came across any post where people complain about unreasonable/unrealistic sales quota?
Hmmm it doesn’t seem unreasonable in that context? You’re really asking people to work more effectively, to accomplish the same amount of work more quickly.
It’s like asking sales people what their quota should be. They pick a number that is no-brainer hittable, because there is a lot of complexity and many unknown variables in getting deals signed, so to prevent looking bad they’ll pad their number. But their no-brainer number is below what the business needs.
So you tell them their quota is going to be a bit higher. They’ll have to stretch to hit it.
And it’s even MORE important since their comp is DIRECTLY tied to hitting that number.
And yet sales people aren’t writing article after article about how self-set quotas are sacrosanct, should only settable by sales people themselves, and how clueless management is to try to get more performance above the no-brainer target.