Ratschläge für neue Principal Engineers

• Ein ehemaliger Amazon-Ingenieur hat in diesem Beitrag 31 Ratschläge dazu zusammengestellt, was er über die Rolle von Principal Engineers/-Scientists von Vorbildern beobachtet und gelernt hat
• Ein Principal ist faktisch ein Multifunktionsakteur, der Produkt, Design, Engineering und Kultur ganzheitlich abdeckt und mit gutem Urteilsvermögen breit gefächerte Aufgaben übernimmt
• Im Kern geht es weniger ums Coden als um technische Vision, Design-Feedback und organisatorische Vernetzung; Aufgaben, die in früheren Rollen zentral waren, werden nun zu Nebenaufgaben
• Einen großen Teil der Arbeit macht aus, anderen den Wert von Dingen zu vermitteln, die die Organisation noch nicht wertschätzt; wichtiger als nur richtige Entscheidungen zu treffen ist die Überzeugungskraft, mit der man andere zum Mitziehen und Handeln bringt
• Man sollte sich auf Kategorien von Arbeit konzentrieren, die ohne einen Principal nicht passieren würden; andere zu vernetzen und zu fördern kann wertvoller sein als die direkte Umsetzung
• Mit Autonomie kommt Verantwortung: Man muss selbst die Probleme finden, auf die sich die Organisation konzentrieren sollte, und sich vom kritischen Pfad weg in eine benachbarte Position bewegen, um langfristig wirksam zu sein

---

1-3. Wesen und Stil der Rolle

• 1: Jeder Principal hat einen anderen Stil
  • Typen, die tief in ein Fachgebiet eintauchen, vs. Typen mit starker horizontaler Einflussnahme
  • Technische Wegbereiter vs. Typen, die Komplexität verständlich machen, vs. Typen, die mehrere Organisationen auf eine gemeinsame Vision ausrichten
  • Man sollte einen Stil finden, der zu den eigenen Stärken passt; kein Stil ist wichtiger als ein anderer
    > Amazon verlangt explizit, dass Principals hands-on arbeiten; wenn das über längere Zeit nicht der Fall ist, steigt die Wahrscheinlichkeit zu scheitern
• 2: Aufgaben, die in der vorherigen Rolle zentral waren, sind jetzt Nebenaufgaben
  • Direkt Code zu schreiben ist vielleicht nicht mehr die beste Nutzung der eigenen Zeit, dennoch bleibt Coden wichtig, um mit der Arbeit verbunden zu bleiben
  • Zu den Kernaufgaben gehören technische Vision, Design-Feedback, Sponsoring, Bereitstellung von Business-, Produkt- und Technik-Kontext, das Erkennen neuer Probleme und das Verbinden von Menschen
    > Eine bekannte Erzählung über L7+-Rollen: Selbst wenn 80 % der Zeit ins Coden fließen, besteht der größte Impact darin, alle anderen effektiver zu machen
    > Mentaler Wechsel weg vom Fokussieren auf das Coding in einem einzelnen Projekt hin dazu, alle Builder besser bauen zu lassen
    > Es kann wirksamer sein, statt nur qualitativ hochwertigen Code ins Repository einzubringen und den Code für sich sprechen zu lassen, auch Feedback zu Designvorschlägen zu geben, technische Leitfäden zu schreiben oder langfristige Visionen voranzutreiben
• 3: Teilzeit-PM für Technik, eigentlich Teilzeitkraft für alles
  • Produkt, Design, Engineering, Wissenschaft, QA, Recruiting, Finanzen, Kultur und mehr
  • „Es gibt nichts, was nicht zu deinem Job gehört.“
  • Mit gutem Urteilsvermögen kann man über die eigene Fachdomäne hinauswirken

4-7. Kommunikation und Einfluss

• 4: Zu deiner Rolle gehören mehr Kommunikation, Einflussnahme und das Vernetzen der richtigen Leute
  • Projekte sind meist umfangreich und umfassen Teams über Director- und VP-Grenzen hinweg
  • Ohne effektive Abstimmung und Zusammenarbeit ist Erfolg unmöglich
  • Man muss darauf achten, den Kunden nicht das Organigramm zuzumuten
