7 ms·

I'm seeing a lot of frustration at the leadership level about product velocity- and much of the frustration is pointed at internal gatekeepers who mainly seem t

by dekhn 1y ago

I'm seeing a lot of frustration at the leadership level about product velocity- and much of the frustration is pointed at internal gatekeepers who mainly seem to say no to product releases. My leadership is currently promoting "better to ask forgiveness", or put another way: "a bias towards action". There are definitely limits on this, but it's been helpful when dealing with various internal negotiations. I don't spend as much time looking to "align with stakeholders", I just go ahead and do things my decades of experience have taught me are the right paths (while also using my experience to know when I can't just push things through).

JTbane 1y ago
> My leadership is currently promoting "better to ask forgiveness", or put another way: "a bias towards action" lol, that works well until a big issue occurs in production
- hkt 1y ago
  Many companies will roll out to slices of production and monitor error rates. It is part of SRE and I would eat my hat if that wasn't the case here.
  - dekhn 1y ago
    Yes, I was SRE at Google (Ads) for several years and that influences my work today. SRE was the first time I was on an ops team that actually was completely empowered to push back against intrusive external changes.
  - crabbone 1y ago
    The big events that shatter everything to smithereens aren't that common or really dangerous: most of the time you can lose something, revert and move on from such an event. The real unmitigated danger of unchecked push to production is the velocity with which this generates technical debt. Shipping something implicitly promises the user that that feature will live on for some time, and that removal will be gradual and may require substitute or compensation. So, if you keep shipping half-baked product over and over, you'll be drowning in features that you wish you never shipped, and your support team will be overloaded, and, eventually, the product will become such a mess that developing it further will become too expensive or just too difficult, and then you'll have to spend a lot of money and time doing it all over... and it's also possible you won't have that much money and time.
- Aperocky 1y ago
  That assume big issue don't occur in production otherwise, with everything having gone through 5 layer of approvals.
  - treis 1y ago
    In that case at least 6 people are responsible so nobody is.
- mgiampapa 1y ago
  Have we learned nothing from Cambridge Analytica?
  - munk-a 1y ago
    We learned not to publish as much information about contracts and to have huge networks of third party data sharing so that any actually concerning ones get buried in noise.
- itronitron 1y ago
  I suppose that's a consequence of having to A/B test everything in order to develop a product
- ponector 1y ago
  But then it also works. Managers can scapegoat engineer who is asking for forgiveness. It's a total win for the management: they take credits if initiative is successful but blame someone else for failure.
  - idrios 1y ago
    Which brings it full circle to engineers saying no to product releases after being burned too harshly by being scapegoated
palmotea 1y ago
> My leadership is currently promoting "better to ask forgiveness", or put another way: "a bias towards action". ... I don't spend as much time looking to "align with stakeholders"... Isn't that "move fast and break things" by another name?
- dekhn 1y ago
  it's more "move fast on a good foundation, rarely breaking things, and having a good team that can fix problems when they inevitably arise".
  - throwawayq3423 1y ago
    That's not what move fast in a large org looks like in practice.
    - dekhn 1y ago
      Sometimes moving fast in a large org boils down to finding a succinct way to tell the lawyer "I understand what you're saying, but that's not consistent with my understanding of the legality of the issue, so I will proceed with my work. If you want to block my process, the escalation path is through my manager." (I have more than once had to explain to a lawyer that their understanding was wrong, and they were imposing unnecessary extra practice)
      - SoftTalker 1y ago
        Raises the question though, why is the lawyer talking to you in the first place, and not your manager?
        xeromal 1y ago
        Isn't that the point of these layoffs? Less obfuscation and games of telephone? The more layers introduces inherent lag.
ihsw 1y ago
[dead]
malthaus 1y ago
... until reality catches up with a software engineer's inability to see outside of the narrow engineering field of view, neglecting most things that the end-users will care about, millions if not billions are wasted and leadership sees that checks and balances for the engineering team might be warranted after all because while velocity was there, you now have an overengineered product nobody wants to pay for.
- varjag 1y ago
  There's little evidence that this is a common problem.
  - KaiserPro 1y ago
    there is in meta. Userneed is very much second to company priority metrics.
    - tru3_power 1y ago
      I wouldn’t say this lends to a bias of over-engineering but more so psc optimizing
  - tomnipotent 1y ago
    Besides the graveyard of failed start-ups? There's plenty of evidence, just no strong conclusions.
    - varjag 1y ago
      Did you look at the graveyard of failed start-ups and conclude they would of lived if they had enough non-coding overhead?
      - tomnipotent 1y ago
        I look at it and see just as many failed start-ups from engineer-founders as a do from non-engineer founders. The idea that being a programmer makes you better to run a business has nothing to back it up.
