> 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?

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".

That's not what move fast in a large org looks like in practice.

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)

Raises the question though, why is the lawyer talking to you in the first place, and not your manager?

Well, let's give a concrete example. I want to use an SaaS as part of my job. My manager knows this and supports it. In the process of me trying to sign up for the SaaS, I have to contact various groups in the company- the cost center folks to get an approval for spending the money to get the SaaS, the security folk to ensure we're not accidentally leaking IP to the outside world, the legal folks to make sure the contract negotiations go smoothly.

Why would the lawyer need to talk to my manager? I'm the person getting the job done, my manager is there to support me and to resolve conflicts in case of escalations. In the meantime, I'm going to explain patiently to the lawyer that the terms they are insisting on aren't necessary (I always listen carefully to what the lawyer says).

So then the poor lawyer thinks "so why the hell did you ask me?"

> I have to contact various groups in the company- the cost center folks to get an approval for spending the money to get the SaaS, the security folk to ensure we're not accidentally leaking IP to the outside world, the legal folks to make sure the contract negotiations go smoothly.

I guess I was assuming (maybe wrongly) that you are an engineer/developer of some sort. All of that work sounds like manager work to me. Why is an IC dealing with all of that bureaucratic stuff? Doesn't they all ultimately need your manager's approval anyway?

