21 Lektionen aus 14 Jahren bei Google

• Hervorragende Ingenieurinnen und Ingenieure sind nicht die besten Programmierer, sondern diejenigen, die gelernt haben, sich im Umfeld von Code zurechtzufinden – bei Menschen, Politik, Abstimmung und Mehrdeutigkeit
• Der Fokus liegt weniger auf Technologie als auf Mustern, die in Projekten und Teams immer wieder auftreten, und umfasst das Lösen von Nutzerproblemen, Teamarbeit, Code-Qualität und Karrieremanagement
• Es zeigt die paradoxe Einsicht, dass Klarheit eine zentrale Eigenschaft von Senior Engineers ist und Cleverness oft nur Overhead bedeutet – und dass der beste Code der ist, der gar nicht geschrieben wurde
• In großen Organisationen ist fehlende Abstimmung eine der Hauptursachen für geringe Geschwindigkeit, und sobald Metriken zum Ziel werden, werden sie verzerrt – eine typische Falle im Organisationsbetrieb
• Aus langfristiger Perspektive wird Zeit zu einer wertvolleren Ressource als Geld, und weil Netzwerke länger bestehen als einzelne Jobs, braucht es eine bewusste Karrieregestaltung

---

1. Die besten Engineers sind besessen davon, Nutzerprobleme zu lösen

• Es ist verlockend, sich zuerst in eine Technologie zu verlieben und dann nach einer Anwendung dafür zu suchen, aber die Engineers mit dem größten Hebel arbeiten andersherum – sie verstehen das Problem der Nutzer tief und leiten daraus die Lösung ab
• Nutzerfokus bedeutet, Zeit in Support-Tickets zu investieren, mit Nutzern zu sprechen, ihre Schwierigkeiten zu beobachten und so lange „Warum?“ zu fragen, bis man an die Wurzel gelangt
• Engineers, die ein Problem wirklich verstehen, stellen oft fest, dass elegante Lösungen einfacher sind als erwartet
• Engineers, die mit der Lösung beginnen, neigen dazu, Komplexität aufzubauen, um sie nachträglich zu rechtfertigen

2. Recht zu haben ist leicht – gemeinsam zum Richtigen zu kommen, ist die eigentliche Arbeit

• Man kann jede technische Debatte gewinnen und trotzdem das Projekt verlieren; immer wieder sieht man brillante Engineers, die stillen Groll ansammeln, weil sie ständig die klügste Person im Raum sein wollen
• Die Kosten zeigen sich später als „mysteriöse Umsetzungsprobleme“ und „seltsamer Widerstand“
• Die entscheidende Fähigkeit ist nicht, recht zu haben, sondern sich an Diskussionen zur Problemabstimmung zu beteiligen, anderen Raum zu geben und den eigenen Überzeugungen mit Skepsis zu begegnen
• Starke Meinungen, geringe Bindung daran – nicht wegen mangelnder Überzeugung, sondern weil man Entscheidungen unter Unsicherheit nicht an die eigene Identität koppeln sollte

3. Veröffentliche mit einem Bias zum Handeln. Eine schlechte Seite kann man bearbeiten, eine leere nicht

• Der Drang zur Perfektion führt zu Lähmung; immer wieder diskutieren Engineers wochenlang über die ideale Architektur für etwas, das noch nie gebaut wurde
• Die perfekte Lösung entsteht nicht durch Nachdenken allein, sondern durch Kontakt mit der Realität, wobei AI auf viele Arten helfen kann
• Erst machen, dann richtig machen, dann besser machen – einen hässlichen Prototyp vor Nutzer stellen, einen unordentlichen Entwurf eines Design-Dokuments schreiben und ein leicht peinliches MVP ausliefern
• Aus einer Woche echtem Feedback lernt man mehr als aus einem Monat theoretischer Debatten; Momentum schafft Klarheit, Analyse-Paralyse schafft nichts

