6 ms·

Since it's a common misconception: Value =/= cost. Instead of asking your developers "how long would this take to do?", ask the business people, "how long can

by kqr 5y ago

Since it's a common misconception: Value =/= cost. Instead of asking your developers "how long would this take to do?", ask the business people, "how long can we spend on this without losing money on it?" This changes discussions to become much more productive and informative for all parties. Often easier too!

mettamage 5y ago
Don’t you always lose money on it though, since at least one dev should be working on it?
- kqr 5y ago
  Not if it makes you more money in revenue than it costs in developer time. "But isn't that obvious and the case for all developer time?" Try running the numbers some time in your organisation. You'll be surprised at how often things are produced at a loss.
- thunkshift1 5y ago
  No you dont..Paying a dev is not losing money.. why hire the dev in the first place in that case?
  - Juliate 5y ago
    Accounting-wise, it's very common that R&D and developers are counted as cost centers, not profit centers. This is not necessarily a problem, unless the management (and shareholders) only understands costs as an impediment to be pressured and reduced (which is sadly also quite common - and not necessarily false either).
    - chrisweekly 5y ago
      This varies so much across companies, let alone industries. It was gratifying a few years back to realize that annual revenue per engineer north of $4m put our team in rarified company. I wonder how common it is to examine that metric. While I'm happier (and earning much more) consulting for a deep-pocketed enterprise where enginering and R&D are treated as cost centers, I kind of doubt it's something my current clients have ever even considered.
      - judge2020 5y ago
        But adding or removing developers doesn't add or remove that revenue. If some exec wants to make a show by increasing (short-term) profit, cutting developers is a quick and dirty to do that.
- VBprogrammer 5y ago
  I think the conversation is what is the expected return vs the cost. Honestly, I'm not sure I'd really like to have that conversation with the business people too often. Once a product is complete I doubt many feature enhancement have a decent business case.
kavunr 5y ago
https://basecamp.com/shapeup https://basecamp.com/shapeup seems to understand this at a core level in a better way than scrum.
thomasahle 5y ago
> ask the business people, "how long can we spend on this without losing money on it?" Presumably you'd want the developers "How much value can you create in time `t`", v(t), and the business people "how much money will we lose in time `t`", l(t). And then you'll find the maximum of `v(t)-l(t)`. The problem of course is how much communication it takes between the two groups to optimize this. And how well they can actually estimate.
e1g 5y ago
Asking that would signal a profound miscalibration in your understanding of how businesses work (unless the only thing your company does is sell your billable hours). For example, nearly every startup is losing money until they become a unicorn (and often, well after) - this doesn't imply that what their developers/ops people do all day is worth either "nothing" or "billions".
- kqr 5y ago
  But someone in the business ought to have estimated the impact of a task, and it's very useful for developers to be in on that discussion because then they can suggest alternatives that are way cheaper but still worth just as much, or that cost slightly more but would also be worth so much more. And that's just the immediate benefit. It goes beyond that to organisational learning and being able to calibrate past estimates and get better at picking high value fruit rather than just the low-hanging ones or the ones someone has a good gut feeling about. But in my experience from organisations both small and large, new and old, is that it's actually a huge mental shift required to go from "this sounds neat let's do this" to - How exactly do we actually think doing this will help us in the long run? - How would we express that in dollars to be able to compare it with other things? - How soon will we be able to tell that we were wrong?
  - e1g 5y ago
    Say you're building an enterprise SaaS, and several of your VIP customers ask for a button to "Export this table into Excel for offline analysis". These customers are paying >$100k p.a., and not threatening to leave or anything, but it's a feature you think would be valuable for the core product. You ask a developer to build this, and they ask, "How long can I spend on this before we're losing money?". There are several ways to answer, but few are polite. While every business has some prioritization matrix/process, rigorously estimating the "marginal revenue" for each movement in the dance would add friction and internal transaction costs that make the business not viable.
    - kqr 5y ago
      The nice thing about estimates is that you can make them at whatever confidence level is sensible. If a precise estimation (which is what it seems like you think of) adds too much friction and internal transaction costs, make it at a different confidence level. So in your specific example, you might go, "I can't give you the exact tipping point right now, but I'm 98 % certain it's worth more than five days. So if you end up spending four days on it and it's still not done, come back to me for a more precise estimate."

