Überarbeitete Regeln für Engineering Leadership

• Zusammenfassung von fünf Regeln für Engineering Leadership, die im letzten Jahr im Umfeld von AI-Tool-Umstellungen und schnellem Wachstum (Hypergrowth) überprüft und neu formuliert wurden, zusammen mit konkreten Projektbeispielen zu ihrer Untermauerung
• Migrationen können heute zu 95 % von Einzelpersonen statt von Teams getragen und in 10 % der früher nötigen Zeit abgeschlossen werden; je niedriger die Einstiegskosten, desto größer der Einfluss individueller Urteile
• Erstfassungen von Code sind nahezu kostenlos, aber die Kosten von funktionierendem Code hängen von Development Harnesses wie Tests und CI/CD ab und sind daher nicht kostenlos
• Der Standardfall der meisten Prozesse lässt sich mit Agenten vollständig automatisieren; auch der erste Pass im Code Review ist mit einem guten Harness schneller und wirksamer als durch Menschen
• Um die Vorteile von AI tatsächlich zu realisieren, braucht es als Voraussetzung beständige Teams mit Domain-Kontext sowie schnelle und robuste Entscheidungen

---

Hintergrund

• Anfang 2014 bis Ende 2020 in einem Hypergrowth-Umfeld gearbeitet; der größte Wert von Hypergrowth ist, dass Fehler nicht erst nächstes Jahr, sondern schon nächsten Monat sichtbar werden (wenn man sich schnell bewegt, eskalieren Probleme groß)
• Der Grund, zuletzt wieder an Hypergrowth zu denken, sind das schnelle Geschäftswachstum von Imprint, umfangreiche Neueinstellungen im letzten Jahr und die veränderte Arbeitsgeschwindigkeit durch die Umstellung auf AI-Tools
• Dieser Beitrag fasst die neu formulierten Führungsregeln zusammen und zugleich die konkreten Projekte des vergangenen Jahres, die zu diesen Überzeugungen geführt haben

Die überarbeiteten Regeln

1. Migrationen können von Einzelpersonen statt von Teams durchgeführt werden

• Selbst komplexe und große Änderungen werden zu 95 % von einer Einzelperson oder dem führenden Team verantwortet und in 10 % der bisherigen Zeit abgeschlossen
• Je niedriger die Einstiegskosten, desto größer werden Belohnung und Strafe für die Qualität jeder Migration
  • Schon kleine Mängel zerstören das mentale Softwaremodell der Kolleginnen und Kollegen, die den Code mit pflegen
• Der Einfluss individueller Urteile auf das Unternehmen ist größer als je zuvor

2. Erstfassungen von Code sind fast kostenlos, aber die Kosten von funktionierendem Code hängen vom Development Harness ab

• Wir leben in einer Zeit, in der alle Code schreiben sollten, aber Code zu schreiben, der sauber funktioniert, ohne schmutzige Edge Cases zu umgehen, ist weiterhin schwierig
• Wie schwierig das ist, wird durch das Development Harness bestimmt: Tests, CI/CD, Validierungsumgebungen, Change Previews usw.
• Selbst in einem Unternehmen, in dem „alle programmieren“, ist der entscheidende Punkt nicht, dass das Marketing-Team Server-Allokationen reduziert, sondern ob es Grenzen gibt, innerhalb derer es sicher mitwirken kann (ähnlich wie bei SaaS-Produkten, die Anpassungen per Software-Erstellung erlauben)
• Die Dinge, die vor zwei Jahren am wertvollsten waren, um die Engineering-Geschwindigkeit zu erhöhen, sind auch heute noch am wertvollsten

3. Den Standardfall von Prozessen für Agenten optimieren

• Mit dem richtigen Harness, geeigneten Kontrollen, Domain-Kontext und gutem Urteilsvermögen der Entwerfenden lässt sich der Standardfall der meisten Prozesse vollständig automatisieren
• Der Standardfall menschlicher Code Reviews ist langsamer und weniger wirksam als Code Review durch ein gutes Harness
  • Das Harness übersieht Dinge, aber Menschen auch; in den meisten Bereichen sind Änderungen relativ sicher
  • Einige Hochrisikobereiche sind jedoch Ausnahmen; wenn man diese Unterscheidung sauber trifft, wird man ohne zusätzliches Risiko schneller, andernfalls entstehen unzählige Probleme
