Die Daten gaben ihnen zunächst recht.

Was uns gesagt wurde

Uns wurde gesagt, ein Entwickler bringe unterdurchschnittliche Leistung.

Die Bedenken kamen von der Produkt- und der Entwicklungsleitung.

Der Entwickler wurde beschrieben als jemand, der zu lange für die Lieferung brauche, Entscheidungen zu oft infrage stelle und die Harmonie des Teams störe.

Die Organisation erwog, den Entwickler aus dem Team zu entfernen.

Die Beweislage schien eindeutig.

Von der Zuweisung der Arbeit in GitHub bis zur Eröffnung eines Pull Requests brauchte dieser Entwickler oft länger, als wir für die eigentliche Umsetzung erwartet hätten.

Gemessen daran war der Entwickler tatsächlich langsamer.

Was wir beobachtet haben

GitHub zeigte die verstrichene Zeit.

Es zeigte nicht, was der Entwickler in dieser Zeit tat.

Also verfolgten wir die Arbeit weiter in Slack.

Nach Erhalt einer Anfrage fragte der Entwickler häufig, warum eine bestimmte Spezifikation existierte, welches Problem sie lösen sollte oder ob eine andere Umsetzung dasselbe Ziel besser erreichen würde.

Das waren keine beliebigen Einwände.

Es waren Versuche, den Hintergrund der Anforderung zu verstehen oder eine Alternative vorzuschlagen, bevor die Umsetzung begann.

Der Product Owner behandelte diese Fragen und Vorschläge in der Regel als unnötig.

Wurde ein Vorschlag abgelehnt, begann der Entwickler sofort mit der Umsetzung.

Blieb eine Frage oder ein Vorschlag unbeantwortet, wartete der Entwickler nicht unbegrenzt.

Nach drei Werktagen erklärte der Entwickler, dass keine Antwort eingegangen sei und die Umsetzung nun auf Grundlage der ursprünglichen Anfrage erfolge.

Erst dann begann die eigentliche Programmierarbeit.

Das Muster

Die Organisation maß die gesamte Zeit zwischen Zuweisung und Lieferung als Umsetzungszeit der Entwicklung.

Doch ein erheblicher Teil dieser Zeit fiel bereits vor der Umsetzung an.

Der Entwickler versuchte, die Absicht zu klären, Annahmen zu hinterfragen oder eine Alternative vorzuschlagen.

Diese Tätigkeiten wurden nicht als nützliche Arbeit gewertet.

Sie wurden als Verzögerung gedeutet.

Diese Deutung prägte auch den Ruf des Entwicklers.

Fragen zu stellen wirkte wie Widerstand.

Alternativen vorzuschlagen wirkte wie die Verweigerung von Anweisungen.

Das Warten auf eine unbeantwortete Produktentscheidung wirkte wie eine langsame Umsetzung.

Dasselbe Verhalten diente somit als Beleg für mehrere negative Urteile über die Person.

Dann fanden wir ein weiteres Signal

Einige der abgelehnten oder ignorierten Vorschläge des Entwicklers verschwanden nicht einfach.

Nachdem die ursprüngliche Umsetzung veröffentlicht worden war, forderte der Product Owner dieselbe Idee manchmal in einem späteren Sprint erneut an.

Der Vorschlag, der zuvor als unnötig abgetan worden war, kehrte später mitunter als offizielle Anforderung zurück.

Das war bedeutsam.

Es zeigte, dass die Fragen und alternativen Vorschläge des Entwicklers nicht bloß Blockade waren.

Zumindest einige davon identifizierten Verbesserungen, die die Produktorganisation ohnehin irgendwann gewollt hätte.

Unsere Hypothese

Der Entwickler litt nicht in erster Linie unter einem Fähigkeitsproblem.

Die Organisation hatte ein Umfeld geschaffen, in dem eine bestimmte Art von Verhalten über alle anderen hinweg belohnt wurde:

Die Anweisung genau wie erhalten ausführen.

Die Spezifikation zu hinterfragen erzeugte Verzögerung.

Eine Alternative vorzuschlagen erzeugte Reibung.

Das Warten auf Klärung erhöhte die gemessene Durchlaufzeit.

Aus dieser Perspektive konnte ein Entwickler, der die Arbeit vor der Umsetzung verbessern wollte, weniger produktiv erscheinen als einer, der einfach sofort mit dem Programmieren begann.

Das System maß nicht bloß die Liefergeschwindigkeit.

Es belohnte indirekt die Befolgung von Anweisungen.

Warum die ursprüngliche Diagnose überzeugend wirkte

Das ursprüngliche Urteil beruhte nicht auf erfundenen Daten.

Die verstrichene Zeit war tatsächlich länger.

Gerade das machte den Fall interessant.

Eine einzige Beweisquelle stützte die Schlussfolgerung der Organisation.

Hätten wir bei GitHub aufgehört, wären wir zum selben Schluss gekommen.

Doch die Kennzahl beantwortete nur eine Frage:

Wie viel Zeit verging zwischen Zuweisung und Lieferung?

Sie beantwortete nicht:

• Wann begann die Umsetzung tatsächlich?
• Was geschah vor der Umsetzung?
• Wer wartete auf wen?
• Welche Entscheidungen waren noch offen?
• Welcher Wert entstand außerhalb des eigentlichen Codes?

Was die Belege zeigten

Der Entwickler war langsamer, wenn man nur die verstrichene Lieferzeit maß.

Doch diese Zahl fasste mehrere unterschiedliche Arten von Tätigkeit in einer einzigen Kennzahl zusammen.

Sobald wir Umsetzung von Klärung, Vorschlag, Entscheidung und Wartezeit trennten, änderte sich die Bedeutung dieser Zahl.

Die Organisation hatte ein Interaktionsmuster auf Systemebene als individuelles Leistungsproblem gedeutet.

Die Entfernung des Entwicklers hätte an diesem Muster nichts geändert.

Sie hätte lediglich die Person entfernt, deren Verhalten das Muster sichtbar machte.

Die Daten waren nicht falsch. Die Interpretation war unvollständig.

Die Sichtweise von Pulsar

Wir beginnen nicht damit, zu beurteilen, ob jemand gut oder schlecht in seinem Job ist.

Wir verfolgen die Arbeit.

In diesem Fall zeigte GitHub, dass die Lieferung länger dauerte.

Slack zeigte, warum.

Spätere Produktentscheidungen zeigten, dass ein Teil des vermeintlich unnötigen Verhaltens tatsächlich echten Wert identifiziert hatte.

Keine dieser Beobachtungen für sich allein erzählte die ganze Geschichte.

Zusammen veränderten sie die Diagnose.

Wir bewerten Menschen nicht anhand eines einzelnen Signals. Wir untersuchen das System, das dieses Signal hervorgebracht hat.