4. Klarheit ist das Kennzeichen von Seniorität, Cleverness ist Overhead

• Der Impuls, cleveren Code zu schreiben, ist unter Engineers fast universell und fühlt sich wie ein Beweis der eigenen Kompetenz an
• Software Engineering beginnt sobald Zeit und andere Programmierer hinzukommen; in diesem Umfeld ist Klarheit keine Stilfrage, sondern eine Verringerung operativer Risiken
• Code ist eine strategische Notiz für Fremde, die ihn nachts um 2 Uhr während eines Ausfalls warten müssen; optimiert werden sollte nicht Eleganz, sondern ihr Verständnis
• Die am meisten respektierten Senior Engineers lernen, Cleverness jedes Mal gegen Klarheit einzutauschen

5. Neuartigkeit ist eine Schuld, die man mit Ausfällen, Recruiting und kognitivem Overhead zurückzahlt

• Technologieentscheidungen sollte man so behandeln, als hätte die Organisation nur ein kleines Budget an „Innovations-Token“; jedes Mal, wenn man etwas wirklich Nicht-Standardmäßiges einführt, verbraucht man einen davon – viel kann man sich davon nicht leisten
• Die Aussage ist nicht „Niemals innovieren“, sondern „Nur dort innovieren, wo man dafür bezahlt wird, einzigartig zu innovieren“; sonst sollte Langeweile der Standard sein
• Denn Langeweile hat bekannte Failure Modes
• Das „beste Werkzeug für den Job“ bedeutet oft eher „das am wenigsten schlechte Werkzeug für viele Jobs“, weil ein Zoo an Tools echte Betriebskosten verursacht

6. Code setzt sich nicht für dich ein – Menschen tun das

• Zu Beginn der Karriere glaubt man, gute Arbeit werde für sich selbst sprechen, doch das ist ein Irrtum; Code sitzt einfach still im Repository
• Ob dein Manager dich in Meetings erwähnt oder nicht, ob Kolleginnen und Kollegen dich für ein Projekt empfehlen oder jemand anderen – das macht den Unterschied
• In großen Organisationen werden Entscheidungen in Meetings getroffen, zu denen du nicht eingeladen bist, auf Basis von Zusammenfassungen, die du nicht selbst geschrieben hast, von Menschen mit fünf Minuten Zeit und zwölf Prioritäten
• Wenn in Räumen, in denen du nicht bist, niemand deinen Einfluss benennen kann, dann ist dieser Einfluss faktisch optional; das ist keine Selbstvermarktung, sondern heißt, die Wertschöpfungskette für alle – einschließlich dir selbst – lesbar zu machen

7. Der beste Code ist Code, der nie geschrieben werden musste

• Engineering-Kulturen feiern das Erschaffen, aber Löschen verbessert Systeme oft stärker als Hinzufügen, auch wenn niemand wegen gelöschtem Code befördert wird
• Jede Zeile Code, die man nicht schreibt, ist eine Zeile, die man nicht debuggen, warten oder erklären muss
• Vor dem Bauen sollte man die Fragen ausschöpfen: „Was wäre, wenn wir es einfach … nicht tun?“ – manchmal lautet die Antwort „Nichts Schlimmes“, und genau das ist die Lösung
• Das Problem ist nicht, dass Engineers keinen Code schreiben können oder ihn nicht mit AI schreiben können, sondern dass sie so gut darin sind, dass sie vergessen zu fragen, ob er überhaupt geschrieben werden muss

8. In großem Maßstab haben sogar Bugs ihre Nutzer

• Hat man genug Nutzer, wird jedes beobachtbare Verhalten zu einer Abhängigkeit, unabhängig davon, ob es je versprochen wurde – irgendwer scrapet die API, automatisiert Eigenheiten oder cached Bugs
• Daraus folgt eine Einsicht auf Karriere-Niveau: Kompatibilitätsarbeit kann nicht als „Wartung“ behandelt werden und neue Features als „eigentliche Arbeit“, denn Kompatibilität ist das Produkt
• Abkündigungen sollten mit Zeit, Werkzeugen und Empathie als Migration gestaltet werden
• Das meiste „API-Design“ bedeutet in Wirklichkeit „API-Ruhestand“