• Als Folgerung daraus arbeiten Planungsprozesse wie wöchentliche oder zweiwöchentliche Sprints auf einer zu niedrigen Flughöhe; gemeinsame menschliche Planung sollte auf einer höheren Ebene stattfinden

4. Beständige Teams mit Domain-Kontext und hohem Ownership bleiben noch wichtiger

• Die Lehre aus Uber: beständige und belastbare Teams erzielen durch angesammelten Domain-Kontext, Kameradschaft und starke Ownership magische Ergebnisse
• Auch in einer Zeit niedriger Ausführungskosten muss man die richtigen Dinge tun; das ist etwas leichter geworden, aber nicht grundlegend leicht
  • Beispiel: Die für eine Produktionsoptimierung nötigen Daten wurden gar nicht erfasst, daher war die Lösung des Harnesses zwar plausibel, aber falsch; die einzige Lösung war die Instrumentierung der fehlenden Informationen
• Gegen die verbreitete Annahme, AI-first-Unternehmen würden mit wenigen genialen Engineers betrieben: Selbst Menschen mit hohem Urteilsvermögen stoßen wegen fehlenden Domain-Kontexts an Grenzen, daher bleibt das beständige Team die grundlegende Einheit

5. Schnelle, gute und robuste Entscheidungen sind die Voraussetzung, um von AI zu profitieren

• Wenn man Legal Review durch Automatisierung ersetzen will, muss Legal diese Änderung verbindlich zusagen können; das hängt von sorgfältigem Design und der Kooperationsbereitschaft des Teams ab
• Der Nutzen höherer Ausführungsgeschwindigkeit ist nur möglich, wenn man schnelle, robuste und gute Entscheidungen treffen kann
• Das ist der Hauptgrund, warum die durchschnittliche CTO-Rolle heute viel technischer und weniger bürokratisch ist als noch vor einem Jahr
  • Häufig ist dies die einzige Person, die bei Meinungsverschiedenheiten zwischen Teams verbindliche Entscheidungen treffen kann, und trifft daher fortlaufend Entscheidungen, um die Geschwindigkeit aufrechtzuerhalten
  • Nicht weil Executives grundsätzlich bessere Entscheider wären, sondern weil verbindliche Entscheidungen auf Executive-Ebene einzigartig stark sind, solange die Führungskräfte untereinander abgestimmt sind und die Entscheidungen respektieren

Konkrete Anwendungsbeispiele

Migrationen

• Vor einem Jahr etwa 6 manuelle Deployments pro Woche → heute 200–400 Deployments pro Woche; die Zahl der Engineers hat sich verdoppelt, aber im Jahresvergleich ist das ein 20- bis 30-facher Anstieg; zwei Personen aus dem Infrastrukturteam haben die Arbeitsweise rund um Deployment und Migration in zwei Monaten zu 90 % neu aufgesetzt
• Am 1. Januar nutzten etwa 25 % täglich Claude Code oder Cursor → bis Ende Februar 100 %; ohne Top-down-Vorgabe wurden Reibungen durch bessere Tool-Qualität und Gespräche mit Nichtnutzenden beseitigt; heute übernimmt das Harness fast bei jedem PR die erste Fassung
• Unterschiedliche Konfigurationsansätze wurden in zwei Konfigurationsmechanismen konsolidiert (für sich kaum ändernde Client-/Server-Konstanten bzw. für produktspezifische, sich häufig ändernde Werte), umgesetzt als unabhängige Projekte einzelner Engineers
  • Eine Person räumte die Architektur auf → eine andere implementierte die Referenzarchitektur → mehrere weitere übernahmen sie für andere Bereiche; was früher ein mehrjähriges Projekt gewesen wäre, wurde in weniger als einem Quartal abgeschlossen, inklusive interner Tools zur Wertverwaltung für Engineering- und Nicht-Engineering-Teams
• Eine Multi-Repo-Frontend-Landschaft wurde in etwa einem Monat in eine Monorepo-Architektur überführt; 95 % davon wurden von einer einzigen Frontend-Ingenieurin bzw. einem einzigen Frontend-Ingenieur getragen, wodurch ein gemeinsames Frontend-Harness entstand und das reibungserzeugende Hosting von npm-Paketen vollständig entfiel
• Der zuvor weitgehend untypisierte Frontend-Code wurde vollständig statisch typisiert; ein Engineer erledigte dies über mehrere Wochen mit einer großen Zahl von Tokens
• Für bessere Security-Defaults und schnellere Deployments erfolgte der Wechsel von npm zu pnpm, umgesetzt von einem Engineer mit einigen Stunden Arbeit pro Tag über wenige Tage