I only started managing people recently (and still do some engineering and development, along with various project management- my job title is "Senior Principal Machine Learning Engineer - so not really even a management track).

I have a lot of experience doing this sort of work (IE, some product management, project management, customer/stakeholder relationships, vendor relationships, telling the industrial contractor where to cut a hole in the concrete for the fiber, changing out the RAM on a storage server in the data center, negotiate a multi-million dollar contract with AWS, give a presentation at re:Invent to get a discount on AWS, etc) because really, my goal is to make things happen using all my talents.

I work with my manager- I keep him up to date on stuff, but if I feel strongly about things, and document my thinking, I can generally move with a fair level of autonomy.

It's been that way throughout my career- although I would love to just sit around and work on code I think is useful, I've always had to carry out lots of extra tasks. Starting as a scientist, I had to deal with writing grants and networking at conferences more than I had time to sit around in the lab running experiments or writing code. Later, working as an IC in various companies, I always found that challenging things got done quicker if I just did them myself rather than depending on somebody else in my org to do it.

"Manager" means different things, btw. There's people managers, product managers, project managers, resource managers. Many of those roles are implemented by IC engineer/developers.

"Manager" means different things, btw.

Certainly, and its interesting to see your perspective. At most of my jobs, if I needed a subscription to a SaaS (the earlier example) I'd tell my manager, explain my reasons, and they'd deal with purchasing, legal, security, etc. as needed, maybe looping me in if there was a technical question they could not answer.

A lot of times, they do. But where I'm at, lawyers have the last say for some reason. A good example is our sub/sister companies. Our lawyers told us that we needed separate physical servers for their fucking VMs and IAM. We have a fucking data center and they wanted us to buy new hardware.

We fought and tried to explain that what they were asking didn't even make sense, all of our data and IAM is already under the same M365 tenant and other various cloud services. We can't take that apart, it's just not possible.

They wouldn't listen and are completely incapable of understanding so we just said "ok, fine" and I was told to just ignore them.

The details were forgotten in the quagmire of meetings and paperwork, and the sun rose the next day in spite of our clueless 70+ year old legal team.

Isn't that the point of these layoffs? Less obfuscation and games of telephone? The more layers introduces inherent lag.

The real question is, how/why did they over-hire in the first place?

> The real question is, how/why did they over-hire in the first place place

This question has been answered many times. Time to move on and fix forward.

I havent seen a single answer that isnt surface level stuff.

Reasons in the press over the last two years or so are due to factors like aggressive growth projections, the availability of cheap capital, and the pandemic-driven surge in demand for online services.

But why do YOU care? Are you trying learn so you can avoid such traps in your own company that you run? Maybe you are trying to understand because you’ve been affected? Or maybe some other reason?

That's the polar opposite of what "better to ask forgiveness," "bias towards action," or "I don't spend as much time looking to 'align with stakeholders'" mean. They, by definition, mean acting on your own agenda as quickly as possible before anyone else affected can voice their concerns. This is consistent with how Facebook has been behaving all along: from gathering images of female college students without consent to rate their appearance, to tricking teenagers into installing spyware VPNs to undermine competitors[1], and even promoting ragebait content that has contributed to societal destabilization, including exacerbating a massacre[2].

You can't label others as mere nuisance and simultaneously claim to respect them when faced with criticism.

[1]: https://techcrunch.com/2019/02/21/facebook-removes-onavo/

[2]: https://www.theguardian.com/technology/2021/dec/06/rohingya-...

Yup. And if this were a Chinese company, people would be calling it “chabuduo.”

I don't think that's the correct translation. Chabuduo is also the mindset of the guy that doesn't give a damn anymore, and just wants to produce the bare minimum.

Move fast and break things is more of an understanding that "rapid innovation" comes with rapid problems. It's not a "good enough" mindset, it's a "let's fuckin do this cowboy style!" mindset.

> 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

That assume big issue don't occur in production otherwise, with everything having gone through 5 layer of approvals.

In that case at least 6 people are responsible so nobody is.

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.

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.

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.

Have we learned nothing from Cambridge Analytica?

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.

I suppose that's a consequence of having to A/B test everything in order to develop a product

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.

Which brings it full circle to engineers saying no to product releases after being burned too harshly by being scapegoated

... 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.

There's little evidence that this is a common problem.

there is in meta.

Userneed is very much second to company priority metrics.

I wouldn’t say this lends to a bias of over-engineering but more so psc optimizing

Besides the graveyard of failed start-ups? There's plenty of evidence, just no strong conclusions.

Did you look at the graveyard of failed start-ups and conclude they would of lived if they had enough non-coding overhead?

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.

I'm not sure where this idea comes from though, it's not something I argued. The post I replied to claims engineers can't see the big picture and deal with end user requirements, and your own testimony above contradicts that.

You’re on the mark - this is the real challenge in software development. Not building software, but building software that actually accomplished the business objective. Unless of course you’re just coding for other reasons besides profit.

I agree... but not at the engineering level.

This is, IMO, a leadership-level problem. You'll always (hopefully) have an engineering manager or staff-level engineer capable of keeping the dev team in check.

I say it's a leadership problem because "partnering with X", "getting Y to market first", and "Z fits our current... strategy" seem to take precedence over what customers really ask for and what engineering is suggesting actually works.

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.

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.

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.

Feels like this is the fundamental flaw with a lot of things not just in the private sector, but the public one too.

Look at the FDA, where it's notoriously bogged down in red tape, and the incentives slant heavily towards rejection. This makes getting pharmaceuticals out even more expensive, and raises the overall cost of healthcare.

It's too easy to say no, and people prioritize CYA over getting things done. The question then becomes how do you get people (and orgs by extension), to better handle risk, rather than opting for the safe option at every turn?

You have a flawed understanding of the FDA pharmaceutical approval process. There is no bias towards either rejection or approval. If an drug application checks all the required boxes then it will be approved.

I think the reason why some people mistakenly think this makes healthcare more expensive is that over recent years the FDA has raised the quality bar on the clinical trials data they will accept. A couple decades ago they sometimes approved drugs based on studies that were frankly junk science. Now that standards have been raised, drug trials are generally some of the most rigorous, high-quality science you'll find anywhere in the world. Doing it right is necessarily expensive and time consuming but we can have pretty high confidence that the results are solid.

For patients who can't wait there is the Expanded Access (compassionate use) program.

https://www.fda.gov/news-events/public-health-focus/expanded...

I take your broader point but personally I feel like it’s ok if the FDA is cautious. The incentives that bias towards rejection may be “not killing people”.

What about the people who die because a safe and effective drug that could have saved their life got rejected? The problem is that there's a fundamental asymmetry here - those deaths are invisible but deaths from a bad drug that got approved are very visible.

I mean drugs are different than consumer technology. Instagram isn’t great but it doesn’t cause birth defects. Also things like the compassionate release of hiv drugs in study show the govt can see the nuance here with enough pressure.

Yes, but it also doesn't save babies that die from currently incurable diseases.

Always saying no to new tech is "safe" , but it also keeps you in the stone age.

Or, to cite a more recent example, fast-tracking COVID-19 vaccine approval.

I deliberately chose the FDA here specifically because of this. The problem here is that on a societal level, we have to be willing to tolerate some risk. If a drug could have saved many, but is rejected because of occasional complications, that sounds like a poor cost benefit analysis.

For “as insulated as possible”, I’d personally start a whole new corporate entity, like Verizon did with Visible.

It wholly owns Visible, and Visible is undercutting Verizon by being more efficient (similar to how Google Fi does it). I love the model – build a business to destroy your current one and keep all of the profits.

IIRC Intuit did that for QBO. Put a new team off-site and everything. The story I read is old (maybe was a business book) and my motivated searches gave nothing.

From what I remember it was also about splitting the finance reporting - so the up-start team isn't compared to the incumbent but to other early teams. Let's them focus on the key metrics for their stage of the game.

> Google et al. were at one point pinnacle technologies too, but this was 20 years ago.

In 2017 Google literally gave us transformer architecture all current AI boom is based on.

That does remind a little of Kodak, inventing the digital camera.

And what did they do with it for the next five years?

Well, there was this wild two year drama where they had people fight and smear each other over whether wasting energy for LLMs is ethical.

https://www.cnet.com/tech/tech-industry/google-ai-chief-says...

That made plenty of scientists and engineers at google avoid AI for a while.

Used it to do things? This seems like a weird question. OpenAI took about the same amount of time to go big as well (Sam was excited about open AI in 2017, but it took 5+ years for it to pan out into something used by people).

I think the point is that they hoarded the technology for internal use instead of opening it up to the public, like OpenAI did with ChatGPT, thus kicking off the current AI revolution.

As sibling comments indicate, reasons may range from internal politics to innovator's dilemma. But the upshot is, even though the underlying technology was invented at Google, its inventors had to leave and join other companies to turn it into a publicly accessible innovation.

So I started at Google in 2020 (after Sam closed our lab down in 2017 to focus on OpenAI), and if they were hoarding it, I at least had no clue about it. To be clear, my perspective is still limited.

Fair enough, maybe a better way to put it is: why was the current AI boom sparked by ChatGPT and not something from Google? It's clear in retrospect that Google had similar capabilities in LaMDA, the precursor to Gemini. As I recall it was even announced a couple years before ChatGPT but wasn't released (as Bard?) until after ChatGPT.

LaMDA is probably more famous for convincing a Google employee that it was sentient and getting him fired. When I heard that story I could not believe anybody could be deceived to that extent... until I saw ChatGPT. In hindsight, it was probably the first ever case of what is now called "AI psychosis". (Which may be a valid reason Google did not want to release it.)

Google had been burned badly in multiple previous launches of ML-based products and their leadership was extremely cautious about moving too quickly. It was convenient for Google that OpenAI acted as a first mover so that Google could enter the field after there was some level of cultural acceptance of the negative behaviors. There's a whole backstory where Noam Shazeer had come up with a bunch of nice innovations and wanted to launch them, but was only able to do so by leaving and launching through his startup- and then returned to Google, negotiating a phenomenal deal (Noam has been at Google for 25 years and has been doing various ML projects for much of that time).

> badly in multiple previous launches of ML-based products

Which ML-based products?

> It was convenient for Google that OpenAI acted as a first mover

That sounds like something execs would say to fend of critics. "We are #2 in AI, and that's all part of the plan"

Thanks for the helpful context. Google being risk averse is definitely a common criticism I've heard. I can't think of what previous problematic launches could have been, but ironically all the ones I remember offhand were after the release of Gemini!

This is the canonical example: https://www.nytimes.com/2023/05/22/technology/ai-photo-label...

Some more details in https://www.nytimes.com/2021/03/15/technology/artificial-int...

I think "hoarding" is the wrong connotation. They were happy to have it be a fun research project alongside alphago while they continued making money from ads.

Pre-ChatGPT OpenAI produced impressive RL results but their pivot to transformers was not guaranteed. With all internet data, infinite money, and ~800x more people, Google's internal LLMs were meh at best, probably because the innovators like Radford would constantly be snubbed by entrenched leaders (which almost happened in OpenAI).

Damn, those goal posts moved fast.

and then sat on it for half a decade because they worried it would disrupt their search empire. Googles invention of transformers is a top 10 example of the innovators dilemma.

> 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.

Didn't Netflix do this when they went from DVDs to online streaming?

Cisco, too. Whether or not you want to consider current Cisco a success model is... yeah

I seldom quote Steve Jobs, but: "If you don't cannibalize yourself, someone else will."

Which is amusing if you look at Apple's product lines and there's several decisions and examples across each that have specs/features that are clearly about delineation and preventing cannibalization.

Your intuition is right. I work at a big corp right now and the average age in the operations department is probably just under 50. That's not to say age is bad, however... these people have never worked anywhere else.

They are completely stuck in the 90s. Almost nothing is automated. Everyone clicks buttons on their grossly outdated tools.

Meetings upon meetings upon meetings because we are so top heavy that if they weren't constantly in meetings, I honestly don't know what leadership would do all day.

You have to go through a change committee to do basic maintenance. Director levels gatekeep core tools and tech. Lower levels are blamed when projects faceplant because of decades of technical debt. No one will admit it because it (rightly) shows all of leadership is completely out of touch and is just trying their damnedest to coast to retirement.

The younger people that come into the org all leave within 1-2 years because no one will believe them when they (rightly) sound the whistle saying "what the fuck are we doing here?" "Oh, you're just young and don't know what working in a large org is like."

Meanwhile, infra continues to rot. There are systems in place that are complete mysteries. Servers whose functions are unknown. You want to try to figure it out? Ok, we can discuss 3 months from now and we'll railroad you in our planning meetings.

When it finally falls over, it's going to be breathtaking. All because the fixtures of the org won't admit that they haven't kept up on tech at all and have no desire to actually do their fucking job and lead change.

You know in the 90s we were saying the same thing:

> They are completely stuck in the 70s. Almost nothing is automated. Everyone types CLI commands into their grossly outdated tools

I'm sure 30 years from now kids will have the same complaints.

CLI would be an upgrade. You're misunderstanding what I'm saying.

> Meetings upon meetings upon meetings because we are so top heavy that if they weren't constantly in meetings, I honestly don't know what leadership would do all day.

Hah, at a previous employer (and we were only ~300 people), we went through three or four rounds of layoffs in the space of a year (and two were fairly sizeable), ending up with ~200. But the "leadership team" of about 12-15 always somehow found it necessary to have an offsite after each round to ... tell themselves that they'd made the right choice, and we were better positioned for success and whatever other BS. And there was never really any official posting about this on company Slack, etc. (I wonder why?) but some of the C-suite liked to post about them on their LI, and a lot of very nice locations, even international.

Just burning those VC bucks.

> You have to go through a change committee to do basic maintenance. Director levels gatekeep core tools and tech. Lower levels are blamed when projects faceplant because of decades of technical debt.

I had a "post-final round" "quick chat" with a CEO at another company. His first question (literally), as he multitasked coordinating some wine deliveries for Christmas, was "Your engineers come to you wanting to do a rewrite, mentioning tech debt. How do you respond?" Huh, that's an eye-opening question. Especially since I'm being hired as a PM...

Setting up a separate insulated internal organization to pursue disruptive innovations is basically what Clayton Christensen recommended in "The Innovator's Dilemma" back in 1997. It's what IBM did to successfully develop the original PC.

https://www.hbs.edu/faculty/Pages/item.aspx?num=46

Every tech industry executive has read that book and most large companies have at least tried to put it into practice. For example, Google has "X" (the moonshot factory, not the social media platform formerly known as Twitter).

https://x.company/

but X isn't really an insulated org... it has close ties with other parts of Google. It shares the corporate infra and it's not hard to get inside and poke around. it has to be, because it's intended to create new products that get commercialized through Google or other Alphabet companies.

A better example would be Calico, which faced significant struggles getting access to internal Google resources, while also being very secretive and closed off (the term used was typically an "all-in bet" or an "all-out bet", or something in between. Verily just underwent a decoupling from Google because Alphabet wants to sell it.

I think if you really want to survive cycles of the innovator's dilemma, you make external orgs that still share lines of communications back to the mothership, maintaining partial ownership, and occasionally acquiring these external startups.

I work in Pharma and there's a common pattern of acquiring external companies and drugs to stay relevant. I've definitely seen multiple external acquisitions "transform" the company that acquires them, if for no other reason than the startup employees have a lot more gumption and solved problems the big org was struggling with.

There are varying degrees of insulation. I'm not convinced that Calico is a good example of Christensen's recommendations. It seems like a vanity research project sponsored by a Google founder rather than an internal startup intended to bring a disruptive innovation to market.

MSFT were the masters of this technique (spin off a startup, acquire it after it proves viable) for decades, but sadly they stopped.

Even internal to MS I worked on 2 teams that were 95% independent from the mothership, on one of them (Microsoft Band) we even went to IKEA and bought our own desks.

Pretty successful in regards to getting a product to market (Band 1 and 2 all up had iirc $50M in funding compared to Apple Watch's billion), but the big company politics still got us in the end.

Of course Xbox is the most famous example of MS pulling off an internal skunk works project leading to massive success.

> 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.

Oh wow. Want to kill morale and ensure if a few years anyone decent has moved on? Make a shiny new team of the future and put existing employees in "not the team of the future".

Any motivation I had to put in extra effort for things would evaporate. They want to keep the lights on? I'll do the same.

I've been on the other end of this, brought in to a company, for a team to replace an older technology stack, while the existing devs continued with what was labeled as legacy. There was a lot of bad vibe.

> 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.

Search is not a commodity. Search providers other than Google are only marginally used because Google is so dominant. At the same time, when LLMs companies can start providing a better solution to the actual job of finding answers to user queries, then Google's dominance is disrupted and their future business is no longer guaranteed. Maintaining Google search infra to serve as a search backbone is not big enough for Google.

Search, after Bert, is very much a commodity.

I get better results than Google on segments of common craw using a desktop computer and a research model.

Given that Google has decades of scrapes, and more than four gpus to work with, they can do a better job than me. That I beat them right now is nothing short of embarrassing, bordering on an existential threat.

> Search, after Bert, is very much a commodity. > I get better results than Google on segments of common craw using a desktop computer and a research model.

For data which hasn't changed since knowledge cutoff - for sure, but for real life web search, being able to get fresh data is a hard requirement.

That is not how encoder only models work.

I'm being nice about this and assuming Google (which also owns Youtube, and it shows, in their decisions about content) is just run by a bunch of naive people and isn't directly controlled by three letter agencies - they have to take a stronger stance against censorship/selective information

"Oh, but that doesn't happen" - it does, Goog results have been manipulated before to the extent that probably can't be attributed purely to SEO. Youtube removed tons of "covid misinformation" about things we all know now to be true

> 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.

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.

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

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.

Because due to that mindset now FB sucks and no one wants to use it anymore?

FB ad serve up 10% yoy but no is using it?

Correct, they don't know yet that their platform is dead, but it is. Most of those are bots.

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.

"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.

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.

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.

>>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.