9. Die meisten „langsamen“ Teams sind in Wirklichkeit schlecht abgestimmt

• Wenn sich Projekte verzögern, ist der erste Reflex, die Ausführung zu beschuldigen – die Leute arbeiten nicht hart genug, die Technologie ist falsch, es gibt nicht genug Engineers –, aber meist ist das nicht das eigentliche Problem
• In großen Unternehmen sind Teams die Einheit der Parallelisierung, aber je mehr Teams es gibt, desto stärker wachsen die Koordinationskosten exponentiell
• Langsamkeit bedeutet meist versagte Abstimmung – man baut das Falsche oder baut das Richtige auf inkompatible Weise
• Senior Engineers verbringen mehr Zeit damit, Richtung, Schnittstellen und Prioritäten zu klären, als damit, „schneller Code zu schreiben“ – weil dort der echte Engpass liegt

10. Konzentriere dich auf das, was du kontrollieren kannst, und ignoriere den Rest

• In großen Unternehmen liegen viele Variablen außerhalb der eigenen Kontrolle – Reorganisationen, Managemententscheidungen, Marktveränderungen, Produktwechsel – und wenn man sich daran festbeißt, erzeugt das Angst ohne Handlungsmacht
• Wer bei Verstand bleibt und effektiv arbeitet, konzentriert sich auf den eigenen Einflussbereich – ob es eine Reorganisation gibt, kann man nicht steuern, aber die Qualität der eigenen Arbeit, die eigene Reaktion und das, was man lernt, schon
• Bei Unsicherheit sollte man das Problem in Teile zerlegen und konkrete Handlungen identifizieren, die einem möglich sind
• Das ist keine passive Akzeptanz, sondern strategischer Fokus; Energie, die man auf Unveränderliches verwendet, fehlt bei dem, was man verändern kann

11. Abstraktion entfernt Komplexität nicht – sie verschiebt sie auf den Moment, in dem du On-Call bist

• Jede Abstraktion ist eine Wette darauf, dass man nicht verstehen muss, was darunterliegt, und manchmal geht diese Wette auf
• Aber irgendetwas leckt immer, und wenn es leckt, muss man wissen, worauf man eigentlich steht
• Senior Engineers lernen mit wachsendem Stack weiterhin die „Lower-Level“-Dinge – nicht aus Nostalgie, sondern aus Respekt vor den Momenten, in denen Abstraktionen versagen und man um 3 Uhr morgens allein mit dem System dasteht
• Nutze den Stack, aber behalte ein funktionierendes Modell seiner grundlegenden Failure Modes

12. Schreiben erzwingt Klarheit. Der schnellste Weg, etwas besser zu lernen, ist zu versuchen, es zu lehren

• Schreiben erzwingt Klarheit; wenn man ein Konzept anderen erklärt – in Dokumenten, Vorträgen, Code-Review-Kommentaren oder sogar im Chat mit AI –, entdeckt man Lücken im eigenen Verständnis
• Der Akt, etwas für andere lesbar zu machen, macht es auch für einen selbst lesbarer
• Das bedeutet nicht, dass man lernt, Chirurg zu werden, indem man Chirurgie lehrt, aber die Grundannahme ist im Bereich Software Engineering weitgehend richtig
• Das ist nicht nur die Großzügigkeit des Wissenteilens, sondern auch ein egoistischer Lern-Hack – wenn man glaubt, etwas verstanden zu haben, sollte man versuchen, es einfach zu erklären; dort, wo man hängen bleibt, ist das Verständnis flach
• Lehren heißt, das eigene mentale Modell zu debuggen

13. Arbeit, die andere Arbeit möglich macht, ist wertvoll – aber unsichtbar

