6 ms·

I once had a manager/CEO who thought you can negotiate the planning, the same as like a price. "The customer always wants to get it earlier, the engineer later"

I once had a manager/CEO who thought you can negotiate the planning, the same as like a price. "The customer always wants to get it earlier, the engineer later". Me saying that only the developer is able to give a realistic planning, was probably received as "developer wants to push the deadline back in his negotiation". In the end, his company went bust because he was selling stuff to customers that could never be delivered on time, or even never at all.

afarrell 8y ago
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.
- drunkpotato 8y ago
  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!
- mgkimsal 8y ago
  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.
  - afarrell 8y ago
    “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.
    - philk10 8y ago
      "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
      - Bartweiss 8y ago
        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.
- Spooky23 8y ago
  End of the day, this is what agile is. By accepting scope items in small batches, you end up done.
- commandlinefan 8y ago
  > 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".
  - jerf 8y ago
    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.
    - Bartweiss 8y ago
      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".
      - commandlinefan 8y ago
        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.
- c0vfefe 8y ago
  Good, fast, & cheap - Pick any 2, at most! https://en.wikipedia.org/wiki/Project_management_triangle https://en.wikipedia.org/wiki/Project_management_triangle
bonoboTP 8y ago
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.
- Chris2048 8y ago
  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.
  - parasubvert 8y ago
    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.
    - Chris2048 8y ago
      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?
      - parasubvert 8y ago
        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.
commandlinefan 8y ago
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.

afarrell 8y ago

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.

drunkpotato 8y ago
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!
mgkimsal 8y ago
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.
- afarrell 8y ago
  “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.
  - philk10 8y ago
    "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
    - Bartweiss 8y ago
      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.
Spooky23 8y ago
End of the day, this is what agile is. By accepting scope items in small batches, you end up done.
commandlinefan 8y ago
> 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".
- jerf 8y ago
  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.
  - Bartweiss 8y ago
    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".
    - commandlinefan 8y ago
      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.
c0vfefe 8y ago
Good, fast, & cheap - Pick any 2, at most! https://en.wikipedia.org/wiki/Project_management_triangle https://en.wikipedia.org/wiki/Project_management_triangle

bonoboTP 8y ago

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.

Chris2048 8y ago
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.
- parasubvert 8y ago
  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.
  - Chris2048 8y ago
    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?
    - parasubvert 8y ago
      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.

commandlinefan 8y ago

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.