Kapitel 1. Was würdest du sagen, was du hier tust?

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: translation-feedback@oreilly.com

Die Idee einer Ingenieurlaufbahn oder einer "technischen Laufbahn" ist für viele Unternehmen neu. Die Unternehmen sind sich nicht einig darüber, welche Eigenschaften sie von ihren leitenden Ingenieuren erwarten und welche Art von Arbeit diese Ingenieure erledigen sollen. Obwohl sich die meisten darin einig sind, dass die Spitze der technischen Schiene nicht einfach nur "seniorer" ist, wie Silvia Botros geschrieben hat, haben wir kein gemeinsames Verständnis davon, was das ist. Deshalb beginnen wir dieses Kapitel mit einer existenziellen Frage: Warum sollte ein Unternehmen wollen, dass sehr erfahrene Ingenieure in der Firma bleiben? Dann werden wir die Rolle auspacken: die technischen Anforderungen, die Anforderungen an die Führung und was es bedeutet, selbstständig zu arbeiten.

Technische Mitarbeiter/innen haben viele verschiedene Aufgaben. Es gibt viele gute Möglichkeiten, den Job zu machen. Aber manche Formen sind für bestimmte Situationen besser geeignet, und nicht alle Organisationen brauchen alle Arten von Personalingenieuren. Deshalb werde ich darüber sprechen, wie man eine Ingenieursposition charakterisieren und beschreiben kann: Umfang, Tiefe, Berichtsstruktur, Hauptschwerpunkt und andere Merkmale. Anhand dieser Beschreibungen kannst du genau sagen, wie du arbeiten willst, in welche Art von Rolle du hineinwachsen möchtest oder wen du einstellen musst. Da verschiedene Unternehmen unterschiedliche Vorstellungen davon haben, was ein/e Ingenieur/in tun sollte, arbeiten wir daran, dein Verständnis mit dem anderer wichtiger Personen in deinem Unternehmen in Einklang zu bringen.

Fangen wir damit an, was dieser Job überhaupt ist.

Was ist überhaupt ein Staff Engineer?

Wenn der einzige Karriereweg darin bestünde, eine Führungskraft zu werden (wie in dem in Abbildung 1-1 links dargestellten Unternehmen), stünden viele Ingenieure vor einer schwierigen Entscheidung: entweder in einer technischen Position zu bleiben und sich weiterzuentwickeln oder ins Management zu wechseln und sich dort beruflich weiterzuentwickeln.

Deshalb ist es gut, dass viele Unternehmen jetzt eine "technische" oder "individuelle" Laufbahn anbieten, die eine Karriere parallel zu einer Führungsposition ermöglicht. Die Leiter auf der rechten Seite in Abbildung 1-1 zeigt ein Beispiel.

Abbildung 1-1. Zwei Beispiele für Karriereleitern, eine davon mit mehreren Wegen.

Die Jobleitern unterscheiden sich von Unternehmen zu Unternehmen, so sehr, dass eine Website, levels.fyi, eingerichtet wurde, die technische Karriereleitern in verschiedenen Unternehmen vergleicht.1 Die Anzahl der Sprossen auf diesen Leitern variiert ebenso wie die Namen der einzelnen Sprossen. Es kann sogar sein, dass du dieselben Namen in einer anderen Reihenfolge siehst.2 Aber sehr oft wird das Wort Senior verwendet. Marco Rogers, ein technischer Leiter, der in zwei Unternehmen Karriereleitern entwickelt hat, bezeichnet die Senior-Stufe als "Anker" für eine Karriereleiter. Rogers sagt: "Die unteren Stufen dienen dazu, die Selbstständigkeit zu erhöhen, während die oberen Stufen den Einfluss und die Verantwortung vergrößern."

Senior wird manchmal als die "Amtszeit"-Ebene angesehen: Du brauchst nicht weiter zu gehen.3 Aber wenn du es tust, kommst du in die Ebene der "technischen Führung". Die erste Stufe über dem Senior wird oft als "Staff Engineer" bezeichnet, und diesen Namen werde ich auch in diesem Buch verwenden.

In der zweigleisigen Karriereleiter aus Abbildung 1-1 kann ein leitender Ingenieur wählen, ob er sich die Fähigkeiten aneignet, um entweder zum Manager oder zum angestellten Ingenieur befördert zu werden. Nach der Beförderung wird ein Rollenwechsel vom leitenden Ingenieur zum Manager oder umgekehrt als Seitwärtsbewegung betrachtet und nicht als weitere Beförderung. Ein leitender Ingenieur hätte den gleichen Dienstgrad wie ein leitender Manager, ein leitender Ingenieur wäre ein Direktor und so weiter; diese Stufen können in den Karriereleitern des Unternehmens sogar noch höher gehen. (Für alle Positionen oberhalb des Senior Managers verwende ich den Begriff Staff+, der von Will Larson in seinem Buch Staff Engineer geprägt wurde).

So sieht also der Job auf einer Leiter aus. Aber schauen wir uns doch mal an , warum es die technischen Führungsebenen gibt. In der Einleitung habe ich über die drei Säulen der technischen Laufbahn gesprochen: Denken in großen Zusammenhängen, Projektdurchführung und Aufsteigen. Warum brauchen wir Ingenieure, die diese Fähigkeiten haben? Warum brauchen wir überhaupt Ingenieurinnen und Ingenieure?

Warum brauchen wir Ingenieure, die das große Ganze sehen können?

Jede technische Organisation muss ständig Entscheidungen treffen: Technologie auswählen, entscheiden, was gebaut werden soll, in ein System investieren oder es abschaffen. Einige dieser Entscheidungen haben klare Eigentümer und vorhersehbare Konsequenzen. Andere sind grundlegende architektonische Entscheidungen, die sich auf jedes andere System auswirken, und niemand kann behaupten, genau zu wissen, wie sie sich auswirken werden.

Gute Entscheidungen brauchen einen Kontext. Erfahrene Ingenieure wissen, dass die Antwort auf die meisten technologischen Entscheidungen "es kommt darauf an" lautet. Es reicht nicht aus, die Vor- und Nachteile einer bestimmten Technologie zu kennen - du musst auch die Details vor Ort kennen. Was willst du erreichen? Wie viel Zeit, Geld und Geduld hast du? Wie hoch ist deine Risikotoleranz? Was braucht das Unternehmen? Das ist der Kontext, in dem die Entscheidung getroffen werden muss.

Das Sammeln von Kontexten kostet Zeit und Mühe. Einzelne Teams neigen dazu, für ihre eigenen Interessen zu optimieren; ein Ingenieur in einem einzelnen Team ist wahrscheinlich auf das Erreichen der Ziele dieses Teams fokussiert. Aber oft haben Entscheidungen, die scheinbar nur für ein Team gelten, Konsequenzen, die weit über die Grenzen dieses Teams hinausgehen. Das lokale Maximum, also die beste Entscheidung für eine einzelne Gruppe, ist nicht unbedingt die beste Entscheidung, wenn man sie aus einer breiteren Perspektive betrachtet.

Abbildung 1-2 zeigt ein Beispiel, bei dem ein Team zwischen zwei Softwareprodukten A und B wählen muss. Beide haben die notwendigen Funktionen, aber A ist wesentlich einfacher einzurichten: Es funktioniert einfach. B ist ein bisschen schwieriger: Es wird ein paar Sprints dauern, bis es funktioniert, und niemand ist begeistert, so lange zu warten.

Aus der Sicht des Teams ist A ein klarer Gewinner. Warum sollten sie etwas anderes wählen? Andere Teams würden es jedoch vorziehen, B zu wählen. Es stellt sich heraus, dass A den Rechts- und Sicherheitsteams viel Arbeit machen wird und die IT- und Plattformteams aufgrund der Authentifizierungsanforderungen die Lösung für immer als Sonderfall behandeln müssen. Mit der Wahl von A, dem lokalen Maximum, entscheidet sich das Team unwissentlich für eine Lösung, die für das Unternehmen insgesamt eine viel größere Zeitinvestition bedeutet. B ist nur geringfügig schlechter für das Team, aber insgesamt viel besser. Diese zwei zusätzlichen Sprints werden sich innerhalb eines Quartals bezahlt machen, aber diese Tatsache wird nur deutlich, wenn das Team jemanden hat, der durch eine breitere Linse schauen kann.

Abbildung 1-2. Lokales Maximum versus bessere Entscheidung.

Um lokale Maxima zu vermeiden, brauchen Teams Entscheidungsträger/innen (oder zumindest Entscheidungsbeeinflusser/innen), die eine Außensichteinnehmen können - diedie Ziele mehrerer Teams gleichzeitig berücksichtigen und einen Weg wählen können, der für die gesamte Organisation oder das gesamte Unternehmen am besten ist. Kapitel 2 befasst sich mit dem Herauszoomen und dem Blick auf das große Ganze.

