There is a type of negotiation that can be done: Negotiation about scope. Work doesn’t get compressed. But stakeholders can identify non-essential business-facing features and cut scope.

Note well: Automated testing is almost certainly essential. If someone says you are “building an MVP”, then make sure it is an actual MVP. Make sure you have a clear market hypothesis to test and check that it couldn’t be built out of duct tape, Google Forms, Zapier, ITTT, manual processes, and excel-wrangling.

Testing will happen. The choice you make is who does the testing and when it happens. Internal people testing earlier is generally preferable to external customers testing 'live', but either way, the testing will happen.

“We can’t make those UX improvements to our core open-source product because then we’s have to introduce untested code. The current code is tested because users have used it and reported the bugs and we’ve fixed them.” Is a real thing a project lead said to me at a previous employer.

"Or customers are better at finding the bugs than we are so just give it a quick look over and ship it" - genuine quote from CEO at a company I soon left

Honestly, I'm surprised more companies don't formalize this. There are places that offer customers discounts or feature-request priority in return for being beta testers, which seems like a major improvement in both integrity and efficient feedback.

I suppose it's both slower and more expensive than "just ship bad code at full price and wait", but I'd still expect more companies to choose it as the intermediate option between that and comprehensive in-house testing.

> Negotiation about scope.

I used to work for an online travel site - before every project kicked off, the business analysts would produce requirements documents that always started with a "flexibility matrix". The flexibility matrix had three rows labeled "schedule", "scope", and "resources" and three columns: "flexible", "moderately flexible" and "inflexible" and they were supposed to check one option for each row. So every single requirements document listed "resources" and "flexible", "scope" as "moderately flexible" and schedule, OF COURSE, "inflexible".

You sound like you're complaining, but your complaint may be incomplete. If those bullet points were honored, that is indeed how pretty much every organization doing development will operate, whether it likes it or not. That is not intrinsically a problem.

I take it these requirements documents were not honored by your non-developers? A document labeling scope as "moderately inflexible" does little if it's treated as written in stone.

One basis for complaint that stands out to me is framing "flexible resources" as a full degree of freedom.

The first question is of course whether that's true, since resources don't tend to flex up unless someone outside the project dictates it. But even if it's accurate, it tends to produce the situation The Mythical Man-Month was written to condemn. If the ship date can't move and the scope won't bend on core features, there's a very real risk of finding that extra resources can't fix the timeline problems.

You're right that most organizations have to operate this way, and it's not inherently bad; I've just found that "flexible resources" is often used as a way to avoid admitting that the real third category is "risk of failure".

Actually it started out as a 2x2 matrix (scope/schedule), and all of them were scope = flexible and schedule = inflexible (of course), and they started adding the "resources = flexible" row so that they could walk back their claims of scope being flexible, because of course it wasn't.

Wait, how are resources flexible here? You can’t just scale the number of engineers on a project quickly..

We actually tried asking for more resources when the schedule was in "jeopardy" and were told that there weren't any available. They suggested we try working weekends to make up the shortfall.

Good, fast, & cheap - Pick any 2, at most! https://en.wikipedia.org/wiki/Project_management_triangle

Hah! You just described the start of one of our products so accurately it’s scary! And then we built out the parts that were starting to fail as the product scaled. You can get surprisingly far this way!

End of the day, this is what agile is. By accepting scope items in small batches, you end up done.

In his mind there is one negotiable variable, though - how many hours you work. You want to work 40 hours/week, he figures if he can push you to work 80 hours instead, it'll get done twice as fast. The typical CEO's background as a schoolyard bully gives them plenty of experience in this area.

Isn't it the same in price negotiation? Only the producer knows the costs. Perhaps the difference is that money can be shifted around more flexibly. Even if I come out with a negative money balance from a negotiation (costs more than the buyer pays), it might be worth it for long term goals. But you cannot borrow time. You cannot do the 1 week project in -1 weeks and then compensate by doing the next 1 week project in 3 weeks and break even.

A sales negotiation is pretty zero sum. There is little advantage in paying more for the same product.

However, Giving a developer more time will often improve the quality of the output.

Price negotiation is not zero sum. Zero sum means one party’s gain is exactly equal to the other party’s loss. Most deals are positive sum - both parties get benefits. Price negotiation is about the seller getting some the upside of the buyer’s benefits but not so much that it sucks for the buyer and not so low a price that the seller will walk.

Some deals are inherently negative sum - if you bought a lemon.

There is such a thing as negotiating too hard on price. The deliverables have lower cost to benefit than if you paid more money. Or worse no deliverables. Worse than that fatal realized liabilities.

I worked with a group that designed telcom IC's. One of our customers developed a new product. Which then failed in the field. The parent company had to issue a recall. Destroyed all remaining inventory and canceled the product. All because someone jacked the microphone supplier down about 5 cents on a part.

If I pay a dollar more for the same thing, I, the buyer, lose a dollar, and the seller gains a dollar. Can you explain how that's not zero-sum?

If one thing if you are haggling over a used toaster at a yard sale. It's another when you are negotiating a business relationship where the success of both parties is important. A contract with a supplier doesn't do you any good if the terms are so bad it cripples their ability to execute.

That highlights a beef I have with economics. Failure to understand that business relationships are exactly that. You can't model them using the sorts of time invariant non-network models they use.

If you are "negotiating a business relationship" you aren't necessarily haggling on price, but service. This is why I mentioned "the same product"

'The same product' is fleeting and ethereal over the long term.

Yet in the context given, it's timeless and relevant..

Ok, here goes

First, Not everything is a commodity with perfect substitutes, arguably most things aren’t. Substitutability goes beyond price.

Secondly, benefits are not necessarily equal or a linear function of cost.

Third, whether a game is zero, positive, or negative sum requires a look at the costs/benefits of the whole transaction. Saying that a buyer gains $1 more if the price goes up is obvious, it that doesn’t necessarily make it zero sum when you look at the overall transaction of a $1 price raise. .

Zero sum implies that price, costs and benefits are equal. I spend $20 on a product that cost you $20 to make, and I get $20 of benefits out of it.

Whereas I buy something for $20 , it cost you $5 to make, and I got benefits of $100 out of it, that’s positive sum, as both the buyer and seller got positive gain. If you raise the price, the deal isn’t as great, but it’s not zero sum.