Der sogenannte 10X Engineer ist ein Entwickler, der der Legende nach zehn Mal so produktiv arbeitet wie der 1X Engineer, der in diesem Szenario der Unproduktivste im Team ist. Auslöser für die Diskussion war ein Tweet des indischen Investors Shekhar Kirani. In diesem Thread definiert Kirani elf Eigenschaften, an denen man einen 10X Engineer erkennen können soll:
Alles beginnt damit, dass er Gründern von Startups empfiehlt, gezielt nach 10X Engineers Ausschau zu halten, weil es seiner Meinung nach die Überlebenschancen des Startups deutlich steigere. Zudem handele es sich um Angehörige einer seltenen Spezies, die man schnell ans eigene Unternehmen binden muss, bevor sie nicht mehr verfügbar sind.
Es dauerte nicht lang, bis sich immer mehr Timelines von Entwicklern weltweit mit den Thesen des Investors füllten und dort auf Ablehnung und Zustimmung zugleich stießen. Gegner und Befürworter der These lieferten sich kontroverse Schlagabtausche, die selten sachlich blieben.
10X Engineer – wichtigster Mitarbeiter oder auf der Kündigungsliste?
In der Essenz stehen sich die Lager unversöhnlich gegenüber, weil die einen glauben, dass der Begriff 10X Engineer ähnlich negativ konnotiert ist, wie der des Rockstars. Danach seien solche Personen unfähig, nicht nur zur Teamarbeit sondern auch jeder anderen Form von Kollaboration. Stattdessen handele es sich um ausgeprägte Einzelgänger mit einem Hang zur Selbstüberschätzung, die sämtliche anderen Projektteilnehmer mindestens für intellektuell benachteiligt hielten. Dabei seien sie selber nicht so viel besser, dass sie eine zehnfache Produktivität tatsächlich nachweisen könnten. Im Ergebnis raten jene, die dem Begriff 10X Engineer negativ gegenüberstehen, davon ab, Personen mit den beschriebenen charakterlichen Eigenschaften einzustellen. Der Begriff an sich sei damit auch obsolet, denn die vermeintlichen positiven Fähigkeiten seien entweder nicht da oder nicht relevant.
Die andere Gruppe der Diskutanten hingegen definiert die von den Gegnern beschriebenen Nachteile teils zu Vorteilen um, teils negiert sie sie ganz. Danach seien 10X Engineers durchaus teamfähig und hätten auch ansonsten alle erforderlichen fachlichen und sozialen Kompetenzen. Alles andere sei bloß Wahrnehmung von Leuten, die an das hohe Leistungsniveau eines 10X Engineers aus den unterschiedlichsten Gründen nicht herankommen. Sie definieren den Streit als eine Neid-Debatte und sind felsenfest der Überzeugung, dass es den Begriff natürlich geben sollte, denn der 10X Engineer sei ein real existierender Fakt.
Der 10X Engineer auf der Sachebene: Was ist dran am Klischee?
Jason Crawford, leitender Entwickler bei der Logistik-Plattform Flexport, hat sich die Zeit genommen, Struktur in die Debatte zu bringen und sich neutral mit dem Thema zu befassen.
Dabei weist er darauf hin, dass das Klischee nicht eine bloße Erfindung darstellt, sondern durch diverse Studien belegt ist, die natürlich in sich nicht ohne Schwächen seien. Dabei gelte es indes verschiedene Aspekte im Blick zu behalten.
Der durchschnittliche Entwickler ist nicht 1X
So sei 10X nicht etwa der Unterschied zwischen dem besten und dem durchschnittlichen Entwickler, sondern jener zwischen dem besten und dem schlechtesten. Hieraus ergäbe sich ein Faktor von etwa 3X, bezogen auf den durchschnittlichen Entwickler. Der Abstand wirke schon weit weniger groß und daher eher glaubhaft.
In den diversen Studien, die zwischen 1968 und 2000 durchgeführt wurden, konnten Leistungsunterschiede bezogen auf definierte Aufgaben von individuell 5X bis 25X nachgewiesen werden. Diese breite Spanne zeige, dass jedenfalls große Produktivitätsunterschiede bestünden, unabhängig davon, ob man konkrete Ergebnisse einzelner Untersuchungen unbedingt auf 10X herunterbrechen könne.
Wer nicht fertig wird, ist 0X?
In diesem Zusammenhang gelte es zu bedenken, dass Gegenstand aller Untersuchungen stets nur Entwickler waren, die die definierten Aufgaben tatsächlich zu einem Ende geführt haben. Dabei gelte ein Anteil von etwa zehn Prozent aller Entwickler als realistisch, die gar nicht erst zu einem erfolgreichen Ende kommen. Hier würden weitere Kosten entstehen, die noch gar nicht in die Betrachtung geflossen seien, wie etwa jene des Entwicklers, der Bugs und Qualitätsprobleme beseitigt oder Teile der Software gleich ganz neu aufstellen muss.
Kritisch betrachtet Crawford den Umstand, dass die Reduktion auf die Produktivität nicht den vollen Wert eines Entwicklers für das Unternehmen repräsentiere, sowie den Fakt, dass sämtliche bisherigen Studien nicht auf Ursachenforschung gegangen sind.
Ist Produktivität eine Frage der Intelligenz?
Warum sind einige Entwickler produktiver als andere? Ist es tatsächlich eine Frage der Intelligenz oder gibt es weitere Einflussfaktoren?
Laut Crawford spielen inhärente Faktoren eine bedeutende Rolle. Das sei aber nicht auf den Beruf des Entwicklers beschränkt. Vielmehr gebe es in allen Berufszweigen ausgesprochene Leistungsträger und weniger starke Mitarbeiter.
Gleichzeitig mache aber auch die Arbeitsumgebung einen großen Teil des Erfolgs oder Misserfolgs aus. Nur wenn ein leistungsfähiger Mitarbeiter auch eine leistungsfähige Arbeitsumgebung vorfindet, kann er sein volles Potenzial abrufen. Das betreffe nicht nur die Ausstattung mit Arbeitsmitteln sondern auch die Organisation als solche. Gibt es Besprechungen im Übermaß? Sind die Hierarchien starr und innovationsfeindlich? Ist die Arbeit machbar verteilt oder leiden die Mitarbeiter unter ständiger Überlastung?
Die Qualität eines Entwicklers bestimmt sich nach einem Faktorengemisch
So ist die individuelle Produktivität für Crawford eine Mischung aus individuellen Fähigkeiten, die schwer zu beeinflussen sind, einem Skillset, das erlernt werden muss, und einer entsprechenden Arbeitseinstellung, die das Unternehmensumfeld zumindest teilweise vermitteln kann.
So kommen Arbeitgeber an die richtigen Leute
Aus alldem leitet Crawford folgende Empfehlungen für Arbeitgeber ab:
Die Bewerberauswahl ist wichtig. Schon an diesem Punkt muss klar sein, welche fachlichen und sozialen Fertigkeiten erforderlich sind. Dabei sollte das Unternehmen diese Anforderungen auch selber widerspiegeln.
Die Schaffung guter Arbeitsbedingungen ist unabdingbar. Das betrifft zum einen die technische Ausstattung, aber auch weichere Faktoren, wie das Betriebsklima und die Fortbildungs- und Aufstiegsmöglichkeiten.
Belohnt werden sollte Produktivität, nicht Zeiteinsatz. Crawford plädiert für eine bessere Bezahlung derer, die das Unternehmen produktiv nach vorne bringen, also mehr erledigen als andere – nicht jene, die am längsten abends im Büro sitzen.
Produktivität lässt sich verbessern und optimal nutzen. Arbeitgeber sollten Mitarbeiter laufend fortbilden und in Projekten einsetzen, die gut zu ihren Skillsets passen, um die maximale Leistung zu erhalten.
Schlechtes Benehmen sollte nicht toleriert werden. Antisoziale Verhaltensweisen, wie Arroganz, Unpünktlichkeit, Leistungsverweigerung, Übergriffigkeit und so weiter darf natürlich auch da nicht akzeptiert werden, wo ansonsten gute Leistungen zu verzeichnen sind.
Crawford bietet eine ausgewogene Sicht auf das Thema und bringt die Diskussion auf ein sachliches Level. Fraglich ist, ob es überhaupt sinnvoll sinnvoll ist, mit Begrifflichkeiten zu arbeiten. Jemanden als 10X Engineer zu bezeichnen, hat keinen Wert in sich. Lob und positive Verstärkung können auch subtiler stattfinden. Mit einer derart plakativen Etikettierung muss es zu Spannungen kommen. Diese werden clevere Arbeitgeber zu vermeiden wissen