Seit drei Jahren führe ich SAFe-Artefakte in einer großen öffentlichen Organisation ein. Ich bin zertifizierter SAFe SPC und schätze SAFe als den einzigen praxistauglichen Leitfaden auf dem Markt, der zumindest in Teilen eine konkrete Blaupause für die Transformation großer Organisationen liefert. Aber das heißt noch lange nicht, dass das Framework in meiner täglichen Praxis funktioniert – und vermutlich tut es das in Ihrer auch nicht. Kritik an SAFe gibt es genug. Hier ist mein eigener Blick darauf.
Die Welt ist nicht nur digital
Diese triviale Feststellung ist offensichtlich für Unternehmen, die physische Güter oder Dienstleistungen anbieten, welche die Mitarbeit von echten Menschen erfordern. Das „Produkt“, das hier geschaffen oder verbessert werden soll, kann zum Beispiel ein Beratungsprozess sein, der am Telefon oder am POS stattfindet, die Abläufe für das medizinische Personal im Krankenhaus oder der Verkaufsprozess im Baumarkt. Diese Prozesse sollen gestaltet, entwickelt und in Betrieb genommen, der Erfolg gemessen und der Prozess kontinuierlich verbessert werden.
SAFe bietet im Entwicklungsprozess aber nur den Mechanismus des Agile Release Train (ART) an, der für eine kontinuierliche Softwarebereitstellung konzipiert ist. Die verantwortlichen Rollen haben deshalb auch Bezeichnungen wie „Release Train Engineer“ (RTE), die in der Realität vieler Unternehmen einfach nicht passend sind. Wozu brauche ich einen RTE, wenn mein Produkt ein Gesprächsleitfaden für ein Kundengespräch ist?
Ebenfalls in diesem Kontext völlig unpassend ist das ausführliche und detailgenaue Mandat des „Program Increment“ (PI) Plannings des ART – nicht nur wegen seiner technischen Ausrichtung, sondern auch wegen der Prämisse fester Release-Zyklen. Teams, deren Aufgabe es ist, Problemlösungen für die physische Welt zu entwickeln, arbeiten faktisch in einem kontinuierlichen Fluss und sollten sich eher an einer Kanban-Logik orientieren. Eine Taktung in festen Zeitabschnitten kann für die übergeordnete Planung und Zielsetzung sinnvoll sein, um sie an den Finanzzyklen des Unternehmens auszurichten, wird ansonsten aber als künstlich aufgesetzt und störend empfunden.
Wertschöpfung in der physischen Welt findet immer noch genauso statt wie im Digitalen. Ein vollständiges Rahmenwerk muss Möglichkeiten schaffen, diese hybride Realität in eine Transformation einzubeziehen.
Entkopplung der Produktverantwortung
SAFe ist darauf ausgelegt, die Produktverantwortung auf der Agile-Release-Train- oder Solution-Train-Ebene anzusiedeln (beide sind ein fester Teil der vorgeschlagenen Managementstruktur). Das hat vermutlich den Hintergrund, dass SAFe am Beispiel eines Unternehmens entwickelt wurde, das wenige, aber sehr umfangreiche Softwareprodukte herstellt, bei denen viele Teams an einer einzigen, gemeinsamen Codebasis arbeiten. Wenn mehr als 100 Entwickler benötigt werden, um ein einziges, singuläres Produkt zu bauen, soll es sinnvoll sein, an übergeordneter Stelle eine verantwortliche Rolle zu installieren, die die zugeordneten Teams steuert. So die Hypothese.
Ich will nicht sagen, dass es keine Unternehmen gibt, für die dieser Ansatz funktioniert, aber ich bezweifle es für die meisten. In der Realität bestehen die meisten Produkte aus sinnvoll trennbaren Bestandteilen, für die es jeweils eine (teil-)produktverantwortliche Person geben kann, die eigenverantwortlich operiert. Oder aber das Unternehmen hat ohnehin eine Vielzahl eigenständiger Produkte mit fester Verantwortungszuteilung.
Natürlich müssen sich in jedem Unternehmen alle Akteure abstimmen, eine übergreifende Produktvision entwickeln und diese gemeinsam tragen. Aber graduelle Abstufungen in der Produktverantwortung sind in SAFe schlicht nicht vorgesehen. Auch Ansätze, wie eine solche gemeinsame Vision in einem Umfeld mit vielen dezentralen Verantwortungsträgern entstehen kann, fehlen. SAFe fehlt die Flexibilität, Teams dort Autonomie und Verantwortung zu übertragen, wo sie gebraucht werden.
Wird das System starr nach Lehrbuch angewendet, wertet dies die Teamebene ab und degradiert Product Owner zu reinen Backlog-Verwaltern und Ticket-Schreibern. In der Folge leidet die Produktivität, da die Potenziale der Teams ungenutzt bleiben und das System verliert massiv an Akzeptanz, gerade bei den kompetentesten und engagiertesten Product Ownern und Entwicklern.
Das „Alles-oder-nichts“-Reorganisations-Dilemma
Auch das folgende grundsätzliche Argument sollte eigentlich selbstverständlich sein. Die Entscheidung zur Reorganisation eines Unternehmens hat immer einen Hintergrund. Dieser kann beispielsweise eine organisatorische Sackgasse sein, eine plötzliche Veränderung der Marktsituation, mit der die Organisation konfrontiert ist, oder schlicht der Bedarf und Wille zu einer fortlaufenden Verbesserung, um es erst gar nicht so weit kommen zu lassen. Im ersten Fall kann ein radikaler Umbruch der Organisation notwendig sein, im letzteren wohl eher nicht. Die möglichen Strategien der Organisationsentwicklung reichen dementsprechend von einem „vorsichtigen Umbau“ bis hin zum „radikalen Schnitt“.
Und selbst wenn der Wille vorhanden ist, ist eine vollständige Reorganisation nicht immer machbar. In regulierten Umfeldern oder Unternehmen des öffentlichen Sektors ist die primäre Organisationsstruktur beispielsweise oft gesetzlich vorgegeben. Bestehende Abteilungen können nicht aufgelöst werden, ohne den rechtlichen Rahmen der Institution selbst zu ändern.
Unabhängig davon, welcher Organisationstheorie man anhängt: Sicher ist, dass nicht alle Unternehmen gleich sind und ein starres Konzept für alle keinen Sinn ergibt. SAFe fordert jedoch genau das – eine fundamentale Neuausrichtung der Struktur um den Wertstrom herum. Eine Übergangsarchitektur oder Alternativkonzepte, wie der Aufbau einer Sekundärorganisation bei Erhalt der primären Disziplinarstruktur, sucht man im Framework vergeblich. Damit sollte die buchstabengetreue Anwendung von SAFe für viele Unternehmen von vornherein ein No-Go sein.
Fehlende Nutzerzentrierung und Service Design
Die SAFe-Autoren Dean Leffingwell und Drew Jemilo haben ihren beruflichen Hintergrund im Ingenieurwesen und in der klassischen Softwareentwicklung. Es verwundert daher nicht, dass bestimmte Transformationsaspekte im Vordergrund stehen, während andere zu kurz kommen (um es vorsichtig auszudrücken). Am deutlichsten wird dies für mich beim Thema Design – zugegebenermaßen auch aufgrund meines eigenen beruflichen Hintergrunds.
Zwar werden „Customer Centricity“ und „Design Thinking“ in SAFe als Konzepte erwähnt, bleiben aber bei genauerem Hinsehen unvollständig, missverständlich oder schlicht falsch interpretiert. In SAFe 5 wurde Design Thinking im Kern noch als reine Methode verstanden, um „das Risiko zu minimieren, das Falsche in perfekter Geschwindigkeit zu bauen“, was dem üblichen Verständnis von Design Thinking objektiv einfach nicht gerecht wird. In Version 6 wurde dies zwar oberflächlich korrigiert, indem im Bereich „Agile Product Delivery“ die Werkzeuge Personas, Empathy Maps, Customer Journey Maps und Story Mapping integriert wurden. Doch auch das greift zu kurz und wäre im Kern ohnehin besser mit dem Begriff Service Design beschrieben (wobei die genannten Methoden nur einen kleinen Teil des Service Design abdecken).
Was in SAFe fehlt, ist eine systematische Integration kreativer Arbeit und moderner Anforderungsanalyse auf allen Ebenen des organisatorischen Gefüges, um etwa die erwähnte gemeinsame Produktvision kollaborativ zu entwickeln. Es gibt dann auch weder Ansätze für eine echte siloübergreifende, multidisziplinäre Zusammenarbeit noch einen konkreten Blueprint zur systematischen Einbindung von Endanwendern in den Entwicklungsprozess, wie er auch in der ISO 9241 – 210 definiert ist. Die vorgeschlagenen Methoden wirken etwas hilflos an das bestehende System angedockt, beispielsweise als bloße „Vorbereitung für die PI-Planning-Events“. Das Wort Nutzerzentrierung ist in SAFe am Ende nicht viel mehr als ein Feigenblatt.
Wertdefinition jenseits von operativem Output
Folgerichtig zu dem erwähnten Schwerpunkt auf der technischen Umsetzung hat SAFe auch einen blinden Fleck bei der Definition dessen, was im eigenen Framework (richtigerweise) den Kern der Organisation ausmacht: der Wertschöpfung bzw. dem Wertstrom. Jede Organisation mag ihre eigene Vorstellung davon haben, was einen „Wert“ darstellt, der erzeugt werden soll. Die Sichtweise wird von Unternehmen zu Unternehmen naturgemäß weit auseinandergehen. SAFe bietet hier jedoch nur eine sehr operative Definition an.
In SAFe leitet sich der Begriff „Wert“ (Value) maßgeblich von einem operativen Durchsatz im Stile der klassischen Fertigung ab – vergleichbar mit dem Schneiden, Stanzen, Polieren und Versenden physischer Güter. Das Framework unterscheidet dabei zwischen dem operativen Wertstrom (dem tatsächlichen Erbringen von Dienstleistungen oder Produzieren von Produkten) und dem Entwicklungswertstrom (dem Verbessern der operativen Wertströme). Der Gedanke dahinter scheint zu sein: Wenn die Produktion effizient organisiert ist, entsteht der „Wert“ von allein. Aber welcher Wert entsteht da eigentlich? Ist Wert immer in Geld umzusetzen?
Das Framework bietet keine Modelle, um nicht-monetäre, übergeordnete Effekte wie langfristige Kundenzufriedenheit, gesellschaftlichen Nutzen (Public Value) oder Verbesserungen der Lebensqualität für Menschen in den täglichen Betrieb zu übersetzen. Wie organisiert man ein Unternehmen, das sich zum Ziel setzt, Menschen glücklich machen zu wollen? Oder etwas naheliegender, wie kann ein wichtiger Wert wie “Vertrauen in staatliche Organisationen schaffen” als Wert für ein öffentliches Unternehmen verankert werden?
Wenn eine Organisation sich „um den Wert herum“ strukturieren soll („organize around value“), dann muss das Rahmenwerk auch Werkzeuge anbieten, um diese strategischen, nicht-monetären Werte sauber zu definieren und operativ zu verankern.
Das agile Paradoxon
SAFe ist extrem umfangreich und komplex. Es führt eine Reihe spezialisierter, künstlicher Rollen ein, sieht jedoch keinerlei Anpassungen am eigenen Rahmenwerk vor und dementsprechend auch keine organisatorischen Formate, um solche Anpassungen überhaupt zu planen und durchzuführen. SAFe ist schwer zu erklären, erzeugt eine erhebliche kognitive Belastung und führt auch deshalb zu Widerständen bei genau denjenigen, die es bei der Arbeit eigentlich unterstützen sollte.
Warum die Autoren, die ja nach eigener Aussage Experten für „agiles Arbeiten“ sind, einen derart starren Ansatz gewählt haben, bleibt ein Rätsel. Vielleicht sind Leffingwell und Jemilo am Ende dann doch eher old school Manager als Entwickler. Oder aber – meine persönliche Verschwörungstheorie: Das starre System ist schlicht eine Folge des Geschäftsmodells von Scaled Agile, Inc. mit seinen standardisierten, globalen und zertifizierbaren Schulungspfaden. Es ist zweifellos einfacher, teure Kurse zu verkaufen, wenn das geschriebene Buch die einzige Quelle der Wahrheit ist. Die beste Lösung für Ihr Unternehmen ist es sehr wahrscheinlich nicht.
Wo sind die Alternativen?
Organisationale Agilität erfordert das Gegenteil von SAFe: ein minimalistisches Framework, das Unternehmen die Werkzeuge an die Hand gibt, sich kontinuierlich anzupassen und sich von innen heraus neu zu erfinden. Oder sich aber dann bei Bedarf doch radikal zu ändern. LeSS, Scrum@Scale, Spotify? Ich sehe derzeit nichts, was als Leitfaden für ein großes Unternehmen mit sowohl digitalen als auch nicht-digitalen Abläufen dienen kann. Vielleicht ist es an der Zeit, einen solchen zu entwickeln.
Patrick Boyle on the repercussions of the U.S. government’s shutdown of Anthropic’ flagship AI models on June 12:
For years, the theory was that building artificial intelligence required Silicon Valley genius, billions in venture capital, and an exclusive relationship with a cloud computing giant […] It turns out that there is no monopoly on math. The open-source models are good enough. They’re 60 times cheaper, and nobody in Washington can switch them off on a Friday afternoon. The productivity gains everyone was promised will still happen; they’ll just flow to the businesses running the code on their own machines rather than to the investors who paid almost a trillion dollars for a global monopoly on math.
For three years, I have been introducing SAFe artifacts in a large, public organization. I am a certified SAFe SPC and appreciate SAFe as the only practical guidebook on the market that provides, at least in part, a concrete blueprint for the transformation of large organizations. But that does not mean that the framework works in my daily practice – and presumably it does not in yours either. There is a lot of criticism of SAFe. Here is my view on it.
The World Is Not Only Digital
This trivial observation is obvious for companies producing physical goods or services that require the involvement of real people. The „product” to be created or improved here can be, for example, a consulting process that takes place on the phone or at the POS, the procedures for medical personnel in a hospital, or the sales process in a hardware store. These processes are to be designed, developed, and put into operation, the success measured, and the process continuously improved.
In the development process, however, SAFe only offers the mechanism of the Agile Release Train (ART), which is designed for continuous software delivery. The responsible roles therefore also have designations like „Release Train Engineer” (RTE), which are simply not appropriate in the reality of many companies. Why do I need an RTE if my product is a conversation guide for a customer interview?
Also completely inappropriate in this context is the detailed and precise mandate of the „Program Increment” (PI) planning of the ART – not only because of its technical orientation, but also because of the premise of fixed release cycles. Teams whose task is to develop problem solutions for the physical world factually work in a continuous flow and should rather orient themselves toward a Kanban logic. A cadence in fixed time intervals can be useful for high-level planning and goal setting to align them with the financial cycles of the company, but is otherwise perceived as artificially imposed and disruptive.
Value creation in the physical world still takes place just as it does in the digital. A complete framework must create opportunities to include this hybrid reality into a transformation.
Decoupling of Product Responsibility
SAFe is designed to locate product responsibility at the Agile Release Train or Solution Train level (both are a fixed part of the proposed management structure). This presumably has the background that SAFe was developed using the example of a company that produces few but very extensive software products, where many teams work on a single, shared codebase. If more than 100 developers are required to build a single, singular product, it is supposed to be useful to install a responsible role at a higher level to manage the assigned teams. So goes the hypothesis.
I do not want to say that there are no companies for which this approach works, but I doubt it for most. In reality, most products consist of meaningfully separable components for which there can be a (partially) product-responsible person who operates independently. Or the company already has a variety of independent products with fixed responsibility allocation.
Of course, in every company, all actors must coordinate, develop an overarching product vision, and bear it together. But gradual nuances in product responsibility are simply not provided for in SAFe. Approaches on how such a shared vision can emerge in an environment with many decentralized decision-makers are also missing. SAFe lacks the flexibility to transfer autonomy and responsibility to teams where they are needed.
If the system is applied rigidly according to the textbook, this devalues the team level and degrades Product Owners to mere backlog administrators and ticket writers. As a result, productivity suffers because the potentials of the teams remain unused, and the system massively loses acceptance, especially among the most competent and committed Product Owners and developers.
The „All-or-Nothing” Reorganization Dilemma
The following fundamental argument should also actually be self-evident. The decision to reorganize a company always has a background. This can be, for example, an organizational dead end, a sudden change in the market situation faced by the organization, or simply the need and desire for continuous improvement to prevent things from getting that far in the first place. In the first case, a radical upheaval of the organization may be necessary; in the latter, probably not. The possible strategies of organizational development accordingly range from a „cautious restructuring” to a „radical cut”.
And even if the will is present, a complete reorganization is not always feasible. In regulated environments or public sector enterprises, for example, the primary organizational structure is often legally prescribed. Existing departments cannot be dissolved without changing the legal framework of the institution itself.
Regardless of which organizational theory one adheres to: What is certain is that not all companies are the same and a rigid concept makes no sense for everyone. SAFe, however, demands exactly that – a fundamental realignment of the structure around the value stream. One looks in vain in the framework for a transition architecture or alternative concepts, such as the creation of a secondary organization while maintaining the primary disciplinary structure. Therefore, the literal application of SAFe should be a no-go for many companies from the beginning.
Missing User-Centricity and Service Design
The SAFe authors Dean Leffingwell and Drew Jemilo have their professional background in engineering and classical software development. It is therefore not surprising that certain transformation aspects are in the foreground while others fall short (to put it mildly). This becomes clearest to me when it comes to design – admittedly also due to my own professional background.
Although „Customer Centricity” and „Design Thinking” are mentioned as concepts in SAFe, upon closer inspection they remain incomplete, misunderstood, or simply misinterpreted. In SAFe 5, Design Thinking was fundamentally still understood as a pure method to „minimize the risk of building the wrong thing at perfect speed,” which objectively simply does not do justice to the usual understanding of Design Thinking. In version 6, this was corrected superficially by integrating the tools personas, empathy maps, customer journey maps, and story mapping into the „Agile Product Delivery” area. But even that falls short and would fundamentally be better described by the term Service Design anyway (whereby the mentioned methods only cover a small part of Service Design).
What is missing in SAFe is a systematic integration of creative work and modern requirements analysis at all levels of the organizational fabric, for instance to collaboratively develop the mentioned shared product vision. There are also neither approaches for true cross-silo, multidisciplinary collaboration nor a concrete blueprint for the systematic involvement of end users in the development process, as is also defined in ISO 9241 – 210. The proposed methods seem somewhat helplessly attached to the existing system, for example as a mere „preparation for the PI planning events.” The word user-centricity is in the end not much more than a fig leaf in SAFe.
Value Definition Beyond Operational Output
Consequently, corresponding to the mentioned focus on technical implementation, SAFe also has a blind spot in the definition of what (rightly) constitutes the core of the organization in its own framework: value creation or the value stream. Every organization may have its own idea of what constitutes a „value” to be generated. The perspective will naturally diverge widely from company to company. SAFe, however, offers only a very operational definition here.
In SAFe, the term „value” is significantly derived from an operational throughput in the style of classical manufacturing – comparable to cutting, stamping, polishing, and shipping physical goods. The framework distinguishes between the operational value stream (the actual provision of services or production of products) and the development value stream (the improvement of operational value streams). The thought behind it seems to be: If production is efficiently organized, the „value” arises on its own. But what value actually arises there? Is value always to be converted into money?
The framework offers no models to translate non-monetary, high-level effects such as long-term customer satisfaction, public value, or improvements in the quality of life for people into daily operations. How do you organize a company that sets itself the goal of wanting to make people happy? Or somewhat more obvious, how can an important value like „creating trust in state organizations” be anchored as a value for a public enterprise?
If an organization is to structure itself „around value” („organize around value”), then the framework must also offer tools to cleanly define and operationally anchor these strategic, non-monetary values.
The Agile Paradox
SAFe is extremely extensive and complex. It introduces a number of specialized, artificial roles, but provides no adaptations to its own framework and, accordingly, no organizational formats to plan and execute such adaptations in the first place. SAFe is difficult to explain, creates a significant cognitive load, and therefore also leads to resistance among exactly those whom it is actually supposed to support in their work.
Why the authors, who by their own account are experts in „agile”, chose such a rigid approach remains a mystery. Perhaps Leffingwell and Jemilo are, in the end, rather old school managers than developers. Or else – my personal conspiracy theory: the rigid system is simply a consequence of the business model of Scaled Agile, Inc. with its standardized, global, and certifiable training tracks. It is undoubtedly easier to sell expensive courses when the written book is the only source of truth. Good for them, but very likely not the best solution for your company.
Where Are the Alternatives?
Organizational agility requires the opposite of SAFe: a minimalist framework that gives companies the tools to continuously adapt and reinvent themselves from within. Or, if necessary, to change radically after all. LeSS, Scrum@Scale, Spotify? I currently see nothing that can serve as a guidebook for a large enterprise with both digital and non-digital operations. Perhaps it is time to develop one.
It is hard to grasp how absurd and evil the SpaceX IPO is when you pick out the facts from Patrick Boyle’s hilarious analysis.
[…] According to the [IPO prospectus], 93% of [SpaceX’s] total addressable market is attributed to AI. And based on the capital expenditure breakdown, roughly 60% of all spending is now going into artificial intelligence infrastructure.
[…] When Musk says that this is an AI company, what he means is that the one business that actually works [Starlink] is subsidizing a money-losing AI venture while he tries to convince public market investors that the money-losing AI venture is the entire reason the company’s worth $1.75 trillion.
[…] In 2025, the company generated $18.7 billion in revenue. […] at a proposed valuation of $1.75 trillion, SpaceX is asking investors to value it at almost 100 times its revenue.[…] If SpaceX were dropped into the S&P 500 today, it would be the seventh largest company in the index by market cap. But if you ranked it by actual revenue, it wouldn’t even meet 200th. It would be down near Kelloggs […] Unlike Kelloggs, SpaceX is not profitable.
[…] Capital expenditure reached $20.7 billion last year, quintupling from 2023, driven by Starlink expansion, Starship development, and AI infrastructure spending. To fund all of this, the company is carrying $29 billion in debt, including a $20 billion bridge loan taken out in March 2026 — eight weeks ago. So when investors hand over $75 billion in this IPO, a meaningful portion of it […] goes straight back to the banks who lent SpaceX money eight weeks ago.
[…] SpaceX claims its total addressable market is $28.5 trillion. This is larger than the entire GDP of the United States and almost entirely built on businesses that do not yet exist. According to the prospectus, enterprise applications of AI make up to 80% of SpaceX’s total addressable market. […] The filing effectively concedes that the enterprise AI market is dominated by OpenAI, Anthropic, and Google. SpaceX’s own AI product, Grok, holds a market share of roughly 3.4%.
[…] SpaceX’s near-term AI revenue story rests substantially on a $15 billion a year deal to rent compute capacity to Anthropic, one of the very competitors whose existence proves that Grok is losing the AI race. […] The more pressing problem is that this $15 billion a year contract — roughly 40% of projected near-term revenues — can be cancelled by Anthropic with 90 days’ notice. SpaceX’s entire AI business model at the moment is renting GPUs to a competitor on terms that can vanish in a fiscal quarter. […]
Now the related-party concerns:
Antonio Gracias is a long-term Musk ally and a sitting member of the SpaceX board of directors. He also runs a private investment firm called Valor Equity Partners. According to the IPO prospectus, SpaceX and XAI are carrying more than $20 billion in AI infrastructure lease obligations tied to agreements with entities connected to Valor. Some of these deals are structured as what accountants call „failed sale-leasebacks.” […] The practical effect is that SpaceX is carrying billions in obligations to a firm run by one of its own board members on its balance sheet as debt.
[…] Back in 2016, Elon Musk used Tesla’s shareholder money to acquire SolarCity, a struggling solar company that he also chaired and partly owned.[…] The court reviewed the entire transaction […] describing the process as deeply flawed […] [Musk] has now completed a structurally similar acquisition, this time of XAI, in a state with far more lax securities rules. […] The lesson that Musk appears to have drawn from SolarCity is not „don’t do conflicted acquisitions”; it’s „do them somewhere with friendlier courts.”
Who is profiting?
The clearest beneficiaries of this acquisition are not the SpaceX engineers trying to get to Mars. They’re the venture capitalists and banks, including Morgan Stanley, who were at first stuck holding billions in underwater debt from Musk’s chaotic buyout of Twitter. Thanks to the XAI-SpaceX merger, those lenders have been made whole in SpaceX equity, conveniently timed just before the largest IPO in history.[…] 23 banks have crammed their names onto the cover of this prospectus. The fees constitute the most lucrative Wall Street IPO payday ever.
and more:
All of this brings us to the corporate governance structure of SpaceX […] While Musk only owns around 41% of SpaceX, he will control more than 85% of the votes, meaning that he can’t ever be fired by shareholders. The company has also placed limits on how shareholders can file legal challenges. As SpaceX writes in the prospectus, „this will limit or preclude your ability to influence corporate matters and the election of our directors.”
[…] On top of that, because Elon Musk convinced NASDAQ to change their index inclusion methodology in order to win this listing, SpaceX will be fast-tracked for inclusion in the NASDAQ 100 index. […] countless pension funds and passive investors will become forced buyers of the stock almost immediately, long before there’s any serious price discovery, and they’ll own shares in a heavily cash-burning company where they have no voting power and no meaningful ability to sue management.
[…] Musk is getting 1 billion performance-based restricted shares and how these shares only vest when SpaceX establishes a permanent human colony on Mars and hits a $7.5 trillion market cap. […] But there’s a trick. As law professor Ann Lipton points out, Musk doesn’t actually need to achieve any of those hard-to-reach goals. […] He gets all the benefits of owning the shares immediately based on a Mars colony that the company admits he will probably never build.
[…] nothing stops Elon Musk from setting up a separate private company tomorrow to pursue whatever the next big tech trend is rather than doing it inside SpaceX […] As Ann Lipton summarized it: public shareholders in SpaceX will have no votes that matter, no ability to sell at a fair price discovered through normal market mechanisms, and no ability to sue the company for wrongdoing. No votes, no sales, no suits.
This is a transcript from an interview of David Sirota with Ed Zitron on Youtube, published on Dec 15, 2025.
Nvidia claimed […] that they shipped 6 million Blackwell GPUs. Now, I’ve confirmed with sources that this was specifically AI GPUs, 6 million of these. So, doing a little napkin maths, that’s about 10 to 12 GW of required power IT load. So, when you turn them on… but we’ve not built anywhere near that many data centers in the last year […] there are likely millions of GPUs sitting in warehouses waiting to be turned on. […] Satya Nadella of Microsoft said in an interview a couple of weeks ago that he has chips sitting in inventory that do not have power to turn on.
I think this is one of the most insane things that’s ever happened in history, ’cause I think that Nvidia is pushing billions of dollars of GPUs on companies that cannot install them.
When Will The AI Bubble Pop? Full Interview With Ed Zitron (10:38 onwards)
I am now collecting quotes about the AI craze, just for my records.
LLMs are dangerous for many, many reasons, but the under-discussed one is how well they play to a certain kind of executive imbecile. Generative AI is — to quote Mo Bitar — really good at doing an impression of work, much like most managers and c‑suite executives, and even if it’s completely incapable of doing something, it’ll absolutely say it can and tell you you’re amazing for suggesting it. And that’s why Business Idiots love it.
26 May 2026, Ed Zitron: Revenge of the Business Idiot
A while ago I subscribed the Oversharing newsletter („more than you wanted to know about the sharing economy”) from qz writer Alison Griswold. Even if you already know that Uber is greedy and Silicon Valley has its flaws – it is actually even worse.
My favorites from the newsletter archive:
Uber alums are calling the shots in Silicon Valley
Shared scooters don’t last long
From Vision in Motion, László Moholy-Nagy, Chicago 1947:
Design has many connotations. It is the organization of materials and processes in the most productive, economic way, in a harmonious balance of all elements necessary for a certain function. It is not a matter of façade, of mere external appearance; rather it is the essence of products and institutions, penetrating and comprehensive. Designing is a complex and intricate task. It is integration of technological, social and economic requirements, biological necessities, and the psychophysical effects of materials, shape, color, volume, and space: thinking in relationships. The designer must see the periphery as well as the core, the immediate and the ultimate, at least in the biological sense. He must anchor his special job in the complex whole. The designer must be trained not only in the use of materials and various skills, but also in appreciation of organic functions and planning. He must know that design is indivisible, that the internal and external characteristics of a dish, a chair, a table, a machine, painting, sculpture are not to be separated. The idea of design and the profession of the designer has to be transformed from the notion of a specialist function into a generally valid attitude of resourcefulness and inventiveness which allows projects to be seen not in isolation but in relationship with the need of the individual and the community. One cannot simply lift out any subject matter from the complexity of life and try to handle it as an independent unit.
There is design in organization of emotional experiences, in family life, in labor relations, in city planning, in working together as civilized human beings. Ultimately all problems of design merge into one great problem: ‘design for life’. In a healthy society this design for life will encourage every profession and vocation to play its part since the degree of relatedness in all their work gives to any civilization its quality. This implies that it is desirable that everyone should solve his special task with the wide scope of a true “designer” with the new urge to integrated relationships. It further implies that there is no hierarchy of the arts, painting photography, music, poetry, sculpture, architecture, nor of any other fields such as industrial design. They are equally valid departures toward the fusion of function and content in ‘design.’