Genauso wichtig wie das Gesamtbild der Situation jetzt zu sehen, ist es, vorauszusehen, wie sich deine Entscheidungen in der Zukunft auswirken werden. Was wirst du in einem Jahr bereuen? Was wirst du dir in drei Jahren wünschen, du hättest jetzt damit angefangen? Um in die gleiche Richtung zu gehen, müssen sich Gruppen auf technische Strategien einigen: in welche Technologien soll investiert werden, welche Plattformen sollen standardisiert werden und so weiter. Diese weitreichenden Entscheidungen können sehr subtil sein und sind oft umstritten. Deshalb ist es wichtig, den Kontext zu kennen und anderen dabei zu helfen, die Entscheidung zu verstehen. In Kapitel 3 geht es darum, sich als Gruppe für eine Richtung zu entscheiden.

Wenn du also weitreichende, vorausschauende Entscheidungen treffen willst, brauchst du Leute, die das große Ganze sehen können. Aber warum können das nicht die Manager sein? Und warum kann der Chief Technology Officer (CTO) nicht einfach alle "geschäftlichen Dinge" kennen, sie in technische Ergebnisse übersetzen und weitergeben, was wichtig ist?

In manchen Teams können sie das. In einem kleinen Team kann ein Manager oft als der erfahrenste Technologe fungieren, der für die wichtigsten Entscheidungen und die technische Leitung zuständig ist. In einem kleinen Unternehmen kann ein CTO bei jeder Entscheidung bis ins kleinste Detail dabei sein. Diese Unternehmen brauchen wahrscheinlich keine eigenen Ingenieure. Aber die Autorität des Managements kann das technische Urteilsvermögen überschatten: Es kann unangenehm sein, mit den technischen Entscheidungen eines Managers zu argumentieren, selbst wenn es eine bessere Lösung gibt. Und andere Menschen zu führen ist ein Vollzeitjob. Jemand, der in eine gute Personalführung investiert, wird weniger Zeit haben, um sich über technische Entwicklungen auf dem Laufenden zu halten, und jemand, der sich tief in die Materie einarbeitet, wird weniger in der Lage sein, auf die Bedürfnisse seiner Mitarbeiter einzugehen. Kurzfristig kann das in Ordnung sein: Manche Teams brauchen nicht viel Aufmerksamkeit, um weiter erfolgreich zu sein. Aber wenn es Spannungen zwischen den Bedürfnissen des Teams und den Erfordernissen der technischen Strategie gibt, muss eine Führungskraft entscheiden, worauf sie sich konzentrieren will. Entweder werden die Teammitglieder oder die technische Ausrichtung vernachlässigt.

Das ist ein Grund dafür, dass viele Unternehmen getrennte Wege für die technische Führung und die Mitarbeiterführung einrichten. Wenn du mehr als nur ein paar Ingenieure hast, ist es ineffizient - um nicht zu sagen entmündigend - wenn jede Entscheidung auf dem Schreibtisch des CTO oder eines leitenden Managers landen muss. Du erzielst bessere Ergebnisse und Designs, wenn erfahrene Ingenieure die Zeit haben, in die Tiefe zu gehen und den Kontext und die Autorität aufzubauen, um die richtige technische Richtung vorzugeben.

Das bedeutet nicht, dass Ingenieure die technische Richtung allein vorgeben. Die Manager, die für die Zuweisung von Personal für technische Initiativen verantwortlich sind, müssen an wichtigen technischen Entscheidungen beteiligt werden. Über die Abstimmung zwischen Ingenieuren und Managern spreche ich später in diesem Kapitel und erneut, wenn wir in Kapitel 3 über die Strategie sprechen.

Warum brauchen wir Ingenieure, die Projekte leiten, die mehrere Teams betreffen?

In einer idealen Welt sollten die Teams in einer Organisation wie Puzzleteile ineinandergreifen und alle Aspekte eines laufenden Projekts abdecken. In der gleichen idealen Welt arbeiten alle an einem schönen neuen Projekt, ohne vorherige Einschränkungen oder Altsysteme, die umgangen werden müssen, und jedes Team widmet sich voll und ganz diesem Projekt. Die Teamgrenzen sind klar und unumstritten. Tatsächlich beginnen wir mit dem, was die technischen Berater von Thoughtworks als " Inverse Conway Maneuver" bezeichnet haben: eine Reihe von Teams, die genau den Komponenten der gewünschten Architektur entsprechen. Die schwierigen Teile dieses utopischen Projekts sind nur deshalb so schwierig, weil sie tiefgreifende, faszinierende Forschungen und Erfindungen beinhalten, und ihre Besitzer sind begierig auf die technische Herausforderung und den beruflichen Ruhm, sie zu lösen.

Ich möchte an diesem Projekt arbeiten, du nicht auch? Leider ist die Realität etwas anders. Es ist fast sicher, dass die Teams, die an einem teamübergreifenden Projekt beteiligt sind, schon vor dem Projekt bestanden und an anderen Dingen arbeiten, vielleicht sogar an Dingen, die sie für wichtiger halten. Sie werden auf halbem Weg des Projekts unerwartete Abhängigkeiten entdecken. Ihre Teamgrenzen haben Überschneidungen und Lücken, die in die Architektur einfließen. Und die undurchsichtigen und schwierigen Teile des Projekts sind keine faszinierenden Algorithmus-Forschungsprobleme: Sie beinhalten das Durchforsten von veraltetem Code, Verhandlungen mit vielbeschäftigten Teams, die nichts ändern wollen, und das Erkennen der Absichten von Ingenieuren, die vor Jahren gegangen sind.4 Selbst zu verstehen, was geändert werden muss, kann ein komplexes Problem sein, und nicht alle Arbeiten können zu Beginn bekannt sein. Wenn du dir die Planungsunterlagen genau ansiehst, stellst du vielleicht fest, dass die wichtigsten Entscheidungen, die am dringendsten abgestimmt werden müssen, aufgeschoben oder durchgewunken werden.

Das ist eine realistischere Projektbeschreibung. Egal, wie sorgfältig du die Teams in einem großen Projekt aufteilst, manche Aufgaben gehören am Ende niemandem, und andere werden von zwei Teams beansprucht. Der Informationsfluss misslingt oder wird bei der Übersetzung verzerrt, was zu Konflikten führt. Die Teams treffen ausgezeichnete lokale Maximalentscheidungen und Softwareprojekte bleiben stecken.

Eine Möglichkeit, ein Projekt voranzutreiben, ist jemanden zu haben, der sich für das Ganze verantwortlich fühlt und nicht nur für die einzelnen Teile. Schon bevor das Projekt beginnt, kann diese Person die Arbeit abstecken und ein Angebot erstellen. Wenn das Projekt erst einmal angelaufen ist, ist er wahrscheinlich der Autor oder Mitautor des übergeordneten Systementwurfs und der Hauptansprechpartner für das Projekt. Sie halten einen hohen technischen Standard aufrecht und nutzen ihre Erfahrung, um Risiken vorherzusehen und schwierige Fragen zu stellen. Sie verbringen auch Zeit damit, die Leiter der einzelnen Projektteile informell zu betreuen oder zu coachen - oder einfach ein gutes Beispiel für sie zu sein. Wenn das Projekt ins Stocken gerät, haben sie genug Durchblick, um die Ursachen aufzuspüren und die Blockade zu lösen (mehr dazu in Kapitel 6). Außerhalb des Projekts erzählen sie, was passiert und warum, verkaufen die Vision an den Rest des Unternehmens und erklären, was die Arbeit ermöglichen wird und wie das neue Projekt alle betrifft.

Warum können technische Programmmanager (TPMs) diese Konsensbildung und Kommunikation nicht übernehmen? Es gibt definitiv einige Überschneidungen bei den Aufgaben. Letztendlich sind die TPMs aber für die Umsetzung verantwortlich, nicht für die Planung und nicht für die technische Qualität. Die TPMs sorgen dafür, dass das Projekt pünktlich fertig wird, aber die Ingenieure sorgen dafür, dass es nach hohen technischen Standards durchgeführt wird. Personalingenieure sind dafür verantwortlich, dass die entstehenden Systeme robust sind und sich gut in die technologische Landschaft des Unternehmens einfügen. Sie sind vorsichtig, wenn es um technische Schulden geht, und hüten sich vor allem, was eine Falle für die zukünftigen Betreuer dieser Systeme darstellt. Es ist unüblich, dass TPMs technische Entwürfe schreiben oder Projektstandards für Tests oder Codeüberprüfungen festlegen, und niemand erwartet von ihnen, dass sie sich tief in die Eingeweide eines Altsystems einarbeiten, um zu entscheiden, welche Teams es integrieren müssen. Wenn ein Personalingenieur und ein TPM bei einem großen Projekt gut zusammenarbeiten, können sie ein Dreamteam sein.

