Ich bin ein Staff Engineer, der das Rampenlicht ignoriert.

 (lalitm.com)
1 Punkte von GN⁺ 2025-12-05 | 1 Kommentare | Auf WhatsApp teilen
  • Das produktzentrierte Modell großer Technologieunternehmen legt den Fokus auf kurzfristige Leistung und Sichtbarkeit, während in den Bereichen Infrastruktur und Developer Tools Nachhaltigkeit und Stewardship als zentrale Werte gelten
  • Der Autor arbeitet bei Google in Developer-Tools- und Infrastrukturteams und stellt das Vertrauen und die Effizienz der Ingenieure als Kunden über die Aufmerksamkeit des Managements
  • Durch langfristiges Systemmanagement (Stewardship) entstehen im Laufe der Zeit Kontextwissen und Erfahrung, die zu Innovationen in Großprojekten wie Bigtrace führen
  • Statt kurzfristiger Aufmerksamkeit zu folgen, betrachtet er Vertrauen und technische Wirkung als Vermögenswerte und baut politisches Kapital auf, mit dem er bei Bedarf „Nein“ sagen kann
  • Auch in der schnell rotierenden Technologiebranche existiert damit ein Karrieremodell auf Basis von Tiefe und Ausdauer, das langfristig Wirkung entfaltet und ein alternatives Modell darstellt

Engineering in unterschiedlichen Welten

  • Produktteams richten sich an externe Kunden aus und bewerten den Erfolg anhand kurzfristiger Metriken wie Umsatz und MAU (monatlich aktive Nutzer)
    • In diesem Umfeld sind Agilität und Sichtbarkeit (Spotlight) nötig, um die Aufmerksamkeit des Managements zu gewinnen
  • Infrastruktur- und Entwicklerwerkzeugteams richten sich dagegen auf interne Ingenieure als Kunden und bauen Werkzeuge und Systeme auf, die die Produktleistung unterstützen und Debugging ermöglichen
    • Die Aufmerksamkeit des Managements ist geringer, und da die Rekrutierung von PMs schwierig ist, entsteht eine ingenieurzentrierte Bottom-up- statt Top-down-Struktur
    • Das Team definiert selbst die Probleme, bei denen es den größten Einfluss hat, und löst diese; das Management überprüft anschließend die Wirkung

Der Zinseszinseffekt von Stewardship

  • In Produktumgebungen ist Geschwindigkeit die wichtigste Währung, in Infrastrukturumgebungen ist Kontext der zentrale Vermögenswert
    • Wird ein Ingenieur als austauschbare Ressource behandelt, geht Kontext verloren und implizites Wissen im System verschwindet
  • Der erste Nutzen langfristiger Steuerung ist die Effizienz durch Mustererkennung
    • Wer lange in einem Bereich bleibt, kann neue Anfragen schnell mit früheren Fällen verknüpfen und schneller lösen
  • Der zweite Nutzen ist die systemische Innovation
    • Einige Probleme werden nur durch langfristige Beobachtung sichtbar, und das Ergebnis ist Bigtrace
      • Anfang 2023 stellten mehrere Google-Teams fest, dass sie Performancetracing-Daten im Terabyte- bis Petabyte-Bereich nicht verarbeiten konnten
      • Nach einem Jahr Prototypenforschung und Feedback-Sammlung wurde Bigtrace zu Beginn 2024 aufgebaut
      • Heute verarbeitet es monatlich mehr als 2 Milliarden Traces, die von über 100 Ingenieuren genutzt werden
    • Hätte ich mich damals für kurzfristige Projektwechsel entschieden, gäbe es Bigtrace nicht