noosphr 1y ago
Big tech is suffering from the incumbents disease. What worked well for extracting profits from stable cash cows doesn't work in fields that are moving rapidly. Google et al. were at one point pinnacle technologies too, but this was 20 years ago. Everyone who knew how to work in that environment has moved on or moved up. Were I the CEO of a company like that I'd reduce headcount in the legacy orgs, transition them to maintenance mode, and start new orgs within the company that are as insulated from legacy as possible. This will not be an easy transition, and will probably fail. The alternative however is to definitely fail. For example Google is in the amazing position that it's search can become a commodity that prints a modest amount of money forever as the default search engine for LLM queries, while at the same time their flagship product can be a search AI that uses those queries as citations for answers people look for.
- janalsncm 1y ago
  Once you have a golden goose, the risk taking innovators who built the thing are replaced by risk averse managers who protect it. Not killing the golden goose becomes priority 1, 2, and 3. I think this is the steel man of “founder mode” conversation that people were obsessed with a year ago. People obsessed with “process” who are happy if nothing is accomplished because at least no policy was violated, ignoring the fact that policies were written by humans to serve the company’s goals.
  - tharkun__ 1y ago
    This but also: not the managers in the teams that build/"protect" it. But really, leadership above, echoing your parents. I just went through this exercise. I had to estimate the entirety of 2026 based on nothing but a title and a very short conversation based on that for a huge suite of products. Of course none of these estimates make any sense in any way. But all of 2026 is gonna be decided on this. Sort of. Now, if you just let us build shit as it comes up, by competent people - you know, the kind of things that I'd do if you just told me what was important and let me do shit (with both a team and various AI tooling we are allowed to use) then we'd be able to build way more than if you made us estimate and then later commit to it. It's way different if you make me to commit to building feature X and I have zero idea if and how to make it possible and if you just tell me you need something that solves problem X and I get to figure it out as we go. Case in point: In my "spare" time (some of which has been made possible by AI tooling) I've achieved more for our product in certain neglected areas than I ever would've achieved with years worth of accumulated arguing for team capacity. All in a few weeks.
solid_fuel 1y ago
> pointed at internal gatekeepers who mainly seem to say no to product releases. I've never observed facebook to be conservative about shipping broken or harmful products, the releases must be pretty bad if internal stakeholders are pushing back. I'm sure there will be no harmful consequences from leadership ignoring these internal warnings.
- kridsdale1 1y ago
  When I worked there (7 years), the gatekeeper effect was real. It didn’t stop broken or harmful, but it did stop revenue neutral or revenue negative. Even if we had proven the product was positive to user wellbeing or brand-favorability. Yes I’m still bitter.
  - HDThoreaun 1y ago
    Why would a business release a revenue negative product? Stopping engineers from making products that dont contribute to the bottom line is exactly what these gatekeepers should be doing
    - fooker 1y ago
      Because you don't have perfect foresight. Something that loses money now can be the next big thing. ChatGPT is the biggest recent example of this. I had seen chatbot demos at Google as early as 2019.
    - lII1lIlI11ll 1y ago
      Because due to that mindset now FB sucks and no one wants to use it anymore?
      - HDThoreaun 1y ago
        FB ad serve up 10% yoy but no is using it?
        1y ago
jongjong 1y ago
Makes sense. It's easier to be right by saying no, but this mindset costs great opportunities. People who are interested in their own career management can't innovate. You can't innovate without taking career-ending risks. You need people who are confident to take career-ending risks repeatedly. There are people out there who do and keep winning. At least on the innovation/tech front. These people need to be in the driver seat.
- rhetocj23 1y ago
  "You can't innovate without taking career-ending risks." Its not the job of employees to bear this burden - if you have visionary leadership at the helm, they should be the ones absorbing this pressure. And thats what is missing. The reality is folks like Zuck were never visionaries. Lets not derail the thread but a) he stole the idea for facebook b) the continued success of Meta comes from its numerous acquisitions and copying its competitors, and not from organic product innovation. Zuckerberg and Musk share a lot more in common than both would like to admit.
  - jongjong 1y ago
    If we want to maximize justice instead of corporate performance then we have to abolish the system, confiscate corporate wealth and redistribute it equally. That would probably be more just than what we have today... But the corporations would all collapse. It depends what you want to optimize for.
    - danaris 1y ago
      That doesn't mean there isn't a middle ground, y'know—where company/division/organization leaders both advance ideas and take responsibility for them.
