--- title: "Vom Entwickler zum Lead: Ein Berufswechsel, keine Beförderung" description: "Wer Lead wird, verliert zuerst das Gefühl, produktiv zu sein. Das ist kein Fehler, sondern der neue Job. Was ich loslassen würde, woran sich Wirkung stattdessen zeigt und welche Messungen in die Falle führen." author: Nils Plagemann date: 2026-10-23 topic: "Führung" tags: ["fuehrung","rollenwechsel"] url: https://plagemann.dev/blog/vom-entwickler-zum-lead/ license: "Text CC BY-SA 4.0, Code-Beispiele MIT" --- # Vom Entwickler zum Lead: Ein Berufswechsel, keine Beförderung Wer Lead wird, verliert zuerst das Gefühl, produktiv zu sein. Das ist kein Fehler, sondern der neue Job. Was ich loslassen würde, woran sich Wirkung stattdessen zeigt und welche Messungen in die Falle führen. Befördert wird meist, wer im Team am meisten liefert. Im neuen Job hilft genau diese Stärke wenig, und sie schadet, sobald man sie weiter ausspielt. Wer Lead wird, verliert als Erstes das Gefühl, produktiv zu sein. Das ist kein Zeichen, dass etwas schiefläuft. Es ist der neue Job. Ich halte den Wechsel zum Lead deshalb nicht für einen Aufstieg im selben Beruf, sondern für einen Berufswechsel. Loslassen muss man nicht die Technik, sondern die Lieferung: den eigenen Code auf dem kritischen Pfad, die Rolle als Wissensinsel, den eigenen Geschmack als Qualitätsgrenze und die Bestätigung durch den grünen Build. Wirkung misst man am Team, und das aussagekräftigste Maß dafür sind die Wartezeiten, die man selbst verursacht. Ich bin selbst aus dem eigenen Team heraus Lead geworden, und am Anfang war das fehlende Gefühl von Produktivität auch mein Problem: Die klassischen Produktivitätsmaße, an denen ich mich als Entwickler gemessen hatte, griffen nicht mehr. Das letzte Ticket auf dem kritischen Pfad, das ich selbst gezogen habe, liegt ein paar Monate zurück. ## Der Maßstab wechselt, nicht nur die Aufgabe Die sauberste Evidenz dafür stammt aus dem Vertrieb. Alan Benson, Danielle Li und Kelly Shue haben Daten zu 38.843 Vertriebsleuten aus 131 US-Firmen ausgewertet. Wer doppelt so viel verkaufte wie vergleichbare Kollegen, hatte eine um 32 % höhere Chance auf Beförderung. Unter solchen Managern sank der Umsatz jedes Unterstellten um 6,1 %. Gute Manager ließen sich eher an ihrer Erfahrung in Zusammenarbeit erkennen. Die Autoren fassen es in einem Satz: „The best worker is not always the best candidate for manager.“ Auf Entwickler übertragen ist das eine Analogie, denn im Vertrieb lässt sich Leistung in Umsatz zählen. Charity Majors hat es 2017 aus der Praxis auf eine Formel gebracht: „Management is not a promotion, management is a change of profession.“ Und gleich danach: „And you will be bad at it for a long time after you start doing it.“ Linda Hill von der Harvard Business School hat 19 neue Manager durch ihr erstes Jahr begleitet. Früher hing ihr Erfolg an der eigenen Expertise, jetzt daran, für eine Gruppe eine Agenda zu setzen, und neue Maßstäbe entstehen erst nach und nach. In ihren Interviews fragen sich neue Manager: „Who am I becoming?“ Man lernt keine neue Fertigkeit, man tauscht den Maßstab, an dem man sich misst. Was Entwickler von diesem Tausch erwarten, zeigt eine Studie bei Microsoft mit 37 Interviews und 563 Umfrageantworten. Unter 15 Eigenschaften großartiger Engineering Manager kam „Is technical“ auf Platz 14, vorn lagen ein positives Arbeitsumfeld, Talente entwickeln und Autonomie ermöglichen. Ein guter Engineering Manager braucht danach „a sufficient level of technical knowledge—not excellence“, die technischen Entscheidungen treffen die Entwickler. Gemessen wurde allerdings, was die Befragten für wichtig halten, nicht, was wirkt. Im deutschen Teamleiter-Modell ist der Berufswechsel schwerer zu erkennen. Wer fachlich und disziplinarisch führt, bekommt meist Titel, Gehaltsstufe und Personalverantwortung, das fühlt sich an wie eine Beförderung. Nicht selten steht der Lead zudem mit einem Anteil in der Sprintkapazität, und sein eigener Vorgesetzter misst ihn weiter an der Lieferung. Das sollte man offen verhandeln, statt still dagegen zu arbeiten, und die [Wartezeit, die man selbst verursacht](https://plagemann.dev/blog/vom-entwickler-zum-lead/#wartezeiten), ist dafür ein brauchbares Argument. Ich habe meine Stelle schrittweise gemeinsam mit meinem Vorgesetzten umgestellt, statt über Nacht die Rolle zu wechseln. Organisatorisch hat mir beim Wechsel deshalb kaum etwas gefehlt. Ich führe selbst ein Team in dieser Doppelrolle und halte sie für die heikelste Konstellation, weil die fachliche Hälfte jederzeit einen legitimen Grund liefert, das schwerste Ticket doch selbst zu ziehen. ## Was man loslässt Konkret sind es sechs Dinge, die sich ein guter Entwickler über Jahre erarbeitet hat und die im neuen Job gegen ihn arbeiten. | Was man loslässt | Was es im Lead-Job anrichtet | Was an seine Stelle tritt | |---|---|---| | den eigenen Code und die Rolle als Wissensinsel | wer als Einziger ein Modul versteht, wird zum Engpass | Wissen über Reviews, Pairing und Doku verteilen | | die schwersten Tickets | das Team verliert die Aufgaben, an denen es wachsen würde | schwere Aufgaben bewusst vergeben und begleiten | | jedes Review | jede Änderung wartet auf eine Person | Reviews als Lehrzeit, verteilt aufs Team | | den eigenen Geschmack als Qualitätsmaßstab | jede Lösung wird an der eigenen gemessen, Reviews werden zu Nacharbeit | harte Regeln in Build und Analyzern, der Rest ist Ermessen des Teams | | die Architektur im eigenen Kopf | Entscheidungen hängen an der Verfügbarkeit einer Person, ihr Grund geht verloren | Entscheidungen kurz aufschreiben, im Repo, mit Begründung | | das Gefühl, produktiv zu sein | man sucht Arbeit, die sich nach Fortschritt anfühlt, statt Arbeit mit Hebel | Maßstäbe, die am Team hängen | Am schwersten fallen die schwersten Tickets, denn mit ihnen hat man sich den Ruf erarbeitet. Majors ist unmissverständlich: „It is your job to *choose* to hand off the challenging assignments, so that your engineers can get better at engineering.“ Andy Grove, lange Chef von Intel, nennt Einmischung („meddling“) ausdrücklich negativen Hebel. Der Vorgesetzte zieht mit überlegenem Wissen eine Lage an sich, statt den Mitarbeiter sie selbst durcharbeiten zu lassen. Kurzfristig entsteht ein Ergebnis, langfristig ein Team, das wartet. Beim eigenen Code ist nicht der Code das Problem, sondern dass nur man selbst ihn versteht. In 65 % von 133 populären GitHub-Projekten liegt der Bus-Faktor (bei Avelino u. a.: Truck Factor) bei höchstens zwei: Fallen zwei Leute weg, steht das Projekt. Als Lead bleibt man so eine Insel, nur mit weniger Zeit für Fragen. Schwerer zu sehen ist der eigene Geschmack. Wer lange für die schwierigen Probleme gefragt wurde, hält die eigene Lösung leicht für den Maßstab, und jedes Review wird zur Nacharbeit. Zwei meiner Grundsätze setzen dagegen: „Grenzen gehören in den Build“ und „Qualität skaliert über Eindeutigkeit“. Was wirklich gelten soll, gehört als Regel in Build, Analyzer oder Architekturtest, eindeutig für alle. Was dort nicht steht, entscheidet das Team, auch wenn der Lead es anders gemacht hätte. Die unsichtbarste Insel ist die Architektur im eigenen Kopf. Solange nur der Lead weiß, warum ein Modul so geschnitten ist, landet jede Folgeentscheidung bei ihm. Entscheidungen schreibt man deshalb auf, kurz, verlinkt, im Repo, und der Grund zählt mehr als das Ergebnis. Ein Register, in dem nur die Entscheidungen des Leads stehen, hat allerdings nur den Kopf ausgelagert, nicht das Entscheiden. Bei uns führen deshalb die Dev-Teams die Entscheidungsregister selbst. Bislang landen dort leider noch zu wenige Entscheidungen. ## Der neue Job belohnt später Loslassen wäre leicht, wenn der neue Job so belohnen würde wie der alte. Als Entwickler bekommt man Rückmeldung in Minuten: Der Test wird grün, das Ticket wandert nach rechts. Als Lead dauert sie Wochen oder Monate, denn ob jemand an einer Aufgabe gewachsen ist, zeigt sich spät. Grove beschreibt einen Fall, in dem zwischen der Arbeit eines Managers und dem Output seiner Organisation „just about a year“ lag. Lara Hogan, früher Engineering Director bei Etsy, bringt es auf den Punkt: „Unlike in my role as an individual contributor, there’s no launch party for a reorg.“ Gefährlich wird die Lücke durch das, womit man sie füllt. Will Larson übernimmt dafür einen Begriff von Hunter Walk: „snacking“, leichte Arbeit mit wenig Wirkung. Für einen Lead, der programmieren kann, ist das schnelle Ticket der naheliegende Snack. Es liefert das Erfolgsgefühl, das der Rest des Tages schuldig bleibt, und nimmt dem Team eine Aufgabe, an der es gewachsen wäre. In der Microsoft-Studie berichteten Manager, die weiter technisch lieferten, von Erschöpfung und Burnout, und sahen selbst, dass ihre Entwickler dadurch weniger wachsen konnten. Wer aus dem eigenen Team heraus Lead wird, hat es doppelt schwer. Die früheren Kollegen erwarten oft weiter, dass er die schweren Bugs löst, und Stakeholder fragen weiter direkt bei ihm an. Das Loslassen muss man deshalb ansagen, dem Team wie den Stakeholdern, und bei jeder Anfrage wiederholen: Fragt nicht mich, fragt die, die es jetzt verantwortet. Sonst holt einen die alte Rolle über den Chat zurück. ## Woran sich Wirkung zeigt Produktiv bin ich auch heute noch. Nur zähle ich das nicht mehr in Codezeilen, sondern in Problemen, die meine Mitarbeiter gelöst haben. Grove definiert den Output eines Managers als den Output seiner Organisation plus den der benachbarten Organisationen, auf die er Einfluss hat. Die zweite Hälfte wird gern weggelassen. Für einen Lead, der auch Architektur und Engineering-Standards verantwortet, ist sie zentral, denn seine Standards tragen oder bremsen andere Teams mit. Team-Output allein ist allerdings ein schlechter Tacho. Er läuft nach, und hinter ihm kann man sich verstecken. Aussagekräftiger finde ich vier Größen, die näher am eigenen Handeln liegen. | Messgröße | Woran man sie abliest | Grenze | |---|---|---| | Entscheidungen ohne mich | Einträge in einem Entscheidungsregister, die andere geschrieben und vertreten haben | sagt nichts über ihre Qualität | | Bus-Faktor | Module und Themen, zu denen nur eine Person Auskunft geben kann, vor allem wenn ich es bin | grobe Zählung, kein exakter Wert | | Wachstum der Leute | wer heute übernimmt, was vor einem halben Jahr nur ich konnte | nur im Gespräch zu erheben, nicht aus Werkzeugen | | Wartezeit, die ich verursache | wie lange Pull Requests, Entwürfe und Fragen auf meine Antwort oder Freigabe warten | belohnt schnelles Freigeben, auch wenn es schlecht ist | Die erste Zeile folgt einem Maßstab, den Larson für Staff Engineers formuliert hat: Die Organisation profitiert zunehmend von den eigenen Beiträgen, hängt aber nicht mehr von ihnen ab („increasingly benefits from, but doesn’t rely upon, your contributions“). Für die dritte Zeile taugt seine Frage an jede kritische Aufgabe: „Who could be both successful with and grown by this work?“ Die Antwort steht nicht im Werkzeug, sondern im Gespräch, und in einem verteilten Team nur, wenn es regelmäßig stattfindet. ### Die ehrlichste Zahl: eigene Wartezeiten Die Wartezeit, die ich verursache, halte ich für das aussagekräftigste der vier Maße, weil ich sie am direktesten beeinflusse. Eine Freigabe, die an einer Person hängt, ist eine Warteschlange mit einem einzigen Schalter. DORA fand für schwere, externe Freigaben von Produktionsänderungen keinen Beleg, dass sie Fehler verhindern, wohl aber, dass sie die Auslieferung bremsen. Das gilt auch für gut gedachte Regeln. Gibt die Teamleitung schwer revidierbare Architekturentscheidungen frei, steht in keiner Prozessbeschreibung, ob sie dabei Enabler ist oder Nadelöhr. Das steht in der Zeit, die solche Pull Requests auf ihre Freigabe warten. Bei mir sind es im Schnitt zwei Tage. Anders als jede Teamkennzahl kann ich diese Zahl allein senken. ## Messungen, die in die Falle führen Die naheliegendste Falle sind die eigenen Commits. Wer als Lead zählt, wie viel er selbst geschafft hat, misst den alten Job. Eine Woche mit vielen eigenen Commits ist für mich deshalb kein gutes Zeichen, sondern eine Frage: Wer hätte das machen können, und was ist in der Zeit liegen geblieben? Die zweite Falle sind individuelle Aktivitätsmetriken wie Pull Requests, Commits oder Reviews pro Person. Das SPACE-Framework von Nicole Forsgren und Kollegen sagt, sie „should never be used in isolation either to reward or to penalize developers“. Die Autoren raten, nur anonymisierte, aggregierte Ergebnisse auf Team- oder Gruppenebene zu berichten, und merken an: „In some countries, reporting on individual productivity isn’t legal.“ SPACE ist ein Konzeptpapier, keine Wirkungsstudie. Bemerkenswert ist, dass die Warnung überwiegend von Leuten bei GitHub und Microsoft kommt, also von Anbietern genau solcher Werkzeuge. In Deutschland kommt hinzu: Ein Dashboard, das Durchlaufzeiten oder Reviews einzelnen Personen zuordnet, ist schnell eine technische Einrichtung, bei der ein Betriebsrat nach § 87 Abs. 1 Nr. 6 BetrVG mitbestimmt, und jede personenbezogene Auswertung braucht nach der DSGVO eine Rechtsgrundlage. Die dritte Falle ist jede Zahl, die zum Ziel wird. Marilyn Strathern hat Goodharts Gesetz 1997 so zugespitzt: „When a measure becomes a target, it ceases to be a good measure.“ Kent Beck und Gergely Orosz beschreiben ein Beispiel von Facebook. Eine Entwicklerumfrage war dort zunächst nützlich. Dann wurde daraus ein Gesamtwert, der Wert tauchte in Leistungsbeurteilungen auf und wurde schließlich zum Ziel, das Directors bei ihren Managern einforderten. Am Ende verhandelten Manager mit einzelnen Entwicklern über bessere Bewertungen. Das gilt auch für meine eigenen Maße. Wird der Anteil der Entscheidungen ohne mich zum Ziel, schreibt das Team eben mehr kleine Einträge ins Register. ### Und die Einzelbeurteilung? Hier wird das deutsche Teamleiter-Modell unbequem. Wer disziplinarisch führt, beurteilt Einzelne, redet über Gehalt und führt im Zweifel das Gespräch über Minderleistung. „Wir messen nur das Team“ ist dann ein Ausweichen. Lösbar ist das, aber nicht mit Zahlen aus dem Werkzeug. Beurteilung braucht Beobachtungen, die man zeitnah mit der Person bespricht und so festhält, dass sie sie kennt, bevor irgendetwas in einem Bogen landet. Dazu gehören die Sicht der Person selbst und die ihrer Kollegen. SPACE lässt eine Tür offen: Einzelauswertungen können Entwicklern selbst helfen, wenn sie sich dafür entscheiden. Die Grenze verläuft also nicht zwischen Messen und Nicht-Messen, sondern bei der Frage, wem die Zahlen gehören. In die Beurteilung gehört auch, was kein Dashboard zeigt. Tanya Reilly nennt es Glue Work: Neue einarbeiten, bemerken, wenn jemand blockiert ist, in Designdokumenten nachfragen, was übergangen wird. Sie warnt: „Left unconscious, it can be career limiting.“ Wer als Lead Glue Work verteilt oder stillschweigend bei denselben Leuten liegen lässt, muss sie in der Beurteilung auch sehen. Ich versuche, Leuten, die viel Glue Work machen, nach einer Weile Aufgaben zu geben, die sie mehr erfüllen, und die Glue Work selbst abzuschaffen, statt sie nur weiterzureichen. ## Technisch bleiben, ohne Nadelöhr zu werden Die Fähigkeit behalten, Dinge zu verstehen und zu beurteilen, und die Lieferung abgeben: So lese ich den stärksten Einwand gegen zu viel Loslassen. Benjamin Artz, Amanda Goodall und Andrew Oswald fanden in Umfragedaten aus den USA und Großbritannien, dass die technische Kompetenz des direkten Vorgesetzten der stärkste einzelne Prädiktor für Arbeitszufriedenheit ist. Die Zufriedenheit ist selbstberichtet, und wer seinen Chef mag, hält ihn womöglich auch für kompetent. Trotzdem: Wer einen Entwurf nicht mehr beurteilen kann, verliert das Team. Wer ihn selbst umsetzt, nimmt dem Team die Arbeit weg, an der es lernt. Praktisch heißt das: programmieren ja, aber nicht dort, wo das Team auf einen wartet. Pat Kua rät Tech Leads schon 2014, keine Aufgaben auf dem kritischen Pfad zu übernehmen, weil sie ständig unterbrochen werden. Will Larson hielt als Manager von Managern jede Stunde eigenes Programmieren für „a sign of questionable judgment“. Als CTO mit rund 50 Entwicklern hat er 2025 mit KI-Werkzeugen wieder über hundert Pull Requests in gut sechs Monaten gemergt, mit einer festen Regel: „Never contribute to something that is truly time sensitive unless it’s a very constrained thing that I can solve end-to-end *today*.“ KI-Werkzeuge ändern, wie viel ein Lead nebenher programmieren kann. Was er programmieren sollte, ändern sie nicht. Was übrig bleibt, ist mehr, als man denkt: Prototypen, die eine Entscheidung vorbereiten, liegengebliebene Aufgaben mit klarem Wert, das Build-Skript, über das alle stolpern. Und Reviews, allerdings anders als vorher. In einer Fallstudie bei Google nennen Entwickler vier Erwartungen an Code Reviews, darunter „education“. Review soll dort auch sicherstellen, dass mehr als eine Person jedes Stück Code kennt. Das stützt meinen Grundsatz, dass Reviews Lehrzeit sind. Es heißt aber nicht, dass der Lead jedes Review macht. Grove nennt den Hebel eines Managers hoch, wenn er Wissen an eine Gruppe weitergibt. Ein Review, das nur der Lead prüft, lehrt eine Person und hält alle anderen auf. Eines, das er gemeinsam mit einem zweiten Reviewer macht und danach abgibt, verteilt Wissen. Dazu kommt eine nüchterne Rechnung. Grove hält für eine überwiegend führende Rolle sechs bis acht Mitarbeiter für richtig und zehn für zu viele, und er setzt etwa einen halben Tag pro Woche und Person an. Larson landet ebenfalls bei sechs bis acht, wer mehr als acht oder neun betreut, werde zu „a coach and a safety net“, beides Erfahrungswerte. Bei mir berichten alle 14 direkt, und ich verantworte zugleich Architektur. Groves halber Tag ergäbe sieben Arbeitstage pro Woche, bevor die erste Architekturentscheidung gefallen ist. Für das schwerste Ticket ist in dieser Rechnung kein Platz. Sie ist weniger ein Appell an die Disziplin als ein Argument, fachliche Führung auf mehrere Schultern zu verteilen. Bei mir nehmen zwei Seniors einen Teil der fachlichen Arbeit ab. ## Der Weg zurück ist kein Scheitern Nicht jeder Lead sollte Lead bleiben. Majors beschreibt das „Engineer/Manager Pendulum“, den bewussten Wechsel zwischen beiden Berufen. Die besten Führungskräfte der ersten Ebene seien nie mehr als zwei bis drei Jahre von der praktischen Arbeit entfernt. 2022 legte sie nach: „After two or three years of management, it’s still pretty easy to go back to engineering. After five years, it gets progressively harder.“ Im selben Text rät sie, den ersten Führungsjob zwei Jahre durchzuhalten, denn so lange dauere es, bis man beurteilen kann, ob man ihn gut macht. In Deutschland ist der Rückweg nach meiner Einschätzung schwerer als in der US-Tech-Szene, aus der Majors schreibt, weil der Hinweg als Beförderung galt. Wer zurückgeht, verliert den Titel, womöglich Gehalt, und das Umfeld liest es leicht als Scheitern. Doppelte Karriereleitern helfen nur, wenn sie ernst gemeint sind und die Fachlaufbahn nicht als Abstellgleis gilt. Bei meinem Arbeitgeber gibt es keine Fachlaufbahn, die der Führungslaufbahn gleichwertig wäre. Legitim ist der Weg zurück für mich, wenn die Maßstäbe des neuen Berufs dauerhaft nichts geben, nicht nach dem ersten schweren Quartal. Hills Befund, dass die neue Identität langsam entsteht, spricht gegen ein zu frühes Urteil, Majors’ Beobachtung, dass der Rückweg nach fünf Jahren zunehmend schwerer wird, gegen ein zu spätes. ## Loslassen, überprüfbar Loslassen ist kein Vorsatz, sondern eine Reihe von Entscheidungen, die man überprüfen kann. So gehe ich es an, manches davon noch als Vorhaben. Ich führe eine Liste aller wiederkehrenden Aufgaben, die bei mir landen, vom Review bis zur Freigabe, und stelle zu jeder Larsons Frage, wer daran erfolgreich sein und wachsen könnte. Als Nächstes würde ich in einem Entscheidungsregister für jede Art Entscheidung festhalten, ob ich entscheide, mitrede oder nur informiert werde. Dazu gehört Groves Warnung: „delegation without follow-through is abdication“. Abgeben heißt nachhalten, nicht wegsehen. Dann würde ich messen, wie lange Arbeit auf mich wartet: Pull Requests, in denen ich Pflicht-Reviewer bin, Entwürfe vor meiner Freigabe, offene Fragen. Pflicht-Reviewer würde ich nur dort bleiben, wo ein Risiko für andere es verlangt, und programmieren nur dort, wo niemand auf mich wartet. Am Ende jedes Quartals bewerte ich, wie es gelaufen ist. Zwei Fragen zählen dabei für mich: Welche Entscheidung ist ohne mich gefallen, die vor einem halben Jahr noch über meinen Tisch gegangen wäre? Und wer kann heute etwas, das damals nur ich konnte? Fällt mir keine Antwort ein, habe ich nichts losgelassen, egal wie voll der Kalender war. Und es braucht einen Termin. Ich bin seit einem Dreivierteljahr Lead, nach Majors’ Rat ist die ehrliche Prüfung also in gut einem Jahr fällig: ob mir die neuen Maßstäbe etwas geben. Wenn nicht, ist der Weg zurück kein Scheitern, solange er noch offen ist. Wenn doch, bleibt ein letzter Test. Bin ich nach zwei Jahren noch immer der, ohne den im Code nichts geht, ist das kein Verdienst, sondern ein Befund. ## Quellen 1. Alan Benson, Danielle Li, Kelly Shue, [Promotions and the Peter Principle](http://danielle.li/assets/docs/PromotionsAndThePeterPrinciple.pdf), The Quarterly Journal of Economics 134(4), 2019. 2. Charity Majors, [The Engineer/Manager Pendulum](https://charity.wtf/2017/05/11/the-engineer-manager-pendulum/), 2017, und [Twin Anxieties of the Engineer/Manager Pendulum](https://charity.wtf/2022/03/24/twin-anxieties-of-the-engineer-manager-pendulum/), 2022. 3. Linda A. Hill, [Becoming the Boss](https://hbr.org/2007/01/becoming-the-boss), Harvard Business Review, 2007. 4. Eirini Kalliamvakou, Christian Bird, Thomas Zimmermann, Andrew Begel, Robert DeLine, Daniel M. German, [What Makes a Great Manager of Software Engineers?](https://www.microsoft.com/en-us/research/wp-content/uploads/2018/06/kalliamvakou-tse-2018.pdf), IEEE Transactions on Software Engineering 45(1), 2019 (Autorenfassung). 5. Andrew S. Grove, *High Output Management*, Random House, 1983. 6. Guilherme Avelino, Leonardo Passos, Andre Hora, Marco Tulio Valente, [A Novel Approach for Estimating Truck Factors](https://arxiv.org/abs/1604.06766), ICPC 2016. 7. Lara Hogan, [Your Brain on Progress](https://increment.com/reliability/brain-on-progress/), Increment 16, 2021. 8. Will Larson, [Work on what matters](https://lethain.com/work-on-what-matters/), 2020, [Create space for others](https://lethain.com/create-space-for-others/), 2020, [Sizing engineering teams](https://lethain.com/sizing-engineering-teams/), 2018, und [Coding at work (after a decade away)](https://lethain.com/coding-at-work/), 2025. 9. DORA, [Capabilities: Streamlining change approval](https://dora.dev/capabilities/streamlining-change-approval/), Stand 09/2026. 10. Nicole Forsgren, Margaret-Anne Storey, Chandra Maddila, Thomas Zimmermann, Brian Houck, Jenna Butler, [The SPACE of Developer Productivity](https://cacm.acm.org/magazines/2021/6/252825-the-space-of-developer-productivity/fulltext), Communications of the ACM 64(6), 2021. 11. § 87 BetrVG, [Mitbestimmungsrechte](https://www.gesetze-im-internet.de/betrvg/__87.html), Stand 09/2026. 12. Marilyn Strathern, *‘Improving ratings’: audit in the British University system*, European Review 5(3), 1997. 13. Kent Beck, Gergely Orosz, [Measuring developer productivity? A response to McKinsey](https://newsletter.kentbeck.com/p/measuring-developer-productivity), 2023. 14. Tanya Reilly, [Being Glue](https://www.noidea.dog/glue), Stand 09/2026. 15. Benjamin Artz, Amanda H. Goodall, Andrew J. Oswald, [Boss Competence and Worker Well-being](https://openaccess.city.ac.uk/15975/), ILR Review 70(2), 2017. 16. Patrick Kua, [How do I still write code as a Tech Lead?](https://thekua.com/atwork/2014/11/how-do-i-still-write-code-as-a-tech-lead/), 2014. 17. Caitlin Sadowski, Emma Söderberg, Luke Church, Michal Sipko, Alberto Bacchelli, [Modern Code Review: A Case Study at Google](https://sback.it/publications/icse2018seip.pdf), ICSE-SEIP 2018.