Die Kraft des „Nein“

  • High-Visibility-Projekte bringen Ressourcen und Aufmerksamkeit, gehen aber mit politischer Volatilität und dem Risiko von Qualitätsverlusten einher
  • Das durch langfristiges Stewardship aufbauende Vertrauenskapital gibt die Kraft, den Reizen des Rampenlichts zu widerstehen
    • Beispiel: Im KI-Boom wurde der Wunsch geäußert, LLM in Perfetto zu integrieren; da jedoch Präzision den Kernwert darstellt, wurde es bewusst abgewogen
    • Beim Kernel-Debugging sind präzise Zeitstempel essenziell, Halluzinationen (hallucination) sind nicht akzeptabel
    • Es geht dabei jedoch nicht um ein „ewiges Nein“, sondern um ein „Wir warten, bis es korrekt implementiert ist“

Alternative Währung der Einflussnahme

  • Wer aus dem Rampenlicht heraustritt, verliert Management-Sichtbarkeit, gewinnt dafür eine andere Währung: technische Vertrauenswürdigkeit und Nützlichkeit
  • Shadow Hierarchy (Schattenhierarchie)
    • In Infrastrukturorganisationen ist es wichtiger, von den Vorgesetzten der Kundenteams anerkannt zu werden als vom eigenen Vorgesetzten
    • Beispiel: Wenn das Pixel-Team sagt „Ohne Perfetto ist Debugging unmöglich“, dann erreicht dieser Einfluss über die Managementkette hinweg die Unternehmensführung
    • Das ist keine Politik, sondern technisch begründete Fürsprache auf Basis von Vertrauen, die in Beförderungsbewertungen ein starkes Signal liefert
  • Utility Ledger (Wirkungsbuch)
    • Utility: Wenn ein Tool bei der Fehlerbehebung genutzt wird, wird sein purer Nutzen belegt
    • Criticality: Direkte Verbindung zum Erfolg zentraler Produktteams
    • Ubiquity: Mehrere Organisationen teilen dieselben Traces und arbeiten gemeinsam
    • Scale: Die Verarbeitung von Petabyte-Daten belegt die Robustheit der Architektur
    • Die Kombination dieser Metriken sichert anhaltenden Einfluss, der selbst bei organisatorischen Neuausrichtungen stabil bleibt

Typen und Entscheidungen eines Staff Engineers

  • Laut Will Larsons Staff Engineer gibt es mehrere Arten von Staff Engineers, darunter Solver/Right Hand und Architect/Tech Lead
    • Der erste Typ ist der Problemlöser, der die Intentionen des Managements umsetzt; der zweite der langfristige Besitzer einer bestimmten Domäne
  • Der Autor gehört zur zweiten Gruppe und betont tiefe technische Kontexte und langfristige Verantwortung
  • Dieser Ansatz ist in der Regel nur in ertragreichen Großunternehmensumfeldern möglich und hängt von Glück und Entscheidung ab
    • Auf ein gutes Team zu stoßen ist Glück, doch jahrelang zu bleiben und als Engineer zu wachsen ist eine Entscheidung
    • Diese Teams werden nach außen oft nicht wahrgenommen, aber sie erhalten eine langfristige Mission und eine stabile Engineering-Kultur