kamaal 1y ago
>>I'm seeing a lot of frustration at the leadership level about product velocity- and much of the frustration is pointed at internal gatekeepers who mainly seem to say no to product releases. If we are serious about productivity. I helps to fire the managers. More often than not, this layer has to act in its own self interest. Which means maintaining large head counts to justify their existence. Crazy automation and productivity has been possible for like 50 years now. Its just that nobody wants it. Death of languages like Perl, Lisp and Prolog only proves this point.

by dekhn 1y ago

JTbane 1y ago

> My leadership is currently promoting "better to ask forgiveness", or put another way: "a bias towards action" lol, that works well until a big issue occurs in production

hkt 1y ago
Many companies will roll out to slices of production and monitor error rates. It is part of SRE and I would eat my hat if that wasn't the case here.
- dekhn 1y ago
  Yes, I was SRE at Google (Ads) for several years and that influences my work today. SRE was the first time I was on an ops team that actually was completely empowered to push back against intrusive external changes.
- crabbone 1y ago
  The big events that shatter everything to smithereens aren't that common or really dangerous: most of the time you can lose something, revert and move on from such an event. The real unmitigated danger of unchecked push to production is the velocity with which this generates technical debt. Shipping something implicitly promises the user that that feature will live on for some time, and that removal will be gradual and may require substitute or compensation. So, if you keep shipping half-baked product over and over, you'll be drowning in features that you wish you never shipped, and your support team will be overloaded, and, eventually, the product will become such a mess that developing it further will become too expensive or just too difficult, and then you'll have to spend a lot of money and time doing it all over... and it's also possible you won't have that much money and time.
Aperocky 1y ago
That assume big issue don't occur in production otherwise, with everything having gone through 5 layer of approvals.
- treis 1y ago
  In that case at least 6 people are responsible so nobody is.
mgiampapa 1y ago
Have we learned nothing from Cambridge Analytica?
- munk-a 1y ago
  We learned not to publish as much information about contracts and to have huge networks of third party data sharing so that any actually concerning ones get buried in noise.
itronitron 1y ago
I suppose that's a consequence of having to A/B test everything in order to develop a product
ponector 1y ago
But then it also works. Managers can scapegoat engineer who is asking for forgiveness. It's a total win for the management: they take credits if initiative is successful but blame someone else for failure.
- idrios 1y ago
  Which brings it full circle to engineers saying no to product releases after being burned too harshly by being scapegoated

palmotea 1y ago

> My leadership is currently promoting "better to ask forgiveness", or put another way: "a bias towards action". ... I don't spend as much time looking to "align with stakeholders"... Isn't that "move fast and break things" by another name?

dekhn 1y ago
it's more "move fast on a good foundation, rarely breaking things, and having a good team that can fix problems when they inevitably arise".
- throwawayq3423 1y ago
  That's not what move fast in a large org looks like in practice.
  - dekhn 1y ago
    Sometimes moving fast in a large org boils down to finding a succinct way to tell the lawyer "I understand what you're saying, but that's not consistent with my understanding of the legality of the issue, so I will proceed with my work. If you want to block my process, the escalation path is through my manager." (I have more than once had to explain to a lawyer that their understanding was wrong, and they were imposing unnecessary extra practice)
    - SoftTalker 1y ago
      Raises the question though, why is the lawyer talking to you in the first place, and not your manager?
      - xeromal 1y ago
        Isn't that the point of these layoffs? Less obfuscation and games of telephone? The more layers introduces inherent lag.

ihsw 1y ago

[dead]

malthaus 1y ago

... until reality catches up with a software engineer's inability to see outside of the narrow engineering field of view, neglecting most things that the end-users will care about, millions if not billions are wasted and leadership sees that checks and balances for the engineering team might be warranted after all because while velocity was there, you now have an overengineered product nobody wants to pay for.

varjag 1y ago
There's little evidence that this is a common problem.
- KaiserPro 1y ago
  there is in meta. Userneed is very much second to company priority metrics.
  - tru3_power 1y ago
    I wouldn’t say this lends to a bias of over-engineering but more so psc optimizing
- tomnipotent 1y ago
  Besides the graveyard of failed start-ups? There's plenty of evidence, just no strong conclusions.
  - varjag 1y ago
    Did you look at the graveyard of failed start-ups and conclude they would of lived if they had enough non-coding overhead?
    - tomnipotent 1y ago
      I look at it and see just as many failed start-ups from engineer-founders as a do from non-engineer founders. The idea that being a programmer makes you better to run a business has nothing to back it up.

noosphr 1y ago

