Bücher — was ich lese und was ich darüber denke.
Ich bin allergisch gegen Gründer-Heldengeschichten. Genau deshalb habe ich „The Algorithm" gelesen: Der Untertitel verspricht eine Formel — und ich wollte wissen, ob unter der Tesla-Mythologie eine übertragbare Methode steckt oder nur das übliche „Sei einfach genial wie Elon". Die Antwort: Beides. Aber der nützliche Teil ist erstaunlich nüchtern.
Worum es geht
Jon McNeill war President von Tesla — laut Buch der erste von Musks direkten Berichtern, der überhaupt ein Buch schreibt. Sheryl Sandberg vermittelte ihn an Musk; McNeill hatte da bereits sechs Firmen gegründet und verkauft. Seine Kernzahl: Während seiner Zeit wuchs Teslas Umsatz von 2 auf 20 Milliarden Dollar in 30 Monaten — aus einer Produktionskrise heraus, die das Unternehmen fast umgebracht hätte.
Das Buch destilliert daraus „den Algorithmus" — Musks berühmte fünf Schritte — plus die Kultur, die nötig ist, damit sie greifen. Mit Fallbeispielen von Tesla, SpaceX, GM und Lululemon.
Was hängengeblieben ist
- Der Algorithmus selbst — und seine Reihenfolge. Fünf Schritte: Jede Anforderung hinterfragen → jeden möglichen Schritt löschen → vereinfachen und optimieren → die Zykluszeit beschleunigen → automatisieren. Die Pointe ist die Reihenfolge: Automatisieren kommt zuletzt. Wer einen aufgeblähten Prozess automatisiert, zementiert die Verschwendung in Software — nur schneller und teurer.
- „Jede Anforderung hat einen Namen." Anforderungen sollen von einer Person kommen, nicht von „der Abteilung" oder „der Compliance" — sonst kann sie niemand hinterfragen. Anforderungen sind Schulden, keine Sicherheit.
- Firmen werden nicht langsam, weil Leute faul sind. Sie werden langsam wegen unsichtbarer Regeln — Prozesse, die mal Sinn hatten und die seit Jahren niemand mehr in Frage stellt. Das ist die ehrlichste Diagnose im Buch.
- Geschwindigkeit ist eine Kultur, kein Tool. Kurze Zykluszeit schlägt Perfektion: lieber schnell etwas Unfertiges testen als langsam etwas vermeintlich Perfektes liefern.
Mein Blick als Mittelständler
Hier wird es interessant — und hier muss man filtern. Streicht man aus dem Buch das Musk-Pathos, die „setz dir unrealistische Ziele"-Romantik und vor allem die Voraussetzungen, die eine normale Firma nicht hat (Milliarden an Kapital, Risikoappetit, und der Survivorship Bias — Tesla hat überlebt, von den Hunderten, die mit denselben „verrückten Zielen" gestorben sind, schreibt niemand ein Buch), dann bleibt etwas übrig, das skalierungsunabhängig ist: Der Algorithmus ist im Kern einfach disziplinierter Prozessbau.
Und genau deshalb hat mich das Buch weniger überrascht als bestätigt. „Jede Anforderung hinterfragen" ist exakt das, was ich an anderer Stelle als Hauptursache gescheiterter Softwareprojekte beschrieben habe — siehe warum Softwareprojekte scheitern. Und „erst löschen und vereinfachen, dann automatisieren" ist dieselbe Reihenfolge, für die ich bei KI plädiere — siehe Werkzeug, kein Wunder. McNeill hat mir vor allem ein knappes Vokabular für Dinge gegeben, die ich ohnehin für richtig halte.
Was ich übernehme, was ich ablehne
Übernehmen würde ich die fünf Schritte als schlichte Checkliste — besonders „delete before automate" und „jede Anforderung braucht einen Namen". Das funktioniert in einem 8-Personen-Team genauso wie in einer Fabrik.
Ablehnen würde ich das implizite „sei wie Musk": die Verklärung von Brutalität und 100-Stunden-Wochen als Erfolgsrezept, und die unkritische Übertragung von Hypergrowth-Logik auf Firmen, die gar nicht hyperwachsen wollen — und auch nicht sollten. Die meisten Mittelständler brauchen kein „exponentielles Wachstum", sondern weniger Reibung. Der Algorithmus liefert das Zweite; das Erste ist Marketing.
Für wen
Lesen, wenn du Prozesse verantwortest und eine Sprache dafür suchst, warum ihr langsam geworden seid. Nicht lesen als Tesla-Bewunderungs-Buch — dafür ist die Methode darin zu gut, um sie unter Heldenpathos zu begraben.
Der eigentliche Wert des Buches ist nicht „werde wie Tesla". Er ist: Bevor du etwas automatisierst, lösche es erst — die meiste Verschwendung verschwindet, wenn man die Anforderung hinterfragt, die sie verursacht.