Fazit

  • Die Tech-Industrie preist das Motto „Bewege dich schnell“, doch ein Pfad aus Tiefe und Geduld existiert ebenso
  • Auch ohne dem Rampenlicht zu folgen lässt sich eine sinnvolle und einflussreiche Karriere aufbauen
  • Der Aufbau nachhaltiger Systeme durch langes Verweilen im Problemraum ist die wohl ambitionierteste Entscheidung

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-12-05
Hacker-News-Kommentare

  • Was ich in mehr als 25 Jahren Arbeit gelernt habe: Wenn man sich seine eigene Geschichte und seine Leistungen nicht selbst aneignet, nimmt sie sich jemand anderes
    Besonders in Großunternehmen kommt es oft vor, dass beliebte Leute die Anerkennung für sich beanspruchen
    Man muss nicht unbedingt im Rampenlicht stehen, aber es ist wichtig, Spuren zu hinterlassen
    Man sollte die eigenen Beiträge durch interne Dokumentation oder externe Vorträge klar festhalten

    • So etwas passiert nicht nur in US-Unternehmen, sondern ähnlich in jeder Organisation
      Wenn man nicht beliebt ist, sitzt man selbst im Baseballteam auf der Bank, und bei Graduiertenprogrammen oder in ML-Communities ist es genauso
      Die Welt funktioniert gewissermaßen wie ein Beliebtheitswettbewerbssystem
    • Wegen dieser politischen Strukturen versuche ich, dem Unternehmensleben zu entkommen
      Wenn es nicht darum geht, einfach zu arbeiten und dafür bezahlt zu werden, sondern Selbstvermarktung zwingend dazugehört, dann besitze und kontrolliere ich meine Arbeit lieber direkt selbst
    • Aber nicht jede Karriere besteht aus Projekten im Rampenlicht
      Ich denke, die wichtigste Währung im Unternehmen ist Vertrauen
      Wenn man über lange Zeit an mehreren erfolgreichen Projekten beteiligt ist, erkennt das Leadership am Ende dieses gemeinsame Muster
      Beförderungen sind langsamer, aber mit wachsendem Ruf und Netzwerk führt das zu stabilem Wachstum
    • Bei FAANG kümmert man sich ab einem gewissen Level, sobald man im Zustand von „rest & vest“ ist, um solche Probleme nicht mehr
      Man hat bereits genug verdient und interessiert sich deshalb nicht mehr für Credit
    • Auch ich habe einige Male Chancen eher dank guter Beziehungen als wegen meiner Fähigkeiten bekommen und umgekehrt durch schlechte Beziehungen Nachteile gehabt
      Bei mir hält sich das inzwischen die Waage, aber bei den meisten scheint das nicht so zu sein

  • Dieser Text ist wirklich sehr gut geschrieben
    Man sollte sich nicht nur auf den Unterton „Ich hasse Politik“ konzentrieren, sondern die politische Struktur von Infra und DevEx verstehen
    Ich habe fünf Jahre bei Slack als Infrastruktur-PM gearbeitet und den Produkt-Launch-Prozess erst im vierten Jahr gelernt
    Entscheidend war, den Erfolg interner Kunden, also der Produktingenieur:innen, zu unterstützen, und „Shadow-Hierarchy“-Feedback war der Schlüssel für Beförderungen
    Wenn man diesen internen Erfolg optimiert, wird man sowohl bei Stabilität als auch in der Karriere belohnt
    Allerdings ist das kein Cheatcode, der das Wesen des Geschäfts ignoriert

    • Auch in mittelgroßen Unternehmen funktionieren diese internen politischen und Feedback-Strukturen genauso

  • Der Autor hat den Bewertungsunterschied zwischen Product Engineering und Infrastructure Engineering gut herausgearbeitet
    Allerdings wirkt die Verallgemeinerung auf Basis von Google als besonderem Umfeld etwas naiv
    Wenn sich Marktlage oder Prioritäten des Leadership ändern, muss man auch den Wert, den man aufgebaut hat, neu definieren

    • Der Verfasser des Originals war sich dessen bewusst
      Er hat betont, dass sein Text kein allgemeingültiger Erfolgsleitfaden ist, und erklärt, dass in anderen Umfeldern andere Strategien nötig sind
    • Ein weiterer Leser widersprach mit dem Hinweis, solche Einwände würden bereits am Ende des Textes behandelt; daher sei er nicht naiv

  • In Großunternehmen sind Bewertungen nach Art einer Popularitätsabstimmung häufig
    Oft wird man nach vagen Kriterien wie „Community Leadership“ bewertet
    Ich denke aber, dass der eigentliche Wert darin liegt, still gute Arbeit zu leisten und anderen zu helfen

    • Es fühlt sich schwierig an, die Balance zwischen VC-artigem abstraktem Wert und MBA-artiger ROI-Fixierung zu finden
    • Unauffällige tiefgehende technische Arbeit wird oft unterschätzt, und wenn man sie falsch behandelt, droht das ganze System zusammenzubrechen
    • Heutzutage gibt es viele Manager, die Codequalität nicht bewerten können, sodass am Ende nach Beliebtheit beurteilt wird
      Ingenieur:innen stehen damit vor dem Dilemma, sich zwischen solidem Code und Selbstvermarktung entscheiden zu müssen
    • Früher wurde man nur gelobt, wenn man ein Problem gelöst hatte, während konstante Leistung als selbstverständlich galt
      Letztlich ist die richtige Gestaltung von Anreizen der Kern guter Organisationsführung

  • In 25 Berufsjahren habe ich meist alle zwei Jahre die Firma gewechselt, aber im jetzigen Unternehmen bin ich bereits im vierten Jahr
    Ich baue eine interne Plattform auf und löse echte Kundenprobleme; unabhängig von Politik ist das der Grund, der mich jeden Tag antreibt

    • Solcher Bottom-up-Erfolg ist selten, aber wenn er einmal eintritt, gibt er enorme Energie

  • Ich war als Infrastruktur- und Tooling-Ingenieur lange in einem Team, und das, was dieser Text beschreibt, passt sehr gut zur Realität
    Manchmal gibt es leicht sichtbare Erfolge, aber meist ist es ruhige, zufriedenstellende alltägliche technische Arbeit

  • Auch ich arbeite lieber im Infrastrukturteam als im Produktteam
    Man ist freier von den Launen des Leadership und kann sich auf technische Exzellenz konzentrieren
    Derzeit genieße ich es in einem mittelgroßen Unternehmen, still die Infrastruktur anderer Teams zu verbessern

  • Schon die Situation, den eigenen Wert mit so einem Text verteidigen zu müssen, ist kein gutes Zeichen
    Natürlich sind Selbstvermarktung und Charisma für Beförderungen von Vorteil, aber man muss dafür nicht die Welt schlechter machen
    Menschen, die still arbeiten wie Wozniak, werden ebenfalls gebraucht

  • Dass der Autor dem Rampenlicht ausweichen konnte, liegt daran, dass er bereits Staff Engineer ist
    In der Startup-Zeit hatte er Vertrauen aufgebaut und musste sich daher nicht besonders in Szene setzen, aber in Big Tech war die Politik härter
    Ich wollte kurzfristig Geld verdienen und dann gehen, aber jüngeren Praktikant:innen zu Anerkennung zu verhelfen war deutlich schwieriger
    Heute verschafft mir schon mein Projekt selbst Sichtbarkeit, sodass ich mich nicht extra promoten muss

    • Andere stimmen dem allerdings nicht zu
      Sie sagen, dass sie schon als L3 bei Google, ohne dem Rampenlicht nachzujagen, allein durch Teilen und Zusammenarbeit mit anderen Ingenieur:innen ausreichend Anerkennung bekommen hätten

  • Wenn man genug Kapital, ob sozial oder finanziell, aufgebaut hat, kann man drei Jahre durchhalten; wenn im zweiten Jahr Erfolge kommen, geraten die anfänglichen Fehltritte in Vergessenheit
    Das Problem ist das Risiko, wenn man falschliegt

    • Ein weiteres Risiko besteht darin, dass niemand den Wert erkennt, wenn man ein großes Problem im Voraus verhindert hat
      Selbst wenn man sich für bugfreie Releases einsetzt, wird am Ende oft nur die Person gelobt, die das Problem mit Überstunden gelöst hat
    • Wenn man jedoch ausreichend mit Kund:innen spricht und den Marktkontext versteht, kann man das Risiko verringern
      Natürlich spielt auch Glück eine Rolle, aber ich glaube daran, dass Chancen zu den Vorbereiteten kommen