Big tech is suffering from the incumbents disease. What worked well for extracting profits from stable cash cows doesn't work in fields that are moving rapidly. Google et al. were at one point pinnacle technologies too, but this was 20 years ago. Everyone who knew how to work in that environment has moved on or moved up. Were I the CEO of a company like that I'd reduce headcount in the legacy orgs, transition them to maintenance mode, and start new orgs within the company that are as insulated from legacy as possible. This will not be an easy transition, and will probably fail. The alternative however is to definitely fail. For example Google is in the amazing position that it's search can become a commodity that prints a modest amount of money forever as the default search engine for LLM queries, while at the same time their flagship product can be a search AI that uses those queries as citations for answers people look for.

janalsncm 1y ago
Once you have a golden goose, the risk taking innovators who built the thing are replaced by risk averse managers who protect it. Not killing the golden goose becomes priority 1, 2, and 3. I think this is the steel man of “founder mode” conversation that people were obsessed with a year ago. People obsessed with “process” who are happy if nothing is accomplished because at least no policy was violated, ignoring the fact that policies were written by humans to serve the company’s goals.
- tharkun__ 1y ago
  This but also: not the managers in the teams that build/"protect" it. But really, leadership above, echoing your parents. I just went through this exercise. I had to estimate the entirety of 2026 based on nothing but a title and a very short conversation based on that for a huge suite of products. Of course none of these estimates make any sense in any way. But all of 2026 is gonna be decided on this. Sort of. Now, if you just let us build shit as it comes up, by competent people - you know, the kind of things that I'd do if you just told me what was important and let me do shit (with both a team and various AI tooling we are allowed to use) then we'd be able to build way more than if you made us estimate and then later commit to it. It's way different if you make me to commit to building feature X and I have zero idea if and how to make it possible and if you just tell me you need something that solves problem X and I get to figure it out as we go. Case in point: In my "spare" time (some of which has been made possible by AI tooling) I've achieved more for our product in certain neglected areas than I ever would've achieved with years worth of accumulated arguing for team capacity. All in a few weeks.

solid_fuel 1y ago

> pointed at internal gatekeepers who mainly seem to say no to product releases. I've never observed facebook to be conservative about shipping broken or harmful products, the releases must be pretty bad if internal stakeholders are pushing back. I'm sure there will be no harmful consequences from leadership ignoring these internal warnings.

kridsdale1 1y ago
When I worked there (7 years), the gatekeeper effect was real. It didn’t stop broken or harmful, but it did stop revenue neutral or revenue negative. Even if we had proven the product was positive to user wellbeing or brand-favorability. Yes I’m still bitter.
- HDThoreaun 1y ago
  Why would a business release a revenue negative product? Stopping engineers from making products that dont contribute to the bottom line is exactly what these gatekeepers should be doing
  - fooker 1y ago
    Because you don't have perfect foresight. Something that loses money now can be the next big thing. ChatGPT is the biggest recent example of this. I had seen chatbot demos at Google as early as 2019.
  - lII1lIlI11ll 1y ago
    Because due to that mindset now FB sucks and no one wants to use it anymore?
    - HDThoreaun 1y ago
      FB ad serve up 10% yoy but no is using it?
      - 1y ago

jongjong 1y ago

Makes sense. It's easier to be right by saying no, but this mindset costs great opportunities. People who are interested in their own career management can't innovate. You can't innovate without taking career-ending risks. You need people who are confident to take career-ending risks repeatedly. There are people out there who do and keep winning. At least on the innovation/tech front. These people need to be in the driver seat.

rhetocj23 1y ago
"You can't innovate without taking career-ending risks." Its not the job of employees to bear this burden - if you have visionary leadership at the helm, they should be the ones absorbing this pressure. And thats what is missing. The reality is folks like Zuck were never visionaries. Lets not derail the thread but a) he stole the idea for facebook b) the continued success of Meta comes from its numerous acquisitions and copying its competitors, and not from organic product innovation. Zuckerberg and Musk share a lot more in common than both would like to admit.
- jongjong 1y ago
  If we want to maximize justice instead of corporate performance then we have to abolish the system, confiscate corporate wealth and redistribute it equally. That would probably be more just than what we have today... But the corporations would all collapse. It depends what you want to optimize for.
  - danaris 1y ago
    That doesn't mean there isn't a middle ground, y'know—where company/division/organization leaders both advance ideas and take responsibility for them.

kamaal 1y ago

>>I'm seeing a lot of frustration at the leadership level about product velocity- and much of the frustration is pointed at internal gatekeepers who mainly seem to say no to product releases. If we are serious about productivity. I helps to fire the managers. More often than not, this layer has to act in its own self interest. Which means maintaining large head counts to justify their existence. Crazy automation and productivity has been possible for like 50 years now. Its just that nobody wants it. Death of languages like Perl, Lisp and Prolog only proves this point.