• Glue Work – Dokumentation, Onboarding, teamübergreifende Koordination, Prozessverbesserung – ist essenziell, kann aber bei unbewusstem Einsatz die technische Laufbahn ausbremsen und zu Burnout führen
• Die Falle besteht darin, sie nur als „hilfreich“ zu behandeln, statt als bewusst, begrenzt und mit sichtbarem Einfluss
• Man sollte Zeitlimits setzen, rotieren und in Artefakte überführen: Dokumente, Templates, Automatisierung – und sie nicht als Charaktereigenschaft, sondern als Impact lesbar machen
• Wertvoll, aber unsichtbar, ist eine gefährliche Kombination für die Karriere

14. Wenn du jede Debatte gewinnst, sammelst du vermutlich stillen Widerstand an

• Man lernt, den eigenen Überzeugungen zu misstrauen; wenn man zu leicht „gewinnt“, läuft meist etwas schief
• Dass Menschen aufhören, mit dir zu streiten, heißt nicht unbedingt, dass du sie überzeugt hast, sondern oft, dass sie aufgegeben haben und die Nicht-Übereinstimmung später in der Umsetzung ausdrücken
• Echte Abstimmung dauert länger – man muss andere Perspektiven wirklich verstehen, Feedback integrieren und manchmal öffentlich die Meinung ändern
• Das kurzfristige Gefühl, recht zu haben, ist weit weniger wert als die langfristige Realität, mit Kolleginnen und Kollegen zusammenzuarbeiten, die dazu bereitwillig beitragen

15. Wenn Messen zum Ziel wird, hört Messen auf, Messen zu sein

• Jede Metrik, die man dem Management sichtbar macht, wird irgendwann gespielt – nicht aus Böswilligkeit, sondern weil Menschen das optimieren, was gemessen wird
• Wenn man Codezeilen trackt, bekommt man mehr Zeilen; wenn man Geschwindigkeit misst, bekommt man aufgeblasene Schätzungen
• Der Senior-Move: Auf jede Metrik-Anfrage im Paar antworten – eine Kennzahl für Geschwindigkeit, eine für Qualität oder Risiko – und dann auf Trendinterpretation statt Schwellenwert-Verehrung bestehen
• Das Ziel ist Erkenntnis, nicht Überwachung

16. Zugeben, dass man etwas nicht weiß, schafft mehr Sicherheit, als so zu tun, als wüsste man es

• Senior Engineers, die sagen „Ich weiß es nicht“, zeigen keine Schwäche, sondern schaffen Erlaubnis
• Wenn Führungspersonen Unsicherheit zugeben, signalisiert das anderen, dass sie dasselbe tun dürfen; die Alternative ist eine Kultur, in der alle so tun, als verstünden sie alles, und Probleme verborgen bleiben, bis sie explodieren
• Man sieht den Schaden in Teams, in denen die erfahrenste Person keine Verwirrung eingesteht – Fragen werden nicht gestellt, Annahmen nicht hinterfragt, und Junior Engineers schweigen, weil sie glauben, alle anderen hätten es verstanden
• Wenn man Neugier vorlebt, bekommt man ein Team, das tatsächlich lernt

17. Dein Netzwerk hält länger als jeder Job, den du je haben wirst

• Zu Beginn der Karriere konzentriert man sich auf die Arbeit und vernachlässigt Networking; rückblickend ist das ein Fehler
• Kolleginnen und Kollegen, die in Beziehungen investiert haben – innerhalb und außerhalb des Unternehmens –, profitieren über Jahrzehnte
• Sie hören zuerst von Chancen, bauen schneller Brücken, werden für Rollen empfohlen und gründen mit Menschen Ventures, mit denen sie über Jahre Vertrauen aufgebaut haben
• Jobs sind nicht für immer, aber Netzwerke überdauern jeden einzelnen davon – man sollte sie mit Neugier und Großzügigkeit angehen, nicht als transaktionalen Hustle
• Wenn der Moment zum Wechsel kommt, öffnen oft Beziehungen die Türen