Warum brauchen wir Ingenieurinnen und Ingenieure, die einen guten Einfluss haben?

Software ist wichtig. Die Softwaresysteme, die wir bauen können das Wohlbefinden und das Einkommen der Menschen beeinflussen: Die Liste der Softwarefehler bei Wikipedia ist eine gute, wenn auch ernüchternde Lektüre. Flugzeugabstürze, Ausfälle von Krankenwagen und fehlerhafte medizinische Geräte haben uns gezeigt, dass Softwarefehler und -ausfälle Menschen töten können, und es wäre naiv anzunehmen, dass es in Zukunft nicht noch mehr und größere softwarebezogene Tragödien geben wird.5 Wir müssen Software ernst nehmen.

Auch wenn weniger auf dem Spiel steht, gibt es einen Grund dafür, dass wir Software entwickeln. Abgesehen von einigen wenigen Ausnahmen im Bereich Forschung und Entwicklung existieren Unternehmen, die Software entwickeln, in der Regel nicht nur, um weitere Technologien zu entwickeln. Sie machen sich auf den Weg, um ein echtes Geschäftsproblem zu lösen oder etwas zu schaffen, das die Menschen nutzen wollen. Und das wollen sie mit einem akzeptablen Qualitätsniveau, einem effizienten Einsatz von Ressourcen und einem Minimum an Chaos erreichen.

Natürlich sind Qualität, Effizienz und Ordnung alles andere als garantiert, vor allem wenn es um Fristen geht. Wenn das "Richtige" langsamer geht, können Teams, die es eilig haben, die Software auszuliefern, Tests auslassen, an allen Ecken und Enden sparen oder Codeüberprüfungen abstempeln. Und gute Software zu entwickeln ist weder einfach noch intuitiv. Teams brauchen erfahrene Leute, die ihre Fähigkeiten verfeinert haben, die gesehen haben, was erfolgreich ist und was fehlschlägt, und die die Verantwortung für eine funktionierende Software übernehmen.

Wir lernen aus jedem Projekt, aber jeder von uns hat nur eine begrenzte Anzahl von Erfahrungen, über die er nachdenken kann. Das bedeutet, dass wir auch von den Fehlern und Erfolgen der anderen lernen müssen. Weniger erfahrene Teammitglieder haben vielleicht noch nie gesehen, wie gute Software gemacht wird, oder sie halten das Erstellen von Code für die einzige wichtige Fähigkeit in der Softwareentwicklung. Erfahrene Ingenieure können viel bewirken, indem sie Code- und Design-Reviews durchführen, bewährte Methoden für die Architektur bereitstellen und Werkzeuge entwickeln, die alle schneller und sicherer machen.

Ingenieurinnen und Ingenieure sind Vorbilder. Manager sind vielleicht dafür verantwortlich, die Kultur in ihren Teams zu bestimmen, gutes Verhalten durchzusetzen und sicherzustellen, dass die Standards eingehalten werden. Aber die technischen Normen werden durch das Verhalten der angesehensten Ingenieure im Projekt bestimmt. Egal, was die Normen vorschreiben, wenn die ranghöchsten Ingenieure keine Tests schreiben, wirst du nie alle anderen davon überzeugen können, es zu tun. Diese Normen gehen über den technischen Einfluss hinaus: Sie sind auch kulturell geprägt. Wenn erfahrene Ingenieure die Arbeit anderer anerkennen, sich gegenseitig mit Respekt behandeln und klärende Fragen stellen, ist es für alle anderen leichter, das auch zu tun. Wenn junge Ingenieurinnen und Ingenieure jemanden als die Art von Ingenieur respektieren, die sie später einmal werden wollen, ist das ein starker Motivator, so zu handeln wie sie.(In Kapitel 7 geht es darum, wie du deine Organisation durch deine Vorbildfunktion verbessern kannst).

Vielleicht bist du jetzt davon überzeugt, dass Ingenieurinnen und Ingenieure diese Dinge tun sollten, die das große Bild, das große Projekt und den guten Einfluss betreffen, aber hier ist das Problem: Sie können das nicht zusätzlich zu dem Programmierpensum eines Senior-Ingenieurs tun. In jeder Stunde, in der du Strategien schreibst, Projektdesigns überprüfst oder Standards festlegst, bist du nicht am Programmieren, an der Entwicklung neuer Systeme oder an einem Großteil der Arbeit beteiligt, für die ein Softwareentwickler bewertet werden könnte. Wenn die leitenden Ingenieure eines Unternehmens den ganzen Tag nur Code schreiben, profitiert zwar die Codebasis von ihren Fähigkeiten, aber dem Unternehmen entgehen die Dinge, die nur sie tun können. Diese Art von technischer Führung muss Teil der Stellenbeschreibung der Person sein, die sie ausübt. Es ist keine Ablenkung von der Arbeit, sondern die Arbeit selbst.

Genug der Philosophie. Was ist mein Auftrag?

Die Details eines Ingenieurberufs können variieren. Es gibt jedoch einige Merkmale des Jobs, die meiner Meinung nach ziemlich einheitlich sind. Ich werde sie hier erläutern, und der Rest des Buches wird sie als selbstverständlich voraussetzen.

Du bist kein Manager, aber du bist eine Führungskraft

Das Wichtigste zuerst: Personalentwicklung ist eine Führungsaufgabe. Ein fest angestellter Ingenieur hat oft das gleiche Dienstalter wie ein Vorgesetzter. Ein leitender Ingenieur hat oft das Dienstalter eines Direktors. Als Staff+ Engineer bist du das Gegenstück zu einer Führungskraft auf derselben Ebene, und es wird von dir erwartet, dass du genauso "der Erwachsene im Raum" bist wie sie. Es kann sogar sein, dass du älter und erfahrener bist als einige der Führungskräfte in deinem Unternehmen. Wenn du das Gefühl hast, dass jemand hier etwas tun sollte, ist die Wahrscheinlichkeit groß, dass du dieser Jemand bist.

Musst du eine Führungspersönlichkeit sein? Ingenieure auf mittlerer Ebene fragen mich manchmal, ob sie wirklich gut in "diesem schwammigen menschlichen Zeug" werden müssen, um weiterzukommen. Sind technische Fähigkeiten nicht genug? Wenn du zu der Sorte Mensch gehörst, die sich für die Softwareentwicklung entschieden hat, weil sie technische Arbeit machen wollte und es nicht liebt, mit anderen Menschen zu reden, kann es sich ungerecht anfühlen, wenn deine Berufung auf diese Mauer stößt. Aber wenn du dich weiterentwickeln willst, bringt es dich nur bedingt weiter, wenn du tief in der Technik steckst. Wenn du etwas Größeres erreichen willst, musst du mit einer größeren Gruppe von Menschen zusammenarbeiten - und das erfordert ein breiteres Spektrum an Fähigkeiten.

Da deine Vergütung steigt und deine Zeit immer teurer wird, wird von deiner Arbeit erwartet, dass sie wertvoller ist und einen größeren Einfluss hat. Dein technisches Urteilsvermögen muss die Realität des Unternehmens berücksichtigen und beurteilen, ob ein bestimmtes Projekt überhaupt sinnvoll ist. Mit zunehmender Betriebszugehörigkeit übernimmst du größere Projekte, die ohne Zusammenarbeit, Kommunikation und Abstimmung nicht erfolgreich sein können; deine brillanten Lösungen werden dich nur frustrieren, wenn du die anderen im Team nicht davon überzeugen kannst, dass dein Weg der richtige ist. Und ob du willst oder nicht, du wirst ein Vorbild sein: Andere Ingenieure werden sich an denjenigen orientieren, die den großen Titel tragen, um zu wissen, wie sie sich verhalten sollen. Also, nein: Du kannst es nicht vermeiden, eine Führungskraft zu sein.

Ingenieurinnen und Ingenieure führen aber anders als Manager. Ein Staff Engineer hat normalerweise keine direkten Untergebenen. Sie sind zwar an der Entwicklung der technischen Fähigkeiten der Ingenieure um sie herum beteiligt, aber sie sind nicht dafür verantwortlich, die Leistung der Mitarbeiter zu verwalten oder Urlaub oder Spesen zu genehmigen. Sie können niemanden entlassen oder befördern - obwohl die Teamleiter/innen vor Ort ihre Meinung über die Fähigkeiten und Leistungen der anderen Teammitglieder schätzen sollten. Ihr Einfluss zeigt sich auf andere Weise.