Die Kosten von funktionierendem Code hängen vom Development Harness ab

• Design-Dokumente oder PRs einfach „über die Mauer“ an Engineers anderer Teams zu werfen, bringt keine Ergebnisse; schlechte („slop“) PRs und Design-Dokumente sind zwar billig, aber eher schädlich
  • Sie müssen aufgeräumt und überarbeitet werden, und dieser Kontext verschmutzt das LLM, was zu schlechteren Ergebnissen führt, als direkt neu zu beginnen
• Solange eine Führungskraft Änderungen selbst verifiziert, nach dem Deployment Dashboards prüft und auftretende Probleme behebt, sind Code-Beiträge von Managern ein großer Erfolg; andernfalls haben sie keinen positiven Effekt

Optimierung des Standardfalls von Prozessen für Agenten

• Alle eingehenden Themen des Customer-Ops-Teams werden durch ein Harness triagiert, das Teams und offene Tickets kennt und mit begrenztem Zugriff auf das Data Warehouse den Impact abschätzt; dadurch wird komplexe, hochqualifizierte, aber wenig interessante Arbeit schneller erledigt
  • Edge Cases werden weiterhin von Menschen triagiert; ohne Änderung des menschlichen Workflows werden im selben Ablauf nur einige Schritte automatisiert
• Den ersten Pass im Code Review übernimmt dasselbe Harness, das die Änderung implementiert hat, jedoch mit geleertem Schreibkontext; Menschen konzentrieren sich auf wertvolleres Feedback
• Im letzten Quartal wurden Claude Code und Cowork unternehmensweit ausgerollt; besonders das Fraud-Team ersetzte manuelle Arbeit aktiv durch erste Automatisierungsschritte und automatisierte die frühe Untersuchung potenzieller Angriffe (einschließlich Attribution auf Basis der Daten selbst)
• Migration von Jira zu Linear; mit stärkerem MCP und besserer Slack-Integration wurde die Infrastruktur für agentenorientierte Workflows ausgebaut, und ein internes Harness, das Issues aus Linear übernimmt und automatisch löst, ist mit seinem Alpha-Test fast fertig

Beständige Teams mit Domain-Kontext und hohem Ownership

• Beim Einstieg rotierten talentierte Mitarbeitende schnell zwischen Projektbereichen und waren dadurch sehr reaktiv; inzwischen gibt es in allen wichtigen Bereichen kleine dedizierte Teams, die kontinuierlich investieren und neue AI-Techniken selbst anwenden
• Nach dem Launch von SierraAI hat das Team das Produkt ununterbrochen verbessert und auf ein wirklich herausragendes Niveau gebracht; ein Ergebnis, das ohne ein dediziertes und fokussiertes Team nicht möglich gewesen wäre

Schnelle, gute und robuste Entscheidungen

• Die Änderung des Konfigurationsansatzes war umstritten, daher musste der Ansatz wiederholt erklärt werden; die Auswirkungen unterscheiden sich je Team, und der Nutzen entsteht nur auf Ökosystem-Ebene (eine Person konfiguriert die Einstellungen des ganzen Teams), weshalb es bottom-up schwer durchzusetzen ist
• Auch die Überarbeitung der CI/CD-Pipeline war umstritten, weil sie das mentale Modell von Deployment und Release verändert und per Feature Flagging Deployment und Release explizit trennt
• Auch die Konsolidierung in ein Web-Monorepo war eine umstrittene Entscheidung mit großem Nutzen durch eine einheitliche Entscheidung
• Die Einführung von SierraAI erforderte schwierige Diskussionen gegenüber Wettbewerbern und der Alternative, nichts einzuführen, sowie die Zustimmung von Führungskräften, um funktionsübergreifende Debatten abzuschließen

Fazit

• Die obigen Fälle sind nur einige repräsentative Beispiele; daneben wurde noch vieles mehr umgesetzt, und der Umfang dessen, was möglich ist, wächst jeden Monat weiter
• Die bremsenden Faktoren haben sich nicht grundlegend verändert: organisatorische Fehlanpassung, mangelnde Klarheit und schlechte technische Architektur