18. Die meisten Performance-Gewinne kommen nicht aus zusätzlicher Cleverness, sondern aus dem Entfernen von Arbeit

• Wenn ein System langsam wird, ist der erste Impuls, etwas hinzuzufügen – Caching-Layer, Parallelisierung, klügere Algorithmen – und manchmal ist das richtig, aber die größten Performance-Gewinne entstehen oft aus der Frage: „Was müssen wir gar nicht berechnen?“
• Unnötige Arbeit zu löschen ist fast immer wirkungsvoller, als notwendige Arbeit schneller zu machen; der schnellste Code ist Code, der nicht ausgeführt wird
• Vor der Optimierung sollte man hinterfragen, ob die Arbeit überhaupt existieren muss

19. Prozesse existieren, um Unsicherheit zu reduzieren, nicht um Papiertrail zu erzeugen

• Die besten Prozesse machen Abstimmung leichter und Fehlschläge billiger, die schlechtesten sind bürokratisches Theater – sie existieren nicht, um zu helfen, sondern um im Fehlerfall Schuld zuzuweisen
• Wenn man nicht erklären kann, wie ein Prozess Risiko senkt oder Klarheit erhöht, ist er wahrscheinlich einfach nur Overhead
• Wenn Menschen mehr Zeit damit verbringen, Arbeit zu dokumentieren als Arbeit zu leisten, läuft etwas grundlegend schief

20. Irgendwann wird Zeit wertvoller als Geld – handle entsprechend

• Am Anfang der Karriere tauscht man Zeit gegen Geld, und das ist in Ordnung, aber irgendwann kippt die Rechnung – man erkennt, dass Zeit eine nicht erneuerbare Ressource ist
• Man sieht Senior Engineers, die sich für die nächste Beförderungsstufe aufreiben und für ein paar Prozentpunkte mehr Vergütung ausbrennen
• Einige bekommen es, aber die meisten fragen sich später, ob das, worauf sie verzichtet haben, es wert war
• Die Antwort ist nicht „Arbeite nicht hart“, sondern „Wisse, was du eintauschst, und tue es bewusst“

21. Es gibt keine Abkürzungen, aber es gibt Zinseszins

• Expertise entsteht durch bewusstes Üben – sich etwas über das aktuelle Niveau hinauszuschieben, zu reflektieren und zu wiederholen – über Jahre hinweg; eine komprimierte Version davon gibt es nicht
• Der hoffnungsvolle Teil: Lernen wirkt mit Zinseszinseffekt, wenn es neue Wahlmöglichkeiten schafft, nicht nur neues Detailwissen
• Schreib – nicht für Engagement, sondern für Klarheit –, baue wiederverwendbare Primitive auf und sammle Narbengewebe in Form von Playbooks
• Engineers, die ihre Karriere wie Zinseszins behandeln, ziehen denen, die sie wie ein Los behandeln, meist deutlich davon

Abschließende Gedanken

• 21 Lektionen wirken nach viel, laufen aber eigentlich auf einige Kernideen hinaus: Neugierig bleiben, bescheiden bleiben, und verstehen, dass Arbeit immer mit Menschen zu tun hat – mit den Nutzern, für die man baut, und den Teams, mit denen man baut
• Eine Engineering-Karriere ist lang genug, um viele Fehler zu machen und trotzdem voranzukommen, und die Engineers, die man am meisten respektiert, sind nicht die, die alles richtig gemacht haben, sondern diejenigen, die aus Fehlern gelernt, ihre Erkenntnisse geteilt und weitergemacht haben
• Wer noch am Anfang der Reise steht, sollte wissen, dass diese Dinge mit der Zeit an Tiefe gewinnen; wer schon tiefer drin ist, erkennt hoffentlich einiges davon wieder