• 5: Recht zu haben ist nicht einmal die halbe Miete
  • Man muss andere davon überzeugen, dass man recht hat, und noch wichtiger: dafür sorgen, dass es ihnen wichtig genug ist, um zu handeln
  • Man muss lernen, Momentum aufzubauen, Sponsoren zu finden und Wege zur Umsetzung zu erschließen
    > Manchmal muss man erst ein Projekt starten und seinen Wert zeigen, um das zu erreichen
    > Principals sollten mit gutem Beispiel vorangehen und wollen, dass Menschen Probleme aktiv lösen, statt auf ein Komitee zu warten
    > „Der Principal ist das Komitee selbst – worauf warten wir also? :)“
• 6: Ein großer Teil der Arbeit besteht darin, anderen den Wert von Dingen zu vermitteln, die die Organisation nicht wertschätzt
  • Das Publikum reicht von Führungskräften bis zu ausführenden ICs (Individual Contributors)
  • Das ist die schwierigste Aufgabe und scheitert oft, aber als jemand mit Blick in die Zukunft und breiterer Perspektive muss man sie trotzdem angehen
  • Ein Mentor hielt es schon für ein hervorragendes Ergebnis, wenn von 10 vorgeschlagenen Dokumenten etwa 3 umgesetzt wurden
    > Im Gegensatz zu ICs, die tägliche Arbeit auf Teamebene tragen, haben L7+-Rollen Raum für die breitere und langfristigere Perspektive des Unternehmens
    > So lässt sich Impact objektiver bewerten, und genau auf dieser Ebene Mehrwert zu schaffen ist besonders wertvoll
• 7: Es gibt Kategorien von Arbeit, die ohne Principals nicht passieren würden
  • Meist liegen sie an der Schnittmenge aus echtem Interesse und besonderer Stärke
  • Etwa schnelle Prototypen bauen und sie dem Leadership zusammen mit neuen Kundenerfahrungen zeigen, Brücken zwischen Organisationen oder Praktikern in der Branche schlagen oder eine 3-Jahres-Vision formulieren
  • Auf diese Kategorie von Arbeit sollte man sich konzentrieren
  • Mit fortschreitender Karriere wird sie tiefer und enger

8-11. Skalierung über andere

• 8: Die wertvollste Arbeit besteht oft nicht im Selbermachen, sondern im Verbinden
  • Man bringt ein Team, das etwas angehen will, mit einem Team zusammen, das Ähnliches schon getan hat, damit es wiederverwenden oder lernen kann
  • Dazu gehört auch, die richtigen Personen zu identifizieren, die die Arbeit leisten können und dabei wachsen
• 9: Was man allein tun kann, hat Grenzen
  • Es ist für die Organisation oft nützlicher, Zeit zu investieren, um andere zu coachen und zu mentorieren, damit sie effektiver werden
  • Zum Beispiel jede Woche einige Stunden in Office Hours oder regelmäßige Syncs investieren
  • 1–2 ICs identifizieren, die man fördern möchte, und Ziele setzen, wie man ihnen helfen kann
    > Skalierung über andere ist der Kern: Der Erfolg eines PE (Principal Engineer) zeigt sich darin, dass die Organisation dieselben Entscheidungen treffen kann wie der PE
    > Der PE kann dann zu anderen mehrdeutigen Problemen weitergehen und eine Kultur etablieren, die die richtigen Ergebnisse hervorbringt
    >
    > Man möchte zwar allen helfen, sollte die Energie langfristig aber darauf konzentrieren, Menschen aufzubauen, die den eigenen Platz ersetzen können
    > In alle, die dieses Potenzial zeigen, sollte man gezielt Zeit investieren, damit sie wiederum anderen helfen können, bei denen das Potenzial aktuell noch weniger sichtbar ist
• 10: Vom Einbinden anderer in die Arbeit dazu übergehen, die Arbeit zu ihrer Arbeit zu machen
  • Jemandem die Chance geben, genau die Art von Arbeit zu übernehmen, die einen selbst an die aktuelle Position gebracht hat
  • Unterstützung geben und die Voraussetzungen für Erfolg schaffen
  • Sorgen muss man sich nicht machen: Es gibt einen endlosen Backlog wichtiger Probleme für Kunden und interessanter Chancen
    > 1–2 Stunden pro Woche mit jemandem zu verbringen, damit diese Person unter eigener Anleitung 40 Stunden Arbeit leisten kann, ist echte Principal-Skalierung