Führungsqualitäten gibt es in vielen Formen, die du vielleicht nicht sofort als solche erkennst. Sie kann darin bestehen, dass du "glückliche Wege" entwirfst, die andere Ingenieure vor häufigen Fehlern schützen. Sie kann darin bestehen, dass du den Code und die Entwürfe anderer Ingenieure so überprüfst, dass ihr Selbstvertrauen und ihre Fähigkeiten gestärkt werden, oder dass du darauf hinweist, dass ein Entwurfsvorschlag einem echten Geschäftsbedarf nicht gerecht wird. Lehren ist eine Form der Führung. Leise die Leistung aller zu steigern, ist Führung. Die technische Richtung vorzugeben ist Führung. Und schließlich ist da noch der Ruf als hervorragender Technologe, der andere Menschen dazu inspirieren kann, sich auf deine Pläne einzulassen, nur weil sie dir vertrauen. Wenn das nach dir klingt, dann rate mal. Du bist eine Führungspersönlichkeit.

Du bist in einer "technischen" Rolle

Personalentwicklung ist eine Führungsaufgabe, aber auch eine sehr spezialisierte Aufgabe. Sie erfordert einen technischen Hintergrund und die Fähigkeiten und Instinkte, die sich aus der Erfahrung als Ingenieur ergeben. Um einen guten Einfluss ausüben zu können, musst du hohe Maßstäbe für exzellente Technik haben und sie vorleben, wenn du etwas baust. Deine Überprüfungen von Code oder Entwürfen sollten für deine Kollegen lehrreich sein und deine Codebasis oder Architektur verbessern. Wenn du technische Entscheidungen triffst, musst du die Kompromisse verstehen und anderen helfen, sie ebenfalls zu verstehen. Du musst in der Lage sein, bei Bedarf ins Detail zu gehen, die richtigen Fragen zu stellen und die Antworten zu verstehen. Wenn du für eine bestimmte Vorgehensweise oder eine bestimmte Veränderung der technischen Kultur plädierst, musst du wissen, wovon du redest. Du musst also ein solides Fundament an technischen Fähigkeiten haben.

Das bedeutet nicht unbedingt, dass du viel Code schreiben wirst. Auf dieser Stufe ist es dein Ziel, Probleme effizient zu lösen, und das Programmieren ist oft nicht der beste Einsatz deiner Zeit. Vielleicht ist es sinnvoller, wenn du die Design- oder Führungsaufgaben übernimmst, die nur du erledigen kannst, und die Programmierung anderen überlässt. Personalingenieure nehmen sich oft unklarer, unübersichtlicher und schwieriger Probleme an und arbeiten gerade so viel daran, dass sie von jemand anderem bearbeitet werden können. Sobald das Problem überschaubar ist, wird es zu einer Chance für weniger erfahrene Ingenieure (manchmal mit Unterstützung durch den Staff Engineer).

Für einige Mitarbeiter/innen wird das tiefe Eintauchen in Codebases weiterhin das effizienteste Mittel sein, um viele Probleme zu lösen. Für andere ist es vielleicht besser, Dokumente zu schreiben, ein Meister der Datenanalyse zu werden oder eine erschreckend hohe Anzahl von Einzelgesprächen zu führen. Entscheidend ist, dass die Probleme gelöst werden, nicht wie.6

Du strebst nach Autonomie

Als du als Ingenieur angefangen hast, hat dir dein Vorgesetzter wahrscheinlich gesagt, woran du arbeiten und wie du es angehen sollst. Auf der höheren Ebene hat dir dein Vorgesetzter vielleicht gesagt, welche Probleme wichtig sind und es dir überlassen, wie du sie lösen kannst. Auf der Ebene der Mitarbeiter/innen sollte dein/e Vorgesetzte/r dich mit Informationen versorgen und dir Zusammenhänge aufzeigen, aber du solltest ihm/ihr auch sagen, was wichtig ist, genauso wie umgekehrt. Sabrina Leandro, leitende Ingenieurin bei Intercom, fragt: "Du weißt also, dass du an Dingen arbeiten sollst, die wirkungsvoll und wertvoll sind. Aber wo findest du den magischen Stapel an wirkungsvollen Aufgaben, die du erledigen solltest?" Ihre Antwort: "Du schaffst ihn!"

Als leitende Person in der Organisation wirst du wahrscheinlich in viele Richtungen gezogen werden. Es liegt an dir, deine Zeit zu verteidigen und zu strukturieren. Die Anzahl der Stunden in der Woche ist begrenzt (siehe Kapitel 4). Du kannst selbst entscheiden, wie du sie verbringen willst. Wenn dich jemand bittet, an etwas zu arbeiten, bringst du dein Fachwissen in die Entscheidung ein. Du wägst die Priorität, den Zeitaufwand und die Vorteile ab - einschließlich der Beziehung, die du zu der Person, die dich um Hilfe gebeten hat, aufrechterhalten willst - und triffst deine eigene Entscheidung. Wenn dein Geschäftsführer oder eine andere lokale Autoritätsperson dir sagt, dass etwas getan werden muss, wirst du das entsprechend gewichten. Aber Autonomie bedeutet auch Verantwortung. Wenn sich die Sache, um die du gebeten wurdest, als schädlich herausstellt, bist du verpflichtet, dich zu melden. Lass eine Katastrophe nicht stillschweigend geschehen. (Wenn du natürlich gehört werden willst, musst du dir einen Ruf als vertrauenswürdig und korrekt erarbeitet haben).

Du gibst die technische Richtung vor

Als technische Führungskraft ist es Teil der Aufgabe eines Ingenieurs, dafür zu sorgen, dass das Unternehmen eine gute technische Ausrichtung hat. Hinter dem Produkt oder der Dienstleistung, die dein Unternehmen anbietet, steht eine Vielzahl von technischen Entscheidungen: deine Architektur, deine Speicherung, die verwendeten Tools und Frameworks und so weiter. Ganz gleich, ob diese Entscheidungen auf Teamebene, in mehreren Teams oder im gesamten Unternehmen getroffen werden, ein Teil deiner Aufgabe ist es, dafür zu sorgen, dass sie getroffen werden, dass sie gut getroffen werden und dass sie aufgeschrieben werden. Deine Aufgabe ist es nicht, alle (oder auch nur einige!) Aspekte der technischen Ausrichtung zu entwickeln, sondern dafür zu sorgen, dass es eine vereinbarte, gut verstandene Lösung gibt, die die Probleme löst, die sie lösen soll.

Du kommunizierst oft und gut

Je höher dein Dienstalter ist, desto mehr wirst du auf starke Kommunikationsfähigkeiten angewiesen sein. Bei fast allem, was du tust, geht es darum, Informationen von deinem Gehirn an die Gehirne anderer Menschen zu übermitteln und umgekehrt. Je besser du dich verständlich machen kannst, desto einfacher wird deine Arbeit sein.

Deine Rolle verstehen

Diese Axiome sollten dir dabei helfen, deine Rolle zu definieren, aber du wirst feststellen, dass sie eine Menge Details der Umsetzung auslassen! Die Wahrheit ist, dass der Arbeitsalltag eines Personalentwicklers ganz anders aussehen kann als der eines anderen. Wie deine Rolle in der Realität aussieht, hängt von der Größe und den Bedürfnissen deines Unternehmens oder deiner Organisation ab und wird auch von deinem persönlichen Arbeitsstil und deinen Vorlieben beeinflusst.

Diese Vielfalt bedeutet, dass es schwierig sein kann, deine Arbeit mit der von Ingenieurinnen und Ingenieuren in deinem Umfeld oder in anderen Unternehmen zu vergleichen. In diesem Abschnitt werden wir daher einige der variablen Eigenschaften der Rolle auspacken.

Beginnen wir mit den Meldeketten.

Wo in der Organisation sitzt du?

In unserer Branche gibt es kein Standardmodell für die Unterstellung von Staff+-Ingenieuren unter den Rest der technischen Organisation. In einigen Unternehmen unterstehen die leitenden Ingenieure einem Chefarchitekten oder dem Büro des CTO; in anderen sind sie Direktoren verschiedener Organisationen, Managern auf verschiedenen Ebenen oder einer Mischung aus all diesen Bereichen unterstellt. Es gibt nicht die eine richtige Antwort, aber es kann eine Menge falscher Antworten geben, je nachdem, was du erreichen willst.

Berichtsketten (siehe das Beispiel in Abbildung 1-3) haben Einfluss darauf, wie viel Unterstützung du erhältst, in welche Informationen du eingeweiht wirst und in vielen Fällen auch darauf, wie du von Kollegen außerhalb deiner Gruppe wahrgenommen wirst.

