3 ms·

I agree that the points you raise are important to realise and affect delivery duration significantly. I, however, disagree with that approach to managing deli

I agree that the points you raise are important to realise and affect delivery duration significantly. I, however, disagree with that approach to managing delivery: if you tie in expected value with deliverables, you empower and enable engineering teams to smartly cut scope and deliver in shorter amount of time the biggest chunk of the value. It's usually only described as "cutting scope", but it requires real creativity and smarts on the engineering team (they can best tell what's feasible in remaining time, when they have tackled all the unknown unknowns you bring up) to do that in a way that still brings the most of the original value. If you move this to your "renegotiation" step, it becomes too slow and hurts delivery as well.

msteffen 2y ago
I basically agree (I think) in that I don’t think there needs to be a separate “cutting scope” phase—one should it as soon as they realize they need to. And I certainly agree that it’s incumbent on engineering to invent alternatives and propose them when we realize that we need to cut scope (for the reasons you mentioned). FWIW, though, engineers shouldn’t decide what to cut (i.e. choose alternatives) in a vacuum, in my experience. I’ve been in plenty of meetings with product/sales/support where they say “it’s better for the whole project to slip than to release it without this one detail” or “we would give up what seems like basic usability to get one particular piece of polish”
- necovek 2y ago
  Yes, totally agreed that engineers should not "decide" in a vacuum. But if they understand what value was supposed to be brought, have a decent product/customer focus, and are creative enough, they can propose good alternatives and not stall the delivery. I've also experienced things you mention, but it was always in orgs where everything, including any small feature, was treated as a "big bet": unsupported by metrics (no matter how imperfect), but instead wishful thinking that it will bring meaningful improvement. As such, you can't come up with anything that's an equally good improvement with less effort because there is no baseline to compare against.
  - msteffen 2y ago
    > I've also experienced things you mention, but it was always in orgs where everything, including any small feature, was treated as a "big bet": unsupported by metrics (no matter how imperfect), but instead wishful thinking that it will bring meaningful improvement. As such, you can't come up with anything that's an equally good improvement with less effort because there is no baseline to compare against. Interesting, that’s exactly the situation I was in, but I never connected the lack of metrics to these kinds of requests. TIL. I feel like I have lot to say about how this manifested. Product direction was very heavily guided by existing customers (because support could say “we have these three customers asking for X”), somewhat guided by closing deals (because sales could say “we have a $$$ deal that the customer says will close if we deliver Y”) and hardly guided at all by the broader market, because product’s suggestions could only ever be supported by speculation and vibes. But we were B2B, so I don’t even know what good metrics would’ve looked like—it’s not like we had billions of users

msteffen 2y ago

I basically agree (I think) in that I don’t think there needs to be a separate “cutting scope” phase—one should it as soon as they realize they need to. And I certainly agree that it’s incumbent on engineering to invent alternatives and propose them when we realize that we need to cut scope (for the reasons you mentioned). FWIW, though, engineers shouldn’t decide what to cut (i.e. choose alternatives) in a vacuum, in my experience. I’ve been in plenty of meetings with product/sales/support where they say “it’s better for the whole project to slip than to release it without this one detail” or “we would give up what seems like basic usability to get one particular piece of polish”

necovek 2y ago
Yes, totally agreed that engineers should not "decide" in a vacuum. But if they understand what value was supposed to be brought, have a decent product/customer focus, and are creative enough, they can propose good alternatives and not stall the delivery. I've also experienced things you mention, but it was always in orgs where everything, including any small feature, was treated as a "big bet": unsupported by metrics (no matter how imperfect), but instead wishful thinking that it will bring meaningful improvement. As such, you can't come up with anything that's an equally good improvement with less effort because there is no baseline to compare against.
- msteffen 2y ago
  > I've also experienced things you mention, but it was always in orgs where everything, including any small feature, was treated as a "big bet": unsupported by metrics (no matter how imperfect), but instead wishful thinking that it will bring meaningful improvement. As such, you can't come up with anything that's an equally good improvement with less effort because there is no baseline to compare against. Interesting, that’s exactly the situation I was in, but I never connected the lack of metrics to these kinds of requests. TIL. I feel like I have lot to say about how this manifested. Product direction was very heavily guided by existing customers (because support could say “we have these three customers asking for X”), somewhat guided by closing deals (because sales could say “we have a $$$ deal that the customer says will close if we deliver Y”) and hardly guided at all by the broader market, because product’s suggestions could only ever be supported by speculation and vibes. But we were B2B, so I don’t even know what good metrics would’ve looked like—it’s not like we had billions of users