• 11: Wenn du Arbeit an andere übergibst, gehört sie jetzt ihnen
  • Man kann Kontext und Guidance geben, aber letztlich ist die Richtungsentscheidung ihre Aufgabe
  • Dazu gehört auch, ihnen Ansätze zu erlauben, die man selbst nicht wählen würde
  • Wenn es schiefgeht, lernen alle daraus; wenn es gutgeht, kann man selbst etwas lernen
  • Nur wenn ein Projekt auf eine risikoreiche Einbahnstraße zusteuert, die großen Schaden anrichten kann, muss man eingreifen

12-15. Meetings und Beteiligung steuern

• 12: In Meetings Raum für andere schaffen
  • Manchmal wartet ein Raum auf die Meinung oder Entscheidung der erfahrensten Person; durch Fragen kann man Raum für andere schaffen
  • Wenn jemand nicht mitredet, kann man die Person behutsam über ein Thema einbeziehen, das zu ihren Stärken passt
  • Falls in einem Meeting jemand fehlt, der an der Diskussion beteiligt sein sollte, sollte diese Person zum nächsten Meeting eingeladen werden
• 13: Du musst deinen Wert nicht ständig beweisen
  • Die effektivsten Principals schweigen manchmal ein ganzes Meeting lang oder hinterlassen fast keine Kommentare in Dokumentenreviews
  • Wenn Team und Diskussion gut laufen, ist das großartig
  • Dann kann man im Arbeitsfluss einen Schritt zurücktreten und die Energie anderswo einsetzen
    > Vorsicht: Wenn man anwesend ist und schweigt, kann das als stillschweigende Zustimmung gelesen werden; man sollte sich der Bedeutung von Teilnahme und Multitasking bewusst sein
• 14: In Meetings mit Executives muss nicht jedes Thema der Agenda behandelt werden
  • Ein gutes Meeting liegt vor, wenn Executives tief in das Thema einsteigen, sinnvolle Fragen stellen und Entscheidungen treffen oder Blockaden lösen, die nur sie lösen können
• 15: In einer breiten Rolle kann sich die ganze Woche mit allem füllen, was hereinkommt
  • Dazu gehören Reviews, Eskalationen, E-Mails, Hilfsanfragen und mehr
  • Je länger man in der Organisation ist, desto größer wird das Problem oft, weil man viel weiß oder Vertrauen aufgebaut hat und zur „go-to“-Person wird
  • Dadurch wird man am Ende zur „unverzichtbaren“ Person in jedem Meeting
  • Wenn man nicht lernt, die eigene Zeit zu schützen, bleibt keine Zeit, um Ideen voranzutreiben, die einem wirklich wichtig sind
  • Man muss nicht in jedem Meeting sitzen oder zu jeder Idee eine Meinung haben, sondern nur zu den wichtigen
    > Was ein Mentor geteilt hat: Zeit zum Denken ist unverzichtbar; wenn man von Meeting zu Meeting springt, bleibt keine Zeit zum Verarbeiten und Vorausdenken
    > Man sollte hochwertige Denkzeit einplanen und sich aus Meetings ausklinken, um das nächste große Thema zu finden
    >
    > Man muss Wege zur Delegation finden: andere so aufbauen, dass sie diese Rolle übernehmen können, schafft nicht nur Freiraum für einen selbst, sondern auch Wachstumsraum für neue Leute

16-19. Impact und Kommunikation

• 16: Wenn du nicht erklären kannst, warum eine Principal-Person für das nötig ist, woran du arbeitest, arbeitest du vielleicht am Falschen (gilt auch für L6)
• 17: Aufgrund deines Status kannst du Ergebnisse manchmal mit relativ wenig Aufwand verbessern
  • Ein Titel verleiht organisatorische Privilegien und besseren Zugang zu Beziehungen und Kontext
  • In Verbindung mit Erfahrung kann man besser um die Ecke schauen
  • Deshalb kann man mit vergleichsweise geringem Aufwand die Erfolgschancen und Resultate eines Projekts substanziell verbessern
  • Das ist ein hoher ROI; wenn man solche Chancen erkennt, sollte man handeln
• 18: Ein Titel verleiht manchmal eine Aura von Glaubwürdigkeit, auch wenn sie nicht angebracht ist
  • Manchmal interpretieren Menschen spontane Kommentare über, besonders wenn sie einen noch nicht gut kennen
  • Dadurch kann wegen eines beiläufigen Kommentars plötzlich viel Arbeit ausgelöst werden
  • Das kann Zeit und Energie verschwenden
  • Deshalb sollte man klar benennen, was man weiß, was man nicht weiß, was man fordert und was nur ein Kommentar ist
• 19: Sag nicht nur das „Was“, sondern teile auch, warum du so denkst
  • Das hilft anderen, bessere Entscheidungen zu treffen
  • Es verringert Situationen, in denen andere sagen: „Principal <Name> hat das so gesagt, also machen wir …“, ohne es wirklich zu verstehen
    > Probleme, die L7-Input benötigen, betreffen meist Entscheidungen unter erheblicher Unsicherheit
    > Wichtig, aber schwierig: mentale Modelle klar auszudrücken – also wie man ohne vollständige Informationen zu einem Urteil kommt und warum bestimmtes Wissen wichtiger ist als andere Datenpunkte

20-24. Mit der Organisation verbunden bleiben

• 20: Mechanismen finden, um mit Teams verbunden zu bleiben
  • Etwa Design-Reviews, wöchentliche Demos, in der Nähe sitzen und zuhören, Team-Lunches oder lockere Gespräche auf dem Flur
  • Das hilft, den Puls der Organisation zu spüren und zu erkennen, wo die wichtigsten Probleme oder Chancen liegen
• 21: Teams helfen, weiter das große Ganze zu sehen
  • Wenn die operative Ebene tief in der täglichen Lieferung steckt, können größere und langfristige Probleme oder Chancen aus dem Blick geraten und lokale Optima entstehen
  • Mit dem eigenen Kontext kann man Teams helfen, daran erinnert zu bleiben
• 22: Man muss pragmatisch sein; Balance zwischen großem Bild und Akzeptanz lokaler Lösungen
  • Mit der operativen Ebene über Details sprechen und zuhören, denn sie sind die Experten vor Ort
• 23: Es kann sein, dass man um Review- oder Beförderungsfeedback zu Personen gebeten wird, mit denen man nur ein oder zwei Stunden verbracht hat
  • Statt Feedback niedriger Qualität auf Basis einer winzigen Stichprobe zu geben, kann man ablehnen
• 24: Zeit für die Interaktion mit Praktikanten und Mentoren schaffen
  • Schon einige wenige Berührungspunkte während eines Praktikums können transformativ sein
  • Dazu gehören ein frühes Check-in zur Kurskorrektur bei Bedarf und die Teilnahme am Demo Day
  • Gemeinsam mit Mentor und Praktikant an Ergebnissen arbeiten, die auch nach dem Praktikum noch wertvoll bleiben
  • Zum Beispiel ein Produkt-1-Pager, funktionierende Software oder technische Dokumentation

25-28. Übergang und Verantwortung als Principal

• 25: Um Principal zu werden, muss man sich auf den kritischen Pfad setzen. Um als Principal wirksam zu sein und darüber hinauszukommen, muss man sich aktiv davon entfernen
  • Früher war man die „go-to“-Person, jetzt braucht es den Wechsel vom Unverzichtbaren zum Benachbarten
  • Die Organisation sollte immer stärker von einem profitieren, darf aber für Wirksamkeit nicht von einem abhängig sein
  • Man sollte darüber nachdenken, wie man andere befähigt, die eigenen Beiträge ebenfalls leisten zu können
    > Vorsicht davor, sich in Projekte auf dem kritischen Pfad hineinzuziehen: Der Fokus wird leicht von anderen Prioritäten abgesaugt; deshalb sollte man vom kritischen Pfad wegbleiben oder, wenn man darauf ist, sich sehr strikt darauf festlegen
• 26: Wenn du zum Principal befördert wurdest, dann deshalb, weil du schon seit einiger Zeit wie ein Principal gehandelt hast
  • In der Regel seit mehr als einem Jahr
  • Deshalb muss man sich über die höheren Erwartungen des Titels nicht übermäßig sorgen
  • Einfach weitermachen, sich mit anderen Principals austauschen, den eigenen Stil finden und mit dem Leadership Schwerpunkte abstimmen
• 27: Große Freiheit bringt große Verantwortung mit sich
  • Man hat Autonomie bei der Wahl der Arbeit, aber auch Verantwortung und hohe Impact-Erwartungen
  • Freiheit bedeutet nicht, das zu tun, worauf man gerade Lust hat, sondern Ownership dafür zu übernehmen, die Probleme mit dem höchsten Hebel zu finden und zu lösen
  • Man sollte nicht erwarten, gesagt zu bekommen, was zu tun ist, oder detaillierte Führung zu erhalten
  • Es wird erwartet, dass man erkennt, worauf sich die Organisation konzentrieren sollte
• 28: Mit dem Leadership Charter definieren und abstimmen
  • Ein Ansatz: Arbeit in drei Buckets aufteilen – (i) Owner, (ii) Sponsor, (iii) Consultant
  • Consultant: an Reviews teilnehmen und Guidance geben, mit einem High-Level-Verständnis des Systems oder der Produktabsicht
  • Sponsor: zusätzlich Ideen zu Organisationsprioritäten machen, Abstimmung schaffen, Entscheidungen vorantreiben und mit Stakeholdern arbeiten
  • Owner: zusätzlich zu allem oben Systemexperte und erste Ansprechperson sein und fast obsessive Verantwortung für den Erfolg von Design, Umsetzung und Impact tragen
  • Der Autor besitzt typischerweise 1–2 Projekte (>50 % der Zeit), sponsert 2–3 Projekte (~20 % der Zeit) und verbringt die restliche Zeit mit Consulting

29-31. Persönliches Wachstum und Nachhaltigkeit

• 29: Principal zu sein kann einsam sein
  • Man ist Teil aller Teams und zugleich Teil keines Teams
  • Deshalb sollte man ein Netzwerk von Peers aufbauen, mit denen offene Gespräche möglich sind
  • Es ist wahrscheinlich nicht wichtig, ob sie im selben Unternehmen oder derselben Domäne arbeiten
• 30: Die eigenen Bedürfnisse nicht ignorieren
  • Zeit und Raum für Projekte schaffen, die Lernen, Wachstum und Wohlbefinden unterstützen
  • Kurzfristig kann das egoistisch wirken, ist aber viel besser, als in der Organisation auszubrennen
  • Wenn man aktiv nach Arbeit sucht, die einen gesund, glücklich und wachsend hält, profitiert auch die Organisation davon und kann einen leichter langfristig halten
  • Gemeinsam mit dem Manager Wege zur Balance finden
• 31: Weiter lernen; die Branche bewegt sich schnell
  • Wenn man Projekte übernimmt, die nichts lehren oder zumindest nichts Relevantes für die Arbeit, fällt man zurück
  • Manchmal ist das unvermeidbar; in solchen Fällen sollte man die Arbeit timeboxen
  • Lernen muss nicht nur aus dem Job kommen
  • Es gibt PEs, die Papers und technische Lehrbücher lesen oder am Wochenende Prototypen hacken, um neue Ideen und Technologien besser zu verstehen

Weitere Ressourcen

• Amazon Principal Engineering Community Tenets
• Staff Engineer: Leadership Beyond the Management Track
• The Staff Engineer's Path: A Guide for ICs Navigating Growth and Change
• The job behind the job [of a high level IC]

Hinweis: Bei Amazon/Google ist ein Principal Tech IC im Sinne eines höchsten technischen Leaders mit strategischer Rolle auf Management-Niveau ein deutlich höheres Konzept als das, was im Deutschen meist unter „Senior Engineer“ verstanden wird

[roxie]

„Wie man ohne alle Informationen zu einer Entscheidung kommt und warum bestimmtes Wissen wichtiger ist als andere Datenpunkte“ beurteilen zu können, scheint wirklich beeindruckend zu sein.