Abbildung 1-3. Staff+ Ingenieure, die auf verschiedenen Ebenen der Organisationshierarchie arbeiten. Selbst wenn diese Ingenieure alle die gleiche Dienstaltersstufe haben, wird es für A viel einfacher sein, einen organisatorischen Zusammenhang herzustellen und an Gesprächen auf Direktorenebene teilzunehmen als für D.

Meldung "hoch"

Wenn du im Organigramm ganz oben stehst, z.B. bei einem Direktor oder Vizepräsidenten, bekommst du eine umfassende Perspektive. Die Informationen, die du bekommst, sind hochrangig und einflussreich, genauso wie die Probleme, die du lösen sollst. Wenn du einer sehr kompetenten Führungskraft unterstellt bist, kann es eine einzigartige und wertvolle Lernerfahrung sein, zu sehen, wie sie Entscheidungen trifft, Meetings leitet oder eine Krise meistert.

Allerdings wird dein Vorgesetzter wahrscheinlich viel weniger Zeit für dich haben, als wenn du einen Vorgesetzten vor Ort hättest. Dein Vorgesetzter hat vielleicht weniger Einblick in deine Arbeit und kann sich daher nicht für dich einsetzen oder dir helfen, dich weiterzuentwickeln. Ein Ingenieur, der eng mit einem einzigen Team zusammenarbeitet, aber einem Direktor unterstellt ist, könnte sich vom Rest des Teams abgekoppelt fühlen oder die Aufmerksamkeit des Direktors auf lokale Meinungsverschiedenheiten lenken, die eigentlich auf Teamebene gelöst werden sollten.

Wenn du feststellst, dass dein Vorgesetzter nicht verfügbar ist, keine Zeit hat, deine Arbeit zu verstehen, oder in technische Entscheidungen auf niedriger Ebene hineingezogen wird, die seine Zeit nicht sinnvoll nutzen, solltest du in Betracht ziehen, dass du mit einem Vorgesetzten glücklicher sein könntest, dessen Fokus mehr mit deinem übereinstimmt.

Meldung "niedrig"

Wenn du einer Führungskraft unterstellt bist, die im Organigramm weiter unten angesiedelt ist, hat das seine eigenen Vor- und Nachteile. Die Chancen stehen gut, dass dein Vorgesetzter sich mehr um dich kümmert und du eher einen Fürsprecher hast. Wenn du dich lieber auf ein bestimmtes Fachgebiet konzentrierst, kann es für dich von Vorteil sein, mit einer Führungskraft zusammenzuarbeiten, die diesem Gebiet nahe steht.

Aber ein Ingenieur, der nur einem einzigen Team zugewiesen ist, kann es schwer haben, die gesamte Organisation zu beeinflussen. Ob es dir gefällt oder nicht, Menschen achten auf Status und Hierarchien - und auf Berichtsketten. Wenn du einem direkten Vorgesetzten unterstellt bist, hast du wahrscheinlich viel weniger Einfluss. Die Informationen, die du erhältst, sind oft gefilterter und konzentrieren sich auf die Probleme des jeweiligen Teams. Wenn dein/e Vorgesetzte/r keinen Zugang zu bestimmten Informationen hat, wirst du ihn mit großer Wahrscheinlichkeit auch nicht bekommen.

Einem direkten Vorgesetzten unterstellt zu sein, kann auch bedeuten, dass du jemandem unterstellt bist, der weniger Erfahrung hat als du selbst. Das ist nicht grundsätzlich ein Problem, aber du kannst vielleicht weniger von deinem Vorgesetzten lernen, und er ist vielleicht nicht hilfreich für deine berufliche Entwicklung: Die Chancen stehen gut, dass er nicht weiß, wie er dir helfen kann. All das kann in Ordnung sein, wenn du einen Teil deines Managementbedarfs anderweitig befriedigen kannst.7 Vor allem, wenn du jemandem unterstellt bist, der in der Hierarchie weit unten steht, solltest du darauf achten, dass du dich mit dem Vorgesetzten deines Vorgesetzten auf gleicher Ebene triffst.8 Finde Wege, um mit den Zielen deines Unternehmens verbunden zu bleiben.

Wenn du und dein/e Vorgesetzte/r unterschiedliche Vorstellungen davon haben, wie du am effektivsten arbeiten kannst, kann das zu Spannungen führen. Am Ende kann es zu den bereits erwähnten lokalen Maximalproblemen kommen, bei denen dein Vorgesetzter möchte, dass du dich um das wichtigste Anliegen des Teams kümmerst , obwohl es weitaus größere Probleme innerhalb der Organisation gibt, die dich dringender brauchen. Es ist schwieriger, eine fachliche Debatte oder eine Diskussion über Prioritäten auf Augenhöhe zu führen, wenn eine Person für die Leistungsbewertung und die Vergütung der anderen verantwortlich ist. Wenn du feststellst, dass diese Auseinandersetzungen häufig vorkommen, solltest du dich dafür einsetzen, dass du einer höheren Ebene unterstellt wirst.

Was ist dein Aufgabenbereich?

Deine Berichtskette wird sich wahrscheinlich auf deinen Bereich auswirken: den Bereich, das Team oder die Teams, denen du besondere Aufmerksamkeit schenkst und für die du eine gewisse Verantwortung trägst, auch wenn du in diesem Bereich keine formale Führungsrolle innehast.

Innerhalb deines Bereichs solltest du einen gewissen Einfluss auf die kurz- und langfristigen Ziele haben. Du solltest wissen, welche wichtigen Entscheidungen getroffen werden. Du solltest eine Meinung zu Veränderungen haben und Menschen vertreten, die nicht die Möglichkeit haben, schlechte technische Entscheidungen, die sie betreffen, zu verhindern. Du solltest darüber nachdenken, wie du die nächste Generation von leitenden und angestellten Ingenieuren fördern kannst, und du solltest Projekte und Möglichkeiten vorschlagen, die ihnen helfen, zu wachsen.

In einigen Fällen erwartet dein Vorgesetzter vielleicht, dass du den Großteil deiner Fähigkeiten und Energie auf die Lösung von Problemen verwendest, die in seinen Bereich fallen. In anderen Fällen ist ein Team vielleicht nur eine Heimatbasis, während du einen Teil deiner Zeit mit Bränden oder anderen Gelegenheiten in der Organisation verbringst. Wenn du einem Direktor unterstellt bist, kann es sein, dass du auf einer hohen Ebene arbeitest und die Arbeit der gesamten Organisation koordinierst, oder du bist explizit einem Teil der Teams oder Technologiebereiche des Direktors zugewiesen. Sei dir darüber im Klaren, was es ist.

Sei bereit, deinen Aufgabenbereich zu ignorieren, wenn es eine Krise gibt: Es gibt zum Beispiel kein "nicht mein Job" während eines Stromausfalls. Du solltest dich auch damit anfreunden können, über deinen Tellerrand hinauszuschauen, bei Bedarf zu führen, zu lernen, was du lernen musst, und zu reparieren, was du reparieren musst. Ein Teil des Wertes eines Staff Engineers besteht darin, dass du nicht in deiner Spur bleibst.

Nichtsdestotrotz empfehle ich dir, dir über deinen Aufgabenbereich klar zu werden, auch wenn er vorübergehend ist und sich ändern kann.

Ein zu breiter Geltungsbereich

Wenn dein Geltungsbereich zu breit (oder unbestimmt) ist, gibt es einige mögliche Fehlerquellen.

Mangelnde Wirkung
Wenn alles zu deinem Problem werden kann, kann auch alles zu deinem Problem werden, vor allem, wenn du in einer Organisation arbeitest, die weniger Führungskräfte hat, als sie braucht. Es wird immer eine andere Nebenaufgabe geben: Es ist sogar allzu leicht, eine Rolle zu schaffen, die nur aus Nebenaufgaben besteht, ohne ein wirkliches Ziel zu haben.9 Hüte dich davor, dich zu sehr zu verzetteln. Es kann sein, dass du am Ende keinen roten Faden in deiner Arbeit hast, der dir (und denjenigen, die dich eingestellt haben) das Gefühl gibt, etwas erreicht zu haben.
Zum Engpass werden
Wenn es eine ranghohe Person gibt, von der man annimmt, dass sie alles macht, kann die Konvention entstehen, dass sie bei jeder Entscheidung dabei sein muss. Anstatt dein Unternehmen zu beschleunigen, bremst du es aus, weil es ohne dich nicht zurechtkommt.
Entscheidungsmüdigkeit
Wenn du der Falle entgehst, alles machen zu wollen, musst du dich ständig entscheiden, welche Dinge du machen willst. In Kapitel 4 werde ich über die Auswahl deiner Arbeit sprechen.
Fehlende Beziehungen
Wenn du mit einer Vielzahl von Teams zusammenarbeitest, ist es schwieriger, genügend regelmäßige Kontakte zu haben, um die Art von freundschaftlichen Beziehungen aufzubauen, die es einfacher machen, Dinge zu erledigen (und die die Arbeit angenehm machen!). Andere Ingenieurinnen und Ingenieure haben ebenfalls das Nachsehen: Sie erhalten nicht die Art von Betreuung und Unterstützung, die ein "lokaler" Ingenieur in ihre Arbeit einbringt.

