- Der „10x-Engineer“ wirkt intuitiv plausibel, doch Produktivität objektiv zu messen ist in der Praxis sehr schwierig, und sie als unveränderliches persönliches Merkmal zu betrachten, ist ebenfalls ein falscher Ansatz
- Die tatsächliche Ownership und die Ergebnisse von Software werden durch Zusammenarbeit und Fähigkeiten auf Ebene des Engineering-Teams bestimmt
- Wirklich herausragende Organisationen zeichnen sich nicht nur dadurch aus, dass sie besonders exzellente Menschen haben, sondern dadurch, dass sie eine Umgebung schaffen, in der gewöhnliche Engineers konstant gute Ergebnisse erzielen
- Systeme sollten so entworfen werden, dass sie berücksichtigen, dass gewöhnliche Menschen Fehler machen oder ermüden können, und der Fokus sollte darauf liegen, „10x-Teams“ zu schaffen
- Architektur und Kultur von Softwaresystemen sollten auf den Eigenschaften, der Vielfalt und dem Wachstumspotenzial „gewöhnlicher Menschen“ basieren
- Letztlich ist der Business-Impact der zentrale Indikator für Produktivität; wichtig ist nicht, die „besten Talente“ zu rekrutieren, sondern die richtigen Menschen einzustellen und Teams entsprechend aufzubauen
Zum Lob des „gewöhnlichen“ Engineers
- Dieser Text kritisiert das Konzept des „10x-Engineers“ und erklärt, warum Organisationen wichtig sind, in denen gewöhnliche Engineers außergewöhnliche Teamleistungen erzielen
Der Mythos des „10x-Engineers“ und seine Grenzen
- Fast jeder hat in seiner Laufbahn schon einmal außergewöhnliche Engineers getroffen, die beinahe wie Magier wirkten
- Daraus entstand das Konzept des „10x-Engineers“, doch es ist nur schwach begründet und verstärkt zudem Vorurteile
- Einen einheitlichen Maßstab für Produktivität festzulegen, ist nahezu unmöglich
- Die Kombination aus Tech-Stack, Domäne, Entwicklungsphase, Marktsituation, Erfahrung und weiteren Variablen ist praktisch unendlich
- Eine Person kann in einem bestimmten Bereich ein 10x-Engineer sein, in den meisten anderen Bereichen aber gewöhnlich oder sogar unterdurchschnittlich
- Selbst wer einmal ein herausragender DBRE war, kann mit der Zeit in diesem Bereich nur noch durchschnittlich sein
- Letztlich gilt: Niemand kann in allen Bereichen dauerhaft zehnmal besser sein
Teamzentrierte Software-Ownership
- Software wird von Teams besessen und betreut, nicht von Einzelpersonen
- Bereitstellung, Wartung, Verbesserung, Skalierung und Refactoring von Software erfolgen vollständig auf Teamebene
- Ein System, das einer einzigen Person gehört, wird bei Urlaub oder Weggang dieser Person zu einem Single Point of Failure (SPOF) und damit zu einer Schwachstelle der Organisation
- In Startups kann individuelle Ownership am Anfang unvermeidlich sein, doch mit dem Wachstum der Organisation muss sie zwingend in Team-Ownership überführt werden
- Die Kernaufgabe von Engineering-Führungskräften sollte darin bestehen, leistungsstarke Teams aufzubauen; wichtiger als ein „10x-Engineer“ ist ein 10x-Team
Bedingungen für wirklich leistungsstarke Organisationen
- Viele Unternehmen bevorzugen Teams mit Menschen von FAANG, Eliteuniversitäten oder mit Staff-Engineer-Hintergrund
- Doch wirklich gute Organisationen sind solche, in denen gewöhnliche Engineers verlässlich echten Impact erzielen können
- Größere Wettbewerbsstärke entsteht nicht durch Organisationen, in denen nur die „Besten“ Ergebnisse liefern können, sondern durch Systeme, in denen auch durchschnittliche Entwickler eigenständig wachsen und Produkt sowie Business positiv beeinflussen können
- Gerade solche Organisationen bringen mehr World-Class-Engineers hervor
Die Bedeutung von „Gewöhnlichkeit“ neu definieren
- In der Softwarebranche ist elitär geprägtes Denken wie „Top 10 %“ oder „Top 0,1 %“ weit verbreitet
- Umso wichtiger ist es anzuerkennen, dass die meisten Engineers gewöhnliche Menschen sind, die durch vielfältige Erfahrungen und Übung gewachsen sind
- Niemand wird von Natur aus als „großartiger Engineer“ geboren
- Großartige Engineers werden gemacht – jeder kann durch Lernen und Erfahrung hervorragend werden
Systeme für gewöhnliche Menschen entwerfen
- Bei der Einstellung ist es richtig, auf außergewöhnliche Stärken zu achten, doch beim Systemdesign muss man berücksichtigen, dass Menschen ganz gewöhnlich Fehler machen, ermüden und sich auf Gewohntes verlassen
- Durchschnittliche Engineers werden von kognitiven Verzerrungen, Müdigkeit und emotionalen Schwankungen beeinflusst
- Wenn Systeme nicht für eine kluge Minderheit, sondern aus der Perspektive gewöhnlicher Engineers entworfen werden, kann sich die kreative Stärke herausragender Talente auf das Produkt selbst konzentrieren
Wie man ein „10x-Team“ aufbaut
- Die Zeit zwischen dem Schreiben von Code und dem Deployment so weit wie möglich verkürzen
- Kurze Deployment-Zyklen senken die kognitive Last und ermöglichen schnellere Experimente und Feedback
- Je langsamer Deployments sind, desto mehr Änderungen sammeln sich auf einmal an, was Ursachenanalyse und Rollback erschwert
- Fehlerbehebung und Rollbacks einfach machen
- Entwickler sollten ihren Code selbst deployen und bei Problemen schnell wiederherstellen können
- Richtiges Verhalten einfach und falsches Verhalten schwierig machen
- In Zusammenarbeit mit Designern und Platform Engineers Guardrails und Self-Service-Strukturen aufbauen
- Konsequent in Observability- und Instrumentierungs-Tools investieren
- Das reale Verhalten von Code sichtbar machen, damit alle Engineers Systeme leichter verstehen und debuggen können
- Engineering-Ressourcen in interne Tools und Produktivitätssteigerung investieren
- Solche Systeme brauchen eigene Ownership und sollten eine unternehmensweite Priorität sein
- Eine inklusive Kultur schaffen
- Eine Umgebung, in der jeder Fragen stellen, Fehler machen und Dinge erkunden kann
- Teams mit unterschiedlichen Hintergründen, Skills und Erfahrungsstufen sind resilienter und robuster gegenüber Veränderungen
- Teams aus Engineers aller Erfahrungsstufen zusammenstellen
- Von Junior bis Senior: eine Struktur, in der Menschen voneinander lernen, einander lehren und gemeinsam wachsen
- Solche Systeme lassen sich auch für das Onboarding neuer Mitarbeitender oder Teamwechsel wiederverwenden
Der wahre Maßstab für Produktivität: „Business-Impact“
- Letztlich ist der Maßstab für Produktivität im Software Engineering der Business-Impact
- Es geht nicht darum, viel Code zu schreiben, sondern Probleme zu lösen und Wert zu schaffen
- In der Praxis wird die Branche nicht von Staff+-Engineers getragen, sondern von Senior- und Mid-Level-Engineers
- Sie bilden das Fundament von Organisationen und treiben das Business kontinuierlich voran
- Wenn nur Staff+-Level Impact erzielen können, ist das ein Signal für Probleme in der Organisation
Organisationen, die World-Class-Engineers hervorbringen
- Eine wirklich gute Organisation ist eine, in der auch Menschen ohne außergewöhnliche Fähigkeiten Impact erzielen können
- Die besten Organisationen bringen ganz natürlich die meisten World-Class-Engineers hervor, auch ohne gezielt nur Talente auf Weltklasse-Niveau einzustellen
- Talente sammeln sich dort, wo Engineers sich auf Problemlösung, Wachstum und Impact konzentrieren können, und die Erfahrung, „glücklich zu arbeiten und zu wachsen“, setzt einen positiven Kreislauf in Gang
- Führungskräfte sollten sich nicht auf die individuelle Stärke einzelner Top-Talente verlassen, sondern diese in Wachstum der gesamten Organisation und in Kundennutzen übersetzen
Lieber die „richtigen Menschen“ einstellen als die „besten Talente“
- Die Branche sucht oft nur nach den „Besten“, doch wirklich entscheidend sind Systeme und Umfeld
- Wichtiger als „die besten Talente“ zu finden ist es, Menschen zu finden, die zum Team und zur Organisation passen
- Effizienter ist es, Teams nicht mit Menschen ohne erkennbare Schwächen zu besetzen, sondern mit passenden Talenten, die eigene Stärken mitbringen und Vielfalt wie Harmonie in der Organisation fördern
- Inklusive und vielfältige Teams führen in der Praxis zu Leistung, Wachstum und langfristigem Erfolg
- Wirklich weltklasse sind Organisationen, in denen alle gern arbeiten, wachsen und bedeutungsvolle Ergebnisse erzielen, und in denen eine Kultur des Lernens aus Scheitern und Fehlern sowohl Engineers als auch Organisation wachsen lässt
- Genau solche Organisationen ziehen auch die nächste Generation von Engineers an und schaffen ein Umfeld, in dem selbst bereits herausragende Talente bleiben möchten
1 Kommentare
Hacker-News-Kommentare
Ich kann der Aussage etwas abgewinnen, dass das Engineering-Team die kleinste Einheit für Software-Eigentümerschaft und Delivery ist, finde sie aber auch etwas unbefriedigend. So eine Struktur hängt mit einer Kultur zusammen, in der Engineers gegenüber Management oder Produkt eher Bürger zweiter Klasse sind. Wir tragen dann nur Verantwortung für die Delivery, können aber keine wirklich bedeutenden Entscheidungen unabhängig über mehr als einen sehr kleinen Teamrahmen hinaus treffen. In den besten Teams reicht der Handlungsspielraum über Monate, sogar Jahre, in den meisten Teams schrumpft er aber auf Tage oder Wochen. Tatsächlich ist es jedoch gut möglich, dass Engineers echte Ownership haben und ein System trotzdem lange tragfähig bleibt, ohne zu zerbrechen oder riskant zu werden. Das Geheimnis ist, Slack zu sichern, qualitativ gute Arbeit zu fördern und allen genug Freiheit zu geben, flexibel zwischen Aufgaben zu wechseln. Wenn jede Person Ownership hat und langfristige Entscheidungen trifft, dabei aber ad hoc zusammenarbeitet und implizites Wissen teilt, wird auch das Szenario natürlich, dass jemand spontan dazustößt, hilft oder die Arbeit ganz übernimmt. Meiner Erfahrung nach gibt es in solchen Teams mehr Rewrites als in gewöhnlichen Teams, insgesamt sind sie aber deutlich produktiver. Systeme schrittweise in kleine Teile neu zu schreiben, ist sowohl für die Design-Evolution als auch für den Aufbau von Wissen und Fähigkeiten in der Organisation sehr effektiv. Von außen wirkt das vielleicht wie Verschwendung, ist aber essenzieller Slack, um die gesamte Organisation flexibel und resilient zu machen. Im Gegenteil bin ich zunehmend überzeugt, dass viele Top-down-Prozesse, die angebliche Verschwendung reduzieren sollen, in Wahrheit wichtigen „Slack“ beseitigen
Menschen außerhalb des Engineerings können langfristige Entscheidungen von Engineers oft nicht direkt beurteilen und wissen dann nicht, wie sie diese belohnen sollen. Das gilt sogar schon außerhalb desselben Engineering-Teams. Ihnen fehlt die Fähigkeit, den tatsächlichen Wert langfristiger Arbeit mit internem Nutzen selbst zu bewerten. Wenn man sich seiner langfristigen Entscheidungen und des Einsatzes von Slack Time sicher ist, kann man auch mit einer Vergütung nach Delivery leben. Irgendwann wird diese langfristige Arbeit zu besseren Ergebnissen führen
Ich denke, dass Software-Rewrites im Entwicklungsprozess eine wichtige Rolle spielen. Wirklich „agil“ ist es, sich nicht zu sehr um die erste Architektur zu sorgen, schnell einen Prototyp zu bauen und flexibel auf veränderte Anforderungen zu reagieren. Coden ist wie Schreiben: Es ist viel effizienter, erst einmal einen rohen ersten Entwurf zu machen und ihn in einer zweiten Version zu verbessern. Das Ziel des ersten Entwurfs ist nicht, gut zu sein, sondern schnell etwas zu bauen, den Problemraum zu erkunden und Edge Cases zu erkennen. Diese Arbeitsweise kommt beim Management oft nicht gut an. Sobald man einen funktionierenden Prototyp zeigt, heißt es nur: „Lasst uns das sofort ausrollen“, und Zeit für einen Rewrite bekommt man nicht. Eine gute Lösung wäre, Hierarchien in der Organisation flacher zu machen und Engineers die Code-Ownership tatsächlich zurückzugeben. Wünschenswert ist eine Struktur, in der Engineers und Product Owner gemeinsam und demokratisch Entscheidungen treffen
Ich habe früher auch viel Wert auf „individuelle Ownership“ gelegt, und ich glaube noch immer, dass Engineers Ownership haben können, aber ich erkenne auch an, dass viele Engineers das in der Praxis gar nicht wollen. Mit Ownership auf Teamebene können die meisten leben, an Ownership auf Ebene einzelner Engineers sind sie meist nicht besonders interessiert. Es ist eben einfach ein Job. Wenn man das dem Individuum überlässt, schafft das leicht Misstrauen im Team oder grenzt Mitglieder aus, die keine Führungsneigung haben, und am Ende entsteht schnell eine Situation, in der niemand echten Ermessensspielraum hat. Ownership und Autonomie auf Teamebene zu vergeben, ist viel einfacher und effektiver. Das ist auch eine Dynamik, die durch Team Leads oder Manager möglich wird. Individuelle Software-Ownership ist wegen Personalwechseln, Stabilität, Karrierefragen und ähnlichen Variablen zu riskant. Selbst die gesündeste Organisation hat große und kleine Probleme, und in so einer Struktur ist der Weg zum Scheitern am kürzesten. Mit einem Getriebe ist es leicht zu verstehen: Wenn es nur einen Gang gibt und der kaputtgeht, kommt man nicht weiter; mit mehreren Gängen geht es trotz Unbequemlichkeit weiter, selbst wenn einer ausfällt
Ich glaube wirklich, dass echte individuelle Ownership möglich ist. Ich halte sie sogar für die einzige Art, wirklich „produktiv“ zu sein. Aber das ist nicht der Kernpunkt. Einzelne Personen sind unersetzlich, Teammitglieder sind je nach Struktur bis zu einem gewissen Grad ersetzbar. Je größer eine Organisation wird, desto mehr will sie Vorhersagbarkeit auf Teamebene, und dafür braucht sie Austauschbarkeit der Mitglieder, also Redundanz. Auch im Engineering schafft man Redundanz für Zuverlässigkeit und Resilienz; Effizienz ist dabei der Trade-off, der Redundanz reduziert
Wir haben in Strukturen gearbeitet, in denen wir nur für „Delivery“ verantwortlich waren, und Ownership bedeutete am Ende nur zusätzliche Last ohne echte Belohnung. Die Arbeit beschränkte sich darauf, Features an eine Seite zu kleben. Wenn zusätzliche Verantwortung hinzukommt, sollte es dafür natürlich auch zusätzliche Vergütung geben. Manager und Executives werden danach bezahlt, für wie viele Menschen sie Verantwortung tragen; für Entwickler sollte dasselbe gelten
Ich bin überzeugt, dass die besten Teams eine Kultur haben, in der gewöhnliche Engineers außergewöhnliche Ergebnisse erzielen können. Wichtiger als das, was landläufig als „Engineering-Qualität“ oder Talent-Recruiting gilt, sind Kultur, Vertrauen, Systeme und Prozesse. Es gibt die Aussage: „Jeder kann eine Organisation mit den besten Engineers aufbauen“, aber in Wirklichkeit haben das nur sehr wenige geschafft. Fast immer sind es Trading-Firmen oder Spezial- bzw. Forschungsorganisationen. Ich frage mich ernsthaft, warum es sonst kaum jemand hinbekommt. Letztlich ist schon unklar, was „Produktivität“ überhaupt genau bedeuten soll. Es gibt Bewertungssysteme, die im Grunde nur messen, wie gut jemand Dysfunktionen in der Organisation aushält und überwindet, aber ich glaube nicht, dass das die wahre Bedeutung eines „Top-Engineers“ ist
Das Angebot an wirklich herausragenden Engineers ist begrenzt, daher locken am Ende größere Unternehmen dieselben Talente mit interessanterer Arbeit oder höherem Gehalt ab
Neben dem Geld, das andere schon erwähnt haben, ist auch „Zeit“ ein sehr großer Faktor. Ein Unternehmen hat oft nicht die Muße, auf den perfekten „Unicorn“-Kandidaten zu warten, sondern muss die Stelle schnell mit verfügbaren Leuten besetzen. In manchen Unternehmen, besonders in Bereichen wie Quant Finance, kann ein Super-Engineer, der zugleich Systemprogrammierer, Mathematiker und Experte für Finanzmärkte ist, weit mehr Wert schaffen als ein Team aus drei Spezialisten. Aber so jemanden zu finden, dauert einfach zu lange. Selbst im Web Development sind „echte Full-Stack“-Entwickler, die von Netzwerkprotokollen über Systemadministration, verteilte Systeme, Datenbanken bis Frontend wirklich breit Bescheid wissen, extrem selten. Nur Organisationen mit genug Zeit und Geld können solche Leute versammeln und damit die besten Produkte bauen. Ob das Produkt tatsächlich ein solches Qualitätsniveau braucht, ist natürlich eine andere Frage
Grundsätzlich ist das weltweite Angebot an „Top-Engineers“ extrem begrenzt. Wenn man Gehälter im obersten 10%-Bereich zahlen und entsprechend gute Leute gewinnen und halten kann, ist das schon ein Erfolg. Tatsächlich kann das eben nicht „jeder“ schaffen; dafür braucht es Führung, die ein soziotechnisches System gestaltet, das auf Lernen und Wachstum ausgerichtet ist. Auch das ist an sich schon eine großartige Leistung
Das größte Problem ist, dass die meisten Führungskräfte der ersten und zweiten Ebene gar nicht so gut sind. Ihnen fehlt die Fähigkeit, produktive Umgebungen zu schaffen und zu erhalten. Die grundlegende Lösung ist am Ende schlicht: viel Geld zahlen. Wenn das Geld groß genug ist, lassen sich die meisten schwierigen Bedingungen ertragen
Unabhängig vom Budget könnte ein wirklich herausragender Engineer für Teamplay sogar eher schlecht sein. Ein brillanter Kopf kann bei notwendigen Kompromissen oder langweiligen, aber wichtigen Aufgaben sogar hinderlich sein
Ich kann der Behauptung, „Business Impact sei der einzige Maßstab für Produktivität“, überhaupt nicht zustimmen. Diese Sicht verengt den Blick auf messbare Veränderungen und kurzfristige Ergebnisse und übersieht den eigentlichen Wert erfahrener Engineers. Die wahre Stärke guter Leute besteht oft darin, Risiken und Landminen zu verhindern, die sonst ein Projekt oder ein Unternehmen fast zerstört hätten. Aber solche „verschwundenen Risiken“ sind schwer messbar und fast unmöglich so zu vermitteln, dass sie nicht banal klingen
„Impact“ muss nicht zwingend kurzfristig gedacht sein. Die Menschen mit dem größten Impact in einer Organisation handeln aus einer langfristigen Perspektive heraus
Ich spreche absichtlich vage von „Produktivität“ oder „Impact“, zum Beispiel in Sätzen wie: „Alles in allem hat X wirklich gute Arbeit geleistet.“ Das lässt sich schwer quantifizieren oder präzise regeln, aber in komplexen und kreativen Organisationen sind menschliche Einsicht und Urteilskraft eben wichtiger. Management um jeden Preis zu quantifizieren, ist grundsätzlich kurzsichtig
Ich bin nicht dafür, den Wert von Engineers nur über Projektmanagement oder Risikovermeidung zu messen, aber es ist mir auch unangenehm, alles auf „Business Impact“ zu reduzieren. Es gibt viele Dinge auf der Welt, die für Einzelne, die Menschheit oder die Welt bedeutungsvoll sind, ohne etwas mit Geld zu tun zu haben. Die Engineers, die ich am meisten bewundere, sind nicht die mythischen Figuren des Silicon Valley nach 2001, sondern John von Neumann, Robert Oppenheimer, Nikola Tesla, Leonardo da Vinci, irgendjemand, der die römischen Aquädukte oder die ägyptischen Pyramiden gebaut hat, oder Astronomen aus Babylonien und Mesoamerika. Haben sie „Business Impact“ hinterlassen? Selbst wenn Tesla zeitweise Westinghouse Gewinn gebracht hat, erklärt das seine Leistung nicht. Geschäftlich war er eher durchschnittlich. Für die Größen der modernen Computing-Industrie gilt Ähnliches. Dass Nvidia oder Geoff Hinton so enorm erfolgreich wurden, hat auch mit Glück zu tun, nämlich mit der Datenexplosion durch die Kommerzialisierung des Internets über Werbung. Es gibt viele Fälle, in denen wirklich fähige Leute übersehen wurden und verschwanden. Selbst jemand wie Doug Lenat, ein Gigant der KI, wurde am Ende vom Lauf der Geschichte nicht wirklich gewürdigt. Ob jemand Erfolg hat, hat oft wenig mit seiner persönlichen Leistung zu tun
Entweder baut man effiziente Systeme, oder man baut Systeme, die das Katastrophenpotenzial minimieren. Welche Katastrophe konkret verhindert wurde, lässt sich in der Praxis schwer beweisen, und negative Auswirkungen sind als „nicht eingetretene Ereignisse“ schwer als Ergebnis zu zeigen
Unternehmen sollten sich bemühen, das Risiko des „Unbekannten“ irgendwie besser zu quantifizieren
Ich hatte das Glück, bisher in mehreren großartigen Teams zu arbeiten, und leite auch heute eines. Anders als der Artikel suggeriert, sind gerade solche Teams für Organisationen oft schwerer zu managen. Große Organisationen fokussieren sich auf Standardisierung, und genau dadurch verlieren exzellente Engineers häufig die Möglichkeit, ihre Fähigkeiten zu entfalten, sowie die Motivation. Ich teile nicht die pessimistische Sicht, dass man nicht alle zu großartigen Engineers entwickeln könne. In der Praxis kann man mit konsequenter Investition sehr wohl hervorragende Engineers heranbilden, und langfristig übersteigt der Nutzen eines größeren Pools starker Talente die Kosten dieser Investition deutlich
Nur weil etwas nicht effektiv messbar ist, heißt das nicht, dass es nicht existiert. Individuelle Produktivität, also die Leistung einzelner Personen, gibt es eindeutig. Wahrscheinlich ist Gruppenproduktivität nur leichter zu messen. „Business Impact“ ist im Gegenteil viel willkürlicher, und mit einem solchen Maßstab ist es schwer, wirklich produktive Talente zu halten. Fachwissen zu bewerten ist ohne gleichwertige Erfahrung sehr schwierig; man kann Ratschläge geben, aber ob das Gegenüber die intellektuelle Offenheit hat, sie anzunehmen, ist eine andere Frage. Woher soll ich wissen, ob ich ein Genie bin oder nur jemand mit übersteigertem Selbstvertrauen?
Das Problem ist nicht, dass man Produktivität nicht „messen“ kann, sondern dass man sie nicht einmal abstrakt sauber „definieren“ kann. Selbst wenn man nur misst, wie viel mehr jemand im Vergleich zu einem „Ersatz“ beigetragen hat, erklärt das noch nicht genau, wie dieses Ergebnis zustande kam. In Wirklichkeit wird der Einfluss einer Person vom Kontext und der gesamten Organisation bestimmt. Selbst bei direkteren Definitionen fällt die richtige Antwort je nach Organisation und Situation völlig unterschiedlich aus. Darüber nachzudenken lohnt sich unbedingt, aber selbst ob der Maßstab eines „Top-1-%-Engineers“ überhaupt sinnvoll ist, erscheint fraglich
Ein echtes Genie kann seine Ergebnisse mit gutem Stil und auf leicht verständliche Weise erklären. Deshalb denke ich, dass man die Unterschiede durchaus erkennen kann
Mir gefällt der Satz: „Die beste Organisation ist die, die normalen Engineers ermöglicht, großartige Arbeit zu leisten.“ Nicht jedes Teammitglied muss ein Superstar sein. Entscheidend ist, wie gut die Unterstützung funktioniert, damit durchschnittliche Entwickler solide, verlässliche Arbeit auf gutem Niveau leisten können
Das Prinzip „Mache das Richtige leicht und das Falsche schwer“ ist im Grunde derselbe Leitsatz, den jedes Plattformteam, das ich erlebt habe, im Kern verfolgt. Das Ziel ist, Systeme so zu gestalten, dass bei den Problemen, denen Engineers begegnen, die „richtige Antwort“ automatisch sichtbar wird und sich leicht umsetzen lässt. Wenn das mit Zuverlässigkeit und einfacher Betriebsführung verbunden ist und so ganz natürlich die richtigen Entwicklungsgewohnheiten fördert, profitiert die ganze Organisation. Diese Wahrheit wird auch in Zukunft gelten
Immer wenn verschiedene Sprachen oder Frameworks wie golang, python, COBOL, lisp, perl, React oder brainfuck erwähnt werden, habe ich schon lange das Gefühl, dass viele React mit dem gesamten Frontend-Ökosystem verwechseln. Dabei existiert jenseits von React eine vielfältige Frontend-Welt, aber viele tun so, als wäre React alles
In unserem Unternehmen stellen wir immer lieber durchschnittliche Engineers mit guter Haltung ein. Menschen mit guten Qualifikationen, aber schlechter Haltung sind oft gut darin, ihren Ruf nach oben zu managen, gewinnen schnell das Vertrauen der Führung und werden danach praktisch unangreifbar. Wenn sich so jemand festsetzt, ist es für die Umgebung schwer, Probleme anzusprechen, selbst wenn das offensichtlich unfair ist. Führungskräfte ignorieren dann auch leicht Daten, die nicht zu ihrem Bild passen. Sich auf Wahrnehmung statt auf objektive Daten zu verlassen, ist viel einfacher
Ich stimme der Aussage wirklich zu, dass „jeder eine Organisation aufbauen kann, die mit Top-Engineers arbeitet, und dass der Fokus auf individuelle Fähigkeiten die eigentliche Rolle von Führung verwässert. Systeme zu schaffen, in denen weniger erfahrene Engineers ihre Fähigkeiten einsetzen und Ergebnisse liefern können, ist ein enormer Wettbewerbsvorteil“. Ich bin kein 10x-Engineer, aber in meiner jüngsten Erfahrung war ich in einem Team mit vielen Leuten mit wenig Erfahrung oder Können und habe dadurch allein die meisten komplexen Tickets übernommen. Wenn sich dieses Muster wiederholt, erledige ich am Ende den Großteil der Arbeit allein, und diese Rolle fühlt sich sowohl anstrengend als auch unfair an. Ehrlich gesagt denke ich, dass ein guter SRE auch ein wenig faul sein sollte, deshalb wünsche ich mir sehr, dass Teammitglieder die Arbeit mittragen. Also habe ich mehrere Wochen sehr intensiv gearbeitet und in die komplexesten Teile verschiedene Abstraktionen eingeführt, hauptsächlich in IaC; in Software gibt es ähnliche Muster. Danach konnten auch Engineers mit weniger Können oder Erfahrung Teile meiner Rolle übernehmen, und ich konnte meine Zeit auf interessantere Probleme verwenden. Es war das erste Mal, dass ich so etwas ohne Anweisung von oben versucht habe. Ohne eine solche Struktur dagegen, wenn man allein als Held auftritt, läuft am Ende das ganze Team hinter einem her und muss Fehler ausbaden, und daraus wird letztlich ein wirklich ineffizientes Team