by kqr 5y ago

mettamage 5y ago

Don’t you always lose money on it though, since at least one dev should be working on it?

kqr 5y ago
Not if it makes you more money in revenue than it costs in developer time. "But isn't that obvious and the case for all developer time?" Try running the numbers some time in your organisation. You'll be surprised at how often things are produced at a loss.
thunkshift1 5y ago
No you dont..Paying a dev is not losing money.. why hire the dev in the first place in that case?
- Juliate 5y ago
  Accounting-wise, it's very common that R&D and developers are counted as cost centers, not profit centers. This is not necessarily a problem, unless the management (and shareholders) only understands costs as an impediment to be pressured and reduced (which is sadly also quite common - and not necessarily false either).
  - chrisweekly 5y ago
    This varies so much across companies, let alone industries. It was gratifying a few years back to realize that annual revenue per engineer north of $4m put our team in rarified company. I wonder how common it is to examine that metric. While I'm happier (and earning much more) consulting for a deep-pocketed enterprise where enginering and R&D are treated as cost centers, I kind of doubt it's something my current clients have ever even considered.
    - judge2020 5y ago
      But adding or removing developers doesn't add or remove that revenue. If some exec wants to make a show by increasing (short-term) profit, cutting developers is a quick and dirty to do that.
VBprogrammer 5y ago
I think the conversation is what is the expected return vs the cost. Honestly, I'm not sure I'd really like to have that conversation with the business people too often. Once a product is complete I doubt many feature enhancement have a decent business case.

kavunr 5y ago

https://basecamp.com/shapeup https://basecamp.com/shapeup seems to understand this at a core level in a better way than scrum.

thomasahle 5y ago

> ask the business people, "how long can we spend on this without losing money on it?" Presumably you'd want the developers "How much value can you create in time `t`", v(t), and the business people "how much money will we lose in time `t`", l(t). And then you'll find the maximum of `v(t)-l(t)`. The problem of course is how much communication it takes between the two groups to optimize this. And how well they can actually estimate.

e1g 5y ago

Asking that would signal a profound miscalibration in your understanding of how businesses work (unless the only thing your company does is sell your billable hours). For example, nearly every startup is losing money until they become a unicorn (and often, well after) - this doesn't imply that what their developers/ops people do all day is worth either "nothing" or "billions".

kqr 5y ago
But someone in the business ought to have estimated the impact of a task, and it's very useful for developers to be in on that discussion because then they can suggest alternatives that are way cheaper but still worth just as much, or that cost slightly more but would also be worth so much more. And that's just the immediate benefit. It goes beyond that to organisational learning and being able to calibrate past estimates and get better at picking high value fruit rather than just the low-hanging ones or the ones someone has a good gut feeling about. But in my experience from organisations both small and large, new and old, is that it's actually a huge mental shift required to go from "this sounds neat let's do this" to - How exactly do we actually think doing this will help us in the long run? - How would we express that in dollars to be able to compare it with other things? - How soon will we be able to tell that we were wrong?
- e1g 5y ago
  Say you're building an enterprise SaaS, and several of your VIP customers ask for a button to "Export this table into Excel for offline analysis". These customers are paying >$100k p.a., and not threatening to leave or anything, but it's a feature you think would be valuable for the core product. You ask a developer to build this, and they ask, "How long can I spend on this before we're losing money?". There are several ways to answer, but few are polite. While every business has some prioritization matrix/process, rigorously estimating the "marginal revenue" for each movement in the dance would add friction and internal transaction costs that make the business not viable.
  - kqr 5y ago
    The nice thing about estimates is that you can make them at whatever confidence level is sensible. If a precise estimation (which is what it seems like you think of) adds too much friction and internal transaction costs, make it at a different confidence level. So in your specific example, you might go, "I can't give you the exact tipping point right now, but I'm 98 % certain it's worth more than five days. So if you end up spending four days on it and it's still not done, come back to me for a more precise estimate."