Es ist schwer, an einem Arbeitsplatz zu arbeiten, an dem du buchstäblich alles tun kannst. Besser ist es, einen Bereich zu wählen, Einfluss zu gewinnen und dort erfolgreich zu sein. Widme deine Zeit ganz der Lösung einiger Probleme. Wenn du dazu bereit bist, kannst du dann in einen anderen Bereich wechseln.

Ein zu enger Geltungsbereich

Hüte dich auch davor, dich selbst zu sehr einzugrenzen. Ein häufiges Beispiel ist, dass ein angestellter Ingenieur Teil eines einzigen Teams ist, das einem Vorgesetzten unterstellt ist. Die Vorgesetzten mögen das vielleicht sehr - sie bekommen einen sehr erfahrenen Ingenieur, der einen großen Teil des Designs und der technischen Planung übernehmen kann und vielleicht als technischer Leiter oder Teamleiter für ein Projekt fungiert. Manche Ingenieure werden das auch lieben: Es bedeutet, dass du dich mit den Technologien und Problemen des Teams intensiv auseinandersetzen und alle Feinheiten verstehen kannst. Aber achte auf die Risiken, die ein zu enger Aufgabenbereich mit sich bringt:

Mangelnde Wirkung
Es ist möglich, deine gesamte Zeit auf etwas zu verwenden, das nicht das Fachwissen und den Fokus eines Ingenieurs benötigt. Wenn du dich für ein einzelnes Team oder eine Technologie entscheidest, sollte es sich um eine Kernkomponente, ein geschäftskritisches Team oder etwas anderes handeln, das für das Unternehmen sehr wichtig ist.
Opportunitätskosten
Die Fähigkeiten von Ingenieurinnen und Ingenieuren sind normalerweise sehr gefragt. Wenn du nur einem Team zugewiesen bist, kann es sein, dass du für die Lösung eines Problems an anderer Stelle in der Organisation nicht in Frage kommst oder dein Vorgesetzter nicht bereit ist, dich gehen zu lassen.
Andere Ingenieure in den Schatten stellen
Ein enger Aufgabenbereich kann bedeuten, dass es nicht genug Arbeit gibt, um dich zu beschäftigen, und dass du vielleicht weniger erfahrene Leute in den Schatten stellst und ihnen Lernmöglichkeiten wegnimmst. Wenn du immer Zeit hast, alle Fragen zu beantworten und alle kniffligen Probleme zu lösen, bekommt niemand anderes die Erfahrung, das zu tun.
Overengineering
Ein Ingenieur, der nicht beschäftigt ist, neigt dazu, sich selbst Arbeit zu machen. Wenn du eine völlig ausgereifte Lösung für ein einfaches Problem siehst, ist das oft die Arbeit eines Ingenieurs, der eigentlich für ein schwierigeres Problem zuständig sein sollte.

Einige technische Bereiche und Projekte sind so tiefgründig, dass ein Ingenieur seine ganze Karriere dort verbringen kann und ihm die Möglichkeiten nie ausgehen. Sei dir einfach darüber im Klaren, ob du dich in einem dieser Bereiche befindest.

Welche Form hat deine Rolle?

Solange man sich einig ist, dass deine Arbeit etwas bewirkt, solltest du sehr flexibel sein, wie du sie machst. Dazu gehört auch, dass du in gewissem Maße definierst, was deine Arbeit ist. Hier sind ein paar Fragen, die du dir stellen solltest:

Gehst du die Dinge eher in die Tiefe oder in die Breite?

Konzentrierst du dich lieber auf ein einziges Problem oder einen Technologiebereich? Oder neigst du eher dazu, dich auf mehrere Teams oder Technologien zu verteilen und dich nur auf ein einziges Problem zu konzentrieren, wenn es ohne dich nicht gelöst werden kann? Ob du dich auf die Tiefe oder auf die Breite konzentrierst, hängt stark von deiner Persönlichkeit und deinem Arbeitsstil ab.

Hier gibt es keine falsche Antwort, aber es wird dir leichter fallen und mehr Spaß machen, wenn deine Vorlieben mit deinem Aufgabenbereich übereinstimmen. Wenn du zum Beispiel die technische Ausrichtung deiner Organisation oder deines Unternehmens beeinflussen willst, wirst du dich zu Gelegenheiten hingezogen fühlen, die dir einen breiteren Überblick verschaffen. Du musst in den Räumen sein, in denen die Entscheidungen getroffen werden, und Probleme angehen, die viele Teams betreffen. Wenn du das versuchst, während du dich mit einem einzigen tiefgreifenden architektonischen Problem beschäftigst, hat niemand etwas davon. Wenn du hingegen ein Branchenexperte in einem bestimmten technischen Bereich werden willst, musst du dich auf einen bestimmten Bereich konzentrieren und die meiste Zeit dort verbringen.

Zu welcher der "vier Disziplinen" fühlst du dich hingezogen?

Yonatan Zunger, angesehener Ingenieur bei Twitter, beschreibt die vier Disziplinen, die man in jedem Job auf der Welt braucht:

Technische Kernkompetenzen
Codieren, Rechtsstreitigkeiten führen, Inhalte produzieren, kochen - was auch immer ein typischer Berufspraktiker in dieser Funktion macht
Produktmanagement
Herausfinden, was getan werden muss und warum, und eine Erzählung über diese Arbeit aufrechterhalten
Projektleitung
Die praktische Umsetzung des Ziels, die Beseitigung des Chaos, die Verfolgung der Aufgaben, das Erkennen von Blockaden und die Sicherstellung, dass sie gelöst werden
Personalmanagement
Eine Gruppe von Menschen in ein Team verwandeln, ihre Fähigkeiten und Karrieren fördern, sie betreuen und sich um ihre Probleme kümmern

Zunger stellt fest, dass die Mischung dieser Fähigkeiten umso weniger mit der Berufsbezeichnung übereinstimmt, je höher deine Ebene ist: "Je höher du aufsteigst, desto mehr wird erwartet, dass du alle diese vier Arten von Aufträgen leicht und fließend ausführen kannst und in allen Räumen funktionierst."

Jedes Team und jedes Projekt braucht alle vier dieser Fähigkeiten. Als Staff Engineer wirst du sie alle brauchen. Du musst aber nicht in allen von ihnen hervorragend sein. Wir alle haben unterschiedliche Begabungen und mögen oder meiden verschiedene Arten von Arbeit. Vielleicht ist dir schon klar, welche dir Spaß machen und welche du hoffentlich nie brauchen wirst. Wenn du dir nicht sicher bist, schlägt Zunger vor, jede Arbeit mit einem Freund zu besprechen und ihn zu bitten, deine emotionale Reaktion und Energie zu beobachten, während ihr darüber sprecht. Wenn es eine Aufgabe gibt, die du wirklich hasst, solltest du sicherstellen, dass du mit jemandem zusammenarbeitest, der diesen Teil der Arbeit gerne machen möchte. Egal, ob du dich für die Breite oder die Tiefe interessierst, mit den technischen Kernkompetenzen allein wird es dir schwer fallen, weiter zu wachsen.

Wie viel willst (oder musst) du codieren?

Wenn du hier "programmieren" sagst, kannst du gerne die technische Kernarbeit deiner bisherigen Laufbahn eintauschen. Diese Fähigkeiten haben dich wahrscheinlich dahin gebracht, wo du heute bist, und es kann unangenehm sein, wenn du das Gefühl hast, dass du einrostest oder veraltet bist. Manche Personalentwickler/innen stellen fest, dass sie zwar viel Code lesen oder überprüfen, aber nicht viel schreiben. Andere tragen wesentlich zu den Projekten bei und programmieren jeden Tag. Eine dritte Gruppe findet Gründe zu programmieren und übernimmt unkritische Projekte, die interessant oder lehrreich sind, aber das Projekt nicht verzögern.

