Wir wussten es, bevor wir begannen.

Was uns gesagt wurde

Ein Unternehmen bat uns, seine Softwareentwicklungsorganisation zu verbessern.

Vor Beginn des Engagements trafen wir uns mit dem CEO und dem Leiter der Entwicklung, um zu besprechen, wo wir helfen könnten.

Uns wurde außerdem gesagt, dass der für die Arbeit nötige Zugang und die nötigen Berechtigungen sofort gewährt würden.

Auf dem Papier gab es kein Zugangsproblem.

Doch während desselben Gesprächs beobachteten wir etwas, das uns an dieser Vorhersage zweifeln ließ – nicht, weil wir dachten, jemand würde lügen, sondern weil das Verhalten in eine andere Richtung wies.

Was wir beobachtet haben

Der CEO schlug zunächst vor, uns in ein bestehendes Projekt einzubinden, das verbessert werden musste.

Der Leiter der Entwicklung erklärte, warum das nicht funktionieren würde: Das Projekt hatte bereits einen festen Release-Termin.

Der CEO schlug ein anderes Projekt vor. Dieses hatte keinen festen Release-Termin.

Wieder erklärte der Leiter der Entwicklung, warum es nicht funktionieren würde: Es seien zu viele Stakeholder beteiligt, als dass ein Außenstehender einsteigen und Verantwortung übernehmen könnte.

Beide Einwände hätten für sich genommen durchaus vernünftig sein können.

Also versuchte es der CEO mit einer dritten Option: Statt uns ein Projekt zuzuweisen, könnten wir vielleicht helfen, die Produktivität des Entwicklungsteams zu verbessern.

Diesmal fiel die Reaktion positiv aus.

Das klang vielversprechend.

Also stellten wir eine Frage.

Gab es einen gemeinsamen Entwicklungsansatz in der gesamten Organisation, oder konnte jeder Entwickler frei entscheiden, wie er arbeitet?

Die Antwort war, dass den Entwicklern bewusst die Freiheit gelassen wurde, ihre eigenen Methoden zu wählen.

Dann stellten wir dem Leiter der Entwicklung eine hypothetische Frage:

Wenn Ihnen jemand eine andere Arbeitsweise zeigen könnte, die Sie zehnmal produktiver machen würde – würden Sie sie übernehmen?

Die Antwort war Nein.

Diese Antwort war bedeutsam.

Aber das Muster war noch bedeutsamer.

Das Muster

Jedes Mal, wenn der CEO einen Weg vorschlug, wie wir beitragen könnten, erklärte der Leiter der Entwicklung, warum es nicht funktionieren würde.

• Projekt A konnte nicht funktionieren.
• Projekt B konnte nicht funktionieren.
• Die Verbesserung der Entwicklungspraktiken klang zunächst akzeptabel – doch die für die Entwicklung verantwortliche Person sagte dann ausdrücklich, dass selbst eine deutlich produktivere Arbeitsweise nicht übernommen würde, wenn sie von jemand anderem käme.

Es gab noch ein weiteres Signal.

Es wurde keine Alternative vorgeschlagen.

In dem Gespräch ging es vordergründig darum, einen Weg zu finden, wie wir helfen könnten. Doch eine Person erklärte wiederholt, warum jeder vorgeschlagene Weg unmöglich sei, ohne einen gangbaren Weg vorzuschlagen.

Die einzelnen Einwände waren Datenpunkte.

Das Muster dahinter war ein Beleg für etwas Größeres.

Unsere Hypothese

Das Problem war nicht Projekt A.

Es war nicht Projekt B.

Und es war nicht die konkrete Form der diskutierten Produktivitätssteigerung.

Unsere Hypothese war, dass die Entwicklungsorganisation Eingriffe von außen tatsächlich nicht akzeptierte.

Wenn diese Hypothese zutraf, würde sich das Problem nicht mit der Entscheidung erledigen, welche Arbeit wir übernehmen sollten.

Sobald das Engagement begänne, würde derselbe Widerstand bei den Dingen auftauchen, die für diese Arbeit nötig sind – einschließlich des Zugangs zu Systemen, Informationen und Berechtigungen.

Noch bevor das Engagement begann, sagten wir also voraus, dass die Beschaffung des für eine effektive Arbeit nötigen Zugangs zu einem Problem werden würde.

Warum wir trotzdem weitermachten

Unter normalen Umständen wäre dies ein Grund gewesen, das Engagement abzulehnen.

Das hatten wir vor.

Doch Geschäftsentscheidungen werden von Menschen getroffen, nicht von Optimierungsalgorithmen.

Das Engagement war über jemanden zustande gekommen, dem wir sehr viel verdankten. Angesichts dieser Beziehung und der Umstände war eine Ablehnung realistisch keine Option.

Also machten wir trotz des erkannten Risikos weiter.

Was die Belege zeigten

Nachdem das Engagement begonnen hatte, wurden der Zugang und die Berechtigungen, die uns angeblich sofort gewährt werden sollten, zu einem erheblichen Hindernis.

Die Vorhersage bestätigte sich.

Aber hier ging es nicht darum, Lügen aufzudecken.

Wir mussten nicht klären, ob jemand wissentlich eine falsche Aussage gemacht hatte. Es ist gut möglich, dass die Beteiligten tatsächlich glaubten, der nötige Zugang könne sofort bereitgestellt werden.

Für unseren Zweck war die Absicht irrelevant.

Die Aussage war ein Datenpunkt.

Das Verhalten, das wir während desselben Gesprächs beobachteten, war ein weiterer.

Als diese Datenpunkte in unterschiedliche Richtungen wiesen, bildeten wir eine Hypothese darüber, was tatsächlich geschehen würde – und warteten auf beobachtbare Belege, die sie bestätigen oder widerlegen würden.

Was Menschen sagten, war ein Datenpunkt. Wie sie sich dabei verhielten, war ein weiterer.

Die Sichtweise von Pulsar

Das meiste, was wir tun, geschieht, nachdem ein Problem bereits aufgetreten ist. Dieser Fall war anders.

Wir bildeten eine Hypothese über ein Problem, das noch gar nicht eingetreten war – allein auf Grundlage dessen, wie zwei Menschen in einem einzigen Meeting miteinander sprachen.

Die Vorhersage hätte falsch sein können. Sie war in dem Moment, in dem wir sie trafen, nicht garantiert.

Möglich wurde das, weil wir das Verhaltenssignal als eigenständigen Beleg behandelten – nicht als Fußnote zum Gesagten.

Eine Hypothese, die sich später bestätigt, ist kein Zufall. Sie ist das Ergebnis, wenn man Verhalten als Daten behandelt, bevor man dazu gezwungen ist.