Wenn du dich unruhig fühlst, wenn du nicht jeden Tag programmierst, solltest du sicherstellen, dass du nicht eine umfassende architektonische oder einflussreiche Aufgabe übernimmst, für die du einfach keine Zeit hast. Oder du solltest zumindest einen Plan haben, wie du diese Lust stillen kannst, damit du dich nicht in Programmieraufgaben stürzt und die größeren Probleme sich selbst überlässt.

Wie sieht es mit deiner verspäteten Belohnung aus?

Beim Programmieren gibt es angenehm schnelle Feedback-Zyklen: jeder erfolgreiche Kompilier- oder Testlauf sagt dir, wie es läuft. Das ist wie eine kleine Leistungsbeurteilung jeden Tag! Es kann entmutigend sein, sich einer Arbeit zuzuwenden, bei der es keine eingebauten Feedbackschleifen gibt, die dir sagen, ob du auf dem richtigen Weg bist.

Bei einem langfristigen oder organisationsübergreifenden Projekt oder bei einem Strategie- oder Kulturwandel kann es Monate - oder sogar noch länger - dauern, bis du ein klares Signal bekommst, ob das, was du tust, funktioniert. Wenn du bei einem Projekt mit längeren Feedback-Zyklen ängstlich und gestresst sein wirst, bitte einen Manager, dem du vertraust, dir regelmäßig und ehrlich zu sagen, wie es läuft. Wenn du das brauchst und es nicht hast, solltest du dir Projekte überlegen, die sich innerhalb eines kürzeren Zeitraums auszahlen.

Bleibst du mit einem Fuß auf dem Weg zum Manager?

Obwohl die meisten Staff Engineers keine direkten Untergebenen haben, gibt es einige, die das tun. Ein Tech Lead Manager (TLM), manchmal auch Team Lead genannt, ist eine Art Hybridfunktion, bei der der Staff Engineer der technische Leiter eines Teams ist und dieses Team auch leitet. Diese Aufgabe ist bekanntlich schwierig. Es kann schwierig sein, sowohl für die Menschen als auch für die technischen Ergebnisse verantwortlich zu sein, ohne das Gefühl zu haben, dass man bei dem einen oder dem anderen fehlschlägt. Es ist auch schwierig, Zeit zu finden, um in die Entwicklung von Fähigkeiten auf beiden Seiten zu investieren, und ich habe gehört, dass TLM-Leute beklagen, dass sie dadurch ihre Karriere nicht vorantreiben können.

Manche Leute übernehmen ein paar Jahre lang eine Führungsrolle und dann eine Rolle als Ingenieur/in, um ihre Fähigkeiten auf beiden Seiten aufrechtzuerhalten.10 In Kapitel 9 werden wir mehr über dieses "Pendel" und die TLM-Rollen erfahren.

Passt einer dieser Archetypen zu dir?

In seinem Artikel "Staff Archetypes" beschreibt Will Larson vier verschiedene Muster, die er bei der Besetzung von technischen Positionen beobachtet hat. Du kannst diese Archetypen nutzen, um die Art von Rolle zu definieren, die du hast oder gerne hättest:

Technik führt
Arbeite mit Managern zusammen, um die Ausführung eines oder mehrerer Teams zu leiten.
Architekten
Verantwortlich für die technische Leitung und Qualität in einem wichtigen Bereich.
Löser
Nimm dir ein schwieriges Problem nach dem anderen vor.
Rechte Hände
Füge einer Organisation Führungsbandbreite hinzu.

Wenn du dich in keinem dieser Archetypen wiederfindest oder deine Rolle sich mit mehr als einem von ihnen überschneidet, ist das in Ordnung! Diese Archetypen sollen keine Vorschriften machen; sie geben uns Konzepte an die Hand, mit denen wir beschreiben können, wie wir am liebsten arbeiten.

Was ist dein Hauptanliegen?

Wir haben also über deinen Aufgabenbereich und deine Berichtskette gesprochen: die groben Grenzen des Teils der Organisation, in dem du arbeitest, und deine Position innerhalb der Organisation. Wir haben uns auch mit deinen Fähigkeiten befasst: wie du gerne arbeitest und welche Fähigkeiten dich anziehen. Aber selbst wenn du das alles weißt und ein klares Bild von deiner Rolle hast, bleibt noch eine Frage: Woran wirst du arbeiten?

Je mehr Einfluss du gewinnst, desto mehr Leute wollen, dass du dich um die Dinge kümmerst. Jemand stellt ein Dokument mit bewährten Methoden für die Codeüberprüfung in deinem Unternehmen zusammen und möchte deine Meinung hören. Deine Gruppe stellt neue Mitarbeiter/innen ein und braucht Hilfe bei der Entscheidung, welche Bewerber/innen eingestellt werden sollen. Es gibt ein Projekt, das besser vorankommen würde, wenn es einen Mitarbeiter hätte, der sich um die Unterstützung der Geschäftsführung bemüht. Und das ist nur Montagmorgen. Was tust du?

In manchen Fällen hat dein Vorgesetzter oder jemand, dem er unterstellt ist, eine starke Meinung darüber, worauf du dich konzentrieren solltest, oder er hat dich sogar speziell für die Lösung eines bestimmten Problems eingestellt. Die meiste Zeit wirst du jedoch selbst entscheiden können, was am wichtigsten ist. Jedes Mal, wenn du entscheidest, woran du arbeiten willst, entscheidest du auch, was du nicht tun willst.

Was ist wichtig?

Wenn du zu Beginn deiner Karriere gute Arbeit bei etwas leistest, das sich als unnötig herausstellt, hast du trotzdem gute Arbeit geleistet. Als Ingenieur/in hat alles, was du tust, hohe Opportunitätskosten, also muss deine Arbeit wichtig sein .

Lass uns das mal kurz auspacken. "Deine Arbeit muss wichtig sein" bedeutet nicht, dass du nur an den ausgefallensten, glamourösesten Technologien und vom Vizepräsidenten gesponserten Initiativen arbeiten solltest. Die Arbeit, die am wichtigsten ist, ist oft die Arbeit, die sonst niemand sieht. Vielleicht fällt es dir schwer, die Notwendigkeit dieser Arbeit zu formulieren, weil deine Teams noch keine guten mentalen Modelle dafür haben. Vielleicht müssen Daten gesammelt werden, die nicht existieren, oder man muss sich durch verstaubten Code oder Dokumente wühlen, die seit einem Jahrzehnt nicht mehr angefasst wurden. Es gibt viele andere schmutzige Aufgaben, die einfach erledigt werden müssen. Sinnvolle Arbeit gibt es in vielen Formen.

Wisse, warum das Problem, an dem du arbeitest, strategisch wichtig ist - und wenn es das nicht ist, mach etwas anderes.

Was brauchst du?

Ähnlich verhält es sich, wenn sich eine erfahrene Person einem Programmierprojekt widmet, das auch ein Ingenieur der mittleren Ebene hätte übernehmen können: Du wirst zwar hervorragende Arbeit leisten, aber wahrscheinlich gibt es ein Problem von der Größe einer erfahrenen Person, das ein Ingenieur der mittleren Ebene nicht bewältigen könnte. Um es mit einer Redewendung zu sagen, die mein Kind eines Tages fallen ließ: "Du pflanzt kein Gras in dein einziges Fass."

Sei vorsichtig, wenn du ein Projekt auswählst, an dem bereits viele erfahrene Leute beteiligt sind. Erkundige dich, wer sonst noch an dem Problem arbeitet und ob es wahrscheinlich ist, dass sie das Problem erfolgreich lösen können. Manche Projekte können sogar dadurch verlangsamt werden, dass ein zusätzlicher Leiter hinzukommt.11 Wenn es mehr Leute gibt, die als weise Stimme der Vernunft auftreten, als Leute, die tatsächlich Code tippen (oder was auch immer das Äquivalent für dein Projekt ist), solltest du dich nicht einmischen. Suche dir ein Problem aus, das dich wirklich braucht und das von deiner Aufmerksamkeit profitieren wird. In Kapitel 4 erfährst du, wie du entscheiden kannst, welche Projekte du in Angriff nehmen willst.

Angleichung an Umfang, Form und Hauptschwerpunkt

Inzwischen solltest du ein ziemlich klares Bild davon haben, was der Umfang von ist, wie deine Rolle aussieht und woran du gerade arbeitest. Aber bist du dir auch sicher, dass dein Bild mit dem der anderen übereinstimmt? Die Erwartungen deines Vorgesetzten und deiner Kollegen können sich stark von deinen Vorstellungen darüber unterscheiden, was ein/e Ingenieur/in ist, welche Entscheidungsbefugnis du hast und unzählige andere wichtige Fragen. Wenn du als Ingenieurin oder Ingenieur in einem Unternehmen anfängst, ist es am besten, wenn du all diese Fragen im Voraus klärst.

Eine Technik, die ich von meinem Freund Cian Synnott gelernt habe, besteht darin, mein Verständnis von meiner Arbeit aufzuschreiben und es mit meinem Vorgesetzten zu teilen. Es kann sich etwas einschüchternd anfühlen, die Frage "Was machst du hier?" zu beantworten. Was ist, wenn andere Leute denken, dass deine Arbeit nutzlos ist oder dass du sie nicht gut machst? Aber wenn du es aufschreibst, wird die Unklarheit beseitigt und du wirst schnell herausfinden, ob dein mentales Modell der Rolle mit dem der anderen übereinstimmt. Besser jetzt als bei der Leistungsbeurteilung.

So könnte eine solche Rollenbeschreibung für Ali aussehen, einen breit angelegten Architekten, der bei einem großen, teamübergreifenden Projekt mitarbeitet (aber nicht leitet).

Sei nicht besessen davon, es perfekt zu machen: Mach es richtig genug. Wenn du deine Ziele beschreibst, heißt das nicht, dass es dir verboten ist, etwas anderes zu tun. Aber es ist eine gute Erinnerung an das, was du vorhast, und es hilft dir dabei, im Auge zu behalten, ob du tatsächlich das tust, was du als deine Aufgabe angegeben hast.

Du könntest früher als erwartet feststellen, dass sich dein Fokus ändern muss. Der Zustand der Welt kann sich ändern oder deine Prioritäten könnten sich verschieben. Wenn das der Fall ist, schreibe eine neue Rollenbeschreibung mit den neuen Informationen. Wenn du deine Erwartungen an dich selbst klar formulierst, ist sichergestellt, dass alle auf derselben Seite stehen.

Ist das dein Job?

Deine Aufgabe ist es, dein Unternehmen erfolgreich zu machen. Du bist vielleicht ein Technologieexperte oder ein Programmierer oder gehörst zu einem bestimmten Team, aber letztendlich ist es deine Aufgabe, deinem Unternehmen zu helfen, seine Ziele zu erreichen. Leitende Angestellte tun viele Dinge, die nicht in ihrer eigentlichen Stellenbeschreibung stehen. Am Ende können sie Dinge tun, die in keiner Stellenbeschreibung stehen! Aber wenn es das ist, was das Projekt braucht, um erfolgreich zu sein, solltest du es tun.

Einige meiner Kollegen bei Squarespace erzählen die Geschichte von dem Tag im Jahr 2012, als ihr Rechenzentrum einen Stromausfall hatte und sie Treibstoff 17 Stockwerke hinauftragen mussten, um es online zu halten. "Fässer mit Diesel schleppen" steht nicht in den meisten Stellenbeschreibungen für Techniker/innen, aber genau das war nötig, um die Website online zu halten (und es hat funktioniert!). Als der Maschinenraum des ISP, bei dem ich vor Jahren gearbeitet habe, überflutet wurde, musste ich eine Eimerkette aus Mülltonnen bilden, um den Wasserstand niedrig zu halten. Und als ein Google-Projekt 2005 in Verzug geriet und wir nicht genügend Hardware-Leute zur Verfügung hatten, bestand mein Job für ein paar Tage darin, Server in einem Rechenzentrum in San Jose zu rüsten. Du tust, was du tun musst, um das Projekt zu verwirklichen.

Normalerweise ist diese "nicht mein Job"-Arbeit natürlich weniger dramatisch. Es kann bedeuten, dass du ein Dutzend Gespräche führst, um ein Projekt freizugeben, von dem dein Team abhängt, oder dass du feststellst, dass dein neuer Ingenieur sich verlaufen hat und dich bei ihm meldest. Um es noch einmal zu sagen: Dein Job ist letztendlich das, was deine Organisation oder dein Unternehmen braucht. Im nächsten Kapitel werde ich darüber sprechen, wie du diese Bedürfnisse erkennen kannst.

Zur Rekapitulation

  • Die Rolle des technischen Personals ist per Definition mehrdeutig. Es liegt an dir, herauszufinden und zu entscheiden, was deine Rolle ist und was sie für dich bedeutet.

  • Du bist wahrscheinlich kein Manager, aber du hast eine Führungsrolle inne.

  • Außerdem bist du in einer Rolle, die technisches Urteilsvermögen und solide technische Erfahrung erfordert.

  • Sei dir über deinen Aufgabenbereich im Klaren: deinen Verantwortungsbereich und deinen Einfluss.

  • Deine Zeit ist begrenzt. Entscheide dich bewusst für einen Schwerpunkt, der wichtig ist und der deine Fähigkeiten nicht vergeudet.

  • Stimme dich mit deiner Führungskraft ab. Besprich, was du von deiner Arbeit hältst, sieh dir an, was dein Vorgesetzter davon hält, verstehe, was geschätzt wird und was tatsächlich nützlich ist, und lege die Erwartungen ausdrücklich fest. Nicht alle Unternehmen brauchen alle Arten von Personalingenieuren.

  • Dein Job wird manchmal eine seltsame Form haben, und das ist okay.

1 Ich empfehle auch progression.fyi, die eine umfangreiche Sammlung von Leitern hat, die von verschiedenen Tech-Unternehmen veröffentlicht wurden.

2 Ein Unternehmen, von dem ich hörte, verwendete die Stufen "Senior", "Staff" und "Principal" in dieser Reihenfolge, wurde aber von einem anderen Unternehmen übernommen, das "Senior", "Principal" und "Staff" verwendete. Chaos. Das übernehmende Unternehmen änderte alle "Mitarbeiter" in "Direktor" und alle "Direktoren" in "Mitarbeiter", und niemand war glücklich. Sowohl die Mitarbeiter/innen als auch die Schulleiter/innen empfanden die Änderung als Degradierung. Titel sind wichtig!

3 Mir gefällt die Definition meines Freundes Tiarnán de Burca für Senior Engineer: die Stufe, auf der jemand aufhören kann, sich weiterzuentwickeln und sein aktuelles Produktivitäts-, Fähigkeits- und Leistungsniveau für den Rest seiner Karriere beibehalten kann, ohne dass es "bedauerlich" ist, wenn er geht.

4 Was haben sie sich dabei gedacht? War es wirklich das, was sie vorhatten? Natürlich werden künftige Teams das Gleiche von uns verlangen.

5 Hillel Wayne weist in seinem Essay "We Are Not Special" darauf hin, dass viele technische Lösungen, die früher eine sorgfältige Abstimmung der physischen Ausrüstung erforderten, heute mit einem "Software-Kniff" durchgeführt werden. Ich bin wirklich immer wieder überrascht, dass wir bisher so wenige schwere tödliche Unfälle durch Software hatten. Ich würde mich nicht darauf verlassen wollen, dass wir weiterhin Glück haben.

6 Aus diesem Grund bin ich kein Fan davon, erfahrenen Ingenieuren ein Vorstellungsgespräch zu geben. Wenn du es bis zu dieser Stufe geschafft hast, kannst du entweder gut programmieren oder hast gelernt, technische Probleme mit deinen anderen Muskeln zu lösen. Was zählt, sind die Ergebnisse.

7 Ich empfehle den Artikel von Lara Hogan über den Aufbau eines "Manager-Voltron".

8 Wenn Besprechungen auf Zwischenebene in deinem Unternehmen nicht üblich sind, musst du vielleicht klarstellen, dass du deinen Vorgesetzten nicht untergraben oder ihm "Bericht erstatten" willst; du willst die Prioritäten der größeren Gruppe verstehen und die Verbindungen herstellen, die dir helfen, den größten Einfluss zu haben. Im Idealfall versteht dein Vorgesetzter den Wert von Meetings auf Übersprungsebene und hilft dir, sie einzurichten.

9 Eine Nebenquest ist ein Teil eines Videospiels, der nichts mit der Hauptmission zu tun hat, den du aber optional für Münzen oder Erfahrungspunkte oder einfach zum Spaß erledigen kannst. Stell dir vor: "Ich wollte mich gerade in die schwer bewachte Festung kämpfen, um den Dämon zu besiegen, der das Land terrorisiert, aber natürlich kann ich vorher noch deine Katze suchen."

10 Charity Majors' "The Engineer/Manager Pendulum" ist ein ausgezeichneter Artikel zu diesem Thema.

11 Du wirst Brooks' Gesetz zitiert hören: "Ein Softwareprojekt, das zu spät kommt, wird durch zusätzliche Arbeitskräfte noch später." Brooks selbst nannte dies zwar eine "unerhörte Vereinfachung", aber es ist etwas Wahres dran. Siehe The Mythical Man-Month von Fred Brooks (Addison-Wesley).

Get Der Weg des Personalingenieurs now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.

Start your free trial