Das dritte Ding

Soweit ich das überblicke, gibt es genau zwei ehrliche Arten, Software von einer anderen Firma zu kaufen.

Du kannst ein Produkt kaufen. Sie behalten ihren Code, ihre Roadmap und ihre Distanz. Du bekommst klare Schnittstellen, Dokumentation und das Recht, dich anderswo umzusehen. Ob ihre Versprechen vage sind, ist ihre Sache. Du hast sie für das gewählt, was sie heute können, und nichts in deinem Plan steht oder fällt damit, was sie nächstes Jahr vielleicht tun.

Oder du kaufst eine Dienstleistung. Sie arbeiten in deinem Backlog, auf deiner Infrastruktur, nach deinen Prioritäten, und alles, was sie bauen, gehört dir. Bezahlt werden sie pro gelieferter Story. Wenn es nicht mehr passt, ersetzt du sie und behältst die Software. So einfach ist das.

An Katastrophen herrscht in der Unternehmens-IT kein Mangel. Aber eine bestimmte Sorte beginnt immer gleich: Jemand unterschreibt einen Vertrag für ein drittes Ding. Diesen Film habe ich inzwischen ein paarmal gesehen.

Klar sieht das auf dem Papier vernünftig aus. Der Lieferant behält sein geistiges Eigentum, wie eine Produktfirma. Aber er betreibt auch, was er baut, auf deinen Cloud-Accounts, wie eine Dienstleistungsfirma. Seine Tickets leben in seinem Jira, in das du nicht hineinschauen kannst. Sein Code ist eine Blackbox. Seine Server treiben deine Rechnung hoch, und nicht mal ihre Größe darfst du bestimmen. Eigentum, Betrieb, Sichtbarkeit: Alle drei zeigen jetzt in verschiedene Richtungen, und keine davon zeigt auf dich.

Was jetzt folgt, ist aus allen Fällen zusammengesetzt, die ich miterlebt habe. Zuerst kommt die Tabelle. Jemand muss den Fortschritt des Lieferanten verfolgen. Dessen Tickets sind unsichtbar. Also erscheint eine Excel-Tabelle, von Hand gepflegt, Dutzende Spalten, mehrere davon dieselbe Spalte unter verschiedenen Namen, jede Zeile der Schatten eines Tickets, das längst irgendwo lebt, wo du nicht hinsehen kannst. Es ist verlockend, über die Tabelle zu lachen, aber lass es. Die Tabelle ist Narbengewebe, und jede Schatten-Tabelle in deiner Firma markiert eine Stelle, an der die Organisation ein gemeinsames Werkzeug aufgegeben und sich stattdessen einen Workaround gezüchtet hat.

Als Nächstes kommt das Meeting, und darüber könnte ich mich stundenlang aufregen. Zwischen den Meilensteinen ist der Fortschritt des Lieferanten unsichtbar, also erscheint ein täglicher „Sync“-Call, damit jemand den Lieferanten fragen kann, wie es denn so läuft. Dutzende Leute werden eingeladen. Ein paar sagen ab. Die meisten antworten gar nicht, denn Absagen und Zusagen sind beides Festlegungen, und die sicherste Antwort ist manchmal gar keine. Ein Dutzend erscheint tatsächlich, jeden Morgen, für eine halbe Stunde. Die Einladung will nützlich sein, aber sie ist eine verkleidete Statusabfrage. Denn wenn Systeme sich nicht synchronisieren dürfen, werden Menschen zum Sync-Mechanismus, und dieser hier läuft über die Gehaltsliste. Ein Dutzend Leute, eine halbe Stunde, fünf Tage die Woche, für immer. Alles der Preis dafür, kein gemeinsames Ticketsystem zu haben.

Bei den Seiten, die dazukommen, juckt dir vielleicht das Gesicht. Jemand legt eine Confluence-Seite für ein Thema an, das am Ende sowieso in Jira landet. Monate später ist die Seite zugemüllt, und Aufräumen wäre mehr Arbeit, also archiviert man sie und klont eine frische Kopie. Meinetwegen. Nur zeigt der Link in der Serieneinladung weiter auf die alte Seite, und das wird er noch Jahre tun, denn wer bearbeitet schon Meeting-Serien. Und es ist wirklich keine Böswilligkeit, das ist ja das Ärgerliche. Jeder Schritt war eine kleine Bequemlichkeit, die sich für sich genommen verteidigen ließ.

Und jetzt sieh dir die Trümmer an, das reinste organische Chaos. Die Fakten sind nirgends zu finden, und zwar nicht, weil Information versteckt wurde, sondern weil sie sich vervielfältigt hat, bis niemand mehr sagen konnte, was aktuell ist und was nicht. Die Wahrheit geht schlicht im Gerümpel unter.

Und über allem legt sich eine Art zu reden. „So bald wie möglich.“ „Wo es sinnvoll ist.“ „Mit höchster Priorität.“ „Das müssen wir erst untersuchen.“ Hör diesen Sätzen zu, wie ein Ingenieur zuhört: Keiner von ihnen kann jemals falsch sein. Was wie ein Kompliment klingt, bis du kurz darüber nachdenkst. Ein Satz, der nicht falsch sein kann, trägt keine Information; er schließt nichts aus. Staple genug davon aufeinander, und ein Statusbericht wird mit jeder möglichen Realität vereinbar, und genau das brauchen alle von ihm. Der Philosoph Harry Frankfurt definierte Bullshit als Rede, der die Wahrheit gleichgültig ist. Er hat eine ganze Monografie darüber geschrieben. Er hätte auch einfach eine Projekt-Statusseite lesen und sich die Mühe sparen können.

Der Dialekt hat Zeitformen, was mir erst nach einer Weile aufgefallen ist. Arbeit lebt im Futur: Aus „Wir schauen uns das nächste Woche an“ wird „Wir haben es uns angeschaut, und wir gehen es nächsten Monat an“. Das Sich-Anschauen ist ein Liefergegenstand, der ein weiteres Sich-Anschauen hervorbringt; der Horizont rollt weiter, die Einheit bläht sich auf, aus der Woche wird ein Monat. Die Eskalation hat ihr eigenes Genre, die Eskalation, die nichts liefert außer der Tatsache ihrer selbst, kein Datum dran, keine Auswirkung benannt. Und wenn ein Status-Badge endlich von Gelb auf Rot springt, lies die Seite darunter: Die Sätze sind dieselben. Die Farbe wechselt, der Dialekt nicht. Rot ist nur Gelb mit Gewaltandrohung.

Was den Dialekt fast unmöglich zu bekämpfen macht: Er ist weder das ganze Dokument noch eine einzelne Person. Echte Statusseiten tragen ehrliche, gut kalibrierte Sätze direkt neben den ausweichenden, also kannst du nicht der Seite widersprechen, nur einzelnen Stellen, und einzelnen Stellen zu widersprechen klingt nach Pedanterie. Und der Dialekt ist ein Chor, kein Solist. „Kommt darauf an.“ „Das müssen wir untersuchen.“ „Das kann ich dir nicht sagen.“ Wenn genug Münder diese Dinge sagen, hört der Dialekt auf, jemandes Persönlichkeit zu sein, und wird zur Muttersprache des Raums, zu dem, was Neue als Onboarding aufsaugen.

Seniorität vollendet den Trick, und zwar nicht, weil der Veteran blufft. Wenn jemand mit Jahrzehnten im System „kommt darauf an“ sagt, kommt es meistens wirklich darauf an. Er hat schon selbstbewusste Antworten zusammenbrechen sehen. Das Problem ist, dass der Raum verdiente Vorsicht nicht von Ausweichen unterscheiden kann, und beides kommt als dieselben drei Wörter heraus. Also darf sich jede leere Floskel im Chor die Glaubwürdigkeit des Veteranen leihen, und Vagheit, von weit genug oben gesprochen, wird als Weisheit gehört.

Falls das nach deinem Projekt klingt: Ich verspreche dir, ich habe nicht dein Projekt beschrieben. Das ist das Vernichtendste, was ich sagen kann. Es klingt nach allen.

Warum wächst das alles? Hier ist eine Szene, zusammengesetzt wie der Rest. Ein Lieferant bekommt eine Frage vorgesetzt, die nur ein Infrastrukturteam beantworten könnte. Eine Kostenanalyse, ein Kapazitätsplan, such dir was aus. Der Grund: Seine Server stehen unterausgelastet auf einer Rechnung, die der Kunde bezahlt. Der Lieferant ist in dieser Szene ein Raum voller Wissenschaftler. Brillant in genau dem, wofür man sie geholt hat. Keine Infrastrukturleute. Alle im Raum wissen beides, auch der Manager, der jetzt den Satz sagt, den Manager in dieser Lage immer sagen. Er kommt in drei Teilen: Das ist eure Verantwortung, wie ist mir egal, und wenn es nicht passiert, landen die Kosten bei euch.

Es ist verlockend, diesen Satz als schlechtes Management zu hören, aber er ist ein Produkt der Verzweiflung. Der Manager kann den Code nicht reparieren, der ist eine Blackbox. Kann den Betrieb nicht übernehmen, der Vertrag sagt, der Lieferant betreibt. Kann der Arbeit nicht mal zusehen, die Tickets leben in einem Jira, das niemand im Raum öffnen kann. Jeder echte Hebel wurde vor Jahren per Unterschrift abgegeben. Was bleibt, ist Verantwortung zuweisen und mit Kostenübertragung drohen. Schuldzuweisung ist das, was von Management übrig bleibt, wenn jeder echte Hebel wegverhandelt wurde.

Beachte, was die Drohung tatsächlich wert ist. Verantwortung jemandem zuzuweisen, dem die Fähigkeit fehlt, terminiert nur die Schuldzuweisung im Voraus. Wer die Server dimensioniert, bezahlt sie nicht, und Unterauslastung ist das Ergebnis. Und wenn das Geld Jahre vor der Arbeit gebunden wurde, ist die Kostendrohung Theater auf Theater: Das Geld ist längst ausgegeben. Jeder im Raum weiß das alles. Der Satz wird trotzdem gesagt. Ihn zu sagen ist der einzige Zug, der auf dem Brett noch übrig ist.

Was kommt bei dem Druck heraus? Nicht die Antwort. Die können sie nicht liefern. Heraus kommt stattdessen Sprache: „Wir schauen uns das nächste Woche an.“ Schuld fließt nach unten, Floskeln fließen nach oben, und beide Seiten gehen mit einer Papierspur nach Hause, die beweist, dass sie ihren Teil getan haben. Schuld rein, Bullshit raus. Der Dialekt ist einfach, wie Leute in einem kaputten Modell zurechtkommen.

Der Instinkt des Ingenieurs an dieser Stelle ist, etwas zu bauen. Ich habe ihn selbst gespürt, und ich habe ihn bei anderen gesehen: Vor einem unsichtbaren Lieferanten-Backlog will man aus purem Instinkt ein Werkzeug skizzieren, das Tickets zwischen den beiden Jiras synchronisiert. Das ist eine dumme Idee, und es dauert ungefähr eine Woche ehrlichen Nachdenkens, um zu sehen, warum. Die Grenze verschwindet nicht. Jemand müsste für immer entscheiden, welche Tickets sie überqueren. Der Sync selbst ist ein weiteres Stück Software, das gewartet werden will. Und nach all der Arbeit hast du dir einen perfekten Blick auf Tickets erkauft, auf die du weiterhin nicht einwirken kannst. Du würdest alles sehen und nichts ändern. Aus einem Problem, das die Form eines Vertrags hat, kannst du dich nicht herausbauen; jede neue Kopie der Wahrheit, so clever sie ist, reiht sich nur in die Menge ein, die sie in die Unterzahl bringt. So etwas wie „kann nicht schaden“ gibt es in einem Projekt nicht. Alles, was nicht aktiv hilft, behindert aktiv.

Die Reparatur wohnt dort, wo der Bruch wohnt, im Modell. Wenn ein Lieferant zwei Jobs macht, teile sie in zwei Beziehungen. Dieselben Leute, wenn du willst; andere Formen. Die eine Hälfte wird eine echte Produktfirma. Sie behält ihren Code und ihre Roadmap, veröffentlicht Updates quartalsweise oder jährlich, verfolgt ihre eigenen Issues und schuldet dir klare Schnittstellen statt Transparenz. Du installierst ihre Blackbox auf deiner Infrastruktur, du betreibst sie, du baust deine eigenen Adapter darum, und du behältst das Recht zu gehen. Die andere Hälfte wird ein echtes Serviceteam. Sie arbeiten in deinem Jira, auf deinen Systemen, in deinem Auftrag. Was sie bauen, gehört dir, sie werden pro gelieferter Story bezahlt, und sie sind per Konstruktion ersetzbar. Du verlierst etwas bei der Teilung: Die Produkthälfte wird dir immer nur eine Roadmap geben, nie ein Datum. Aber sieh, was du zurückbekommst. Die Servicehälfte arbeitet jetzt dort, wo du sie sehen kannst, du weißt also genau, wann etwas die Produktion erreicht, und der Schalter, der ein Feature in deiner Welt einschaltet, liegt endlich in deiner Hand.

Beide Hälften davon existieren. AWS und Microsoft veröffentlichen Roadmaps für Hunderttausende Kunden, und diese Roadmaps versprechen so gut wie nichts. Niemand geht daran unter, denn die Architektur des Kunden hängt nie an diesen Versprechen; die Vagheit bleibt auf der anderen Seite einer Schnittstelle, wo sie bloß ein Wetterbericht ist. Hol dieselbe Vagheit in dein eigenes Backlog, und dein Release-Datum hängt plötzlich an einem „Wir schauen uns das an“. Das ist das Gesetz, das sich unter diesem ganzen Essay versteckt: Bullshit-Toleranz ist eine Funktion der Kopplung. Und es zeigt auf die echte Reparatur. Von Menschen unter Druck mutigere Sätze zu verlangen repariert nichts. Du arbeitest daran, das Modell zu reparieren, bis schlichte Sätze wieder bezahlbar sind.

Also prüfe deine Lieferanten. Vier Fragen: Wem gehört der Code, wer betreibt ihn, wer bezahlt die Rechnung, wer kann die Arbeit sehen. Wenn sich die Antworten nicht zu einer der beiden ehrlichen Formen fügen, musst du nicht auf die Katastrophe warten; geh über den Projektflur, und du findest sie schon beim Wachsen. Eine Tabelle, die sich selbst wiederholt. Ein Daily, das die Leute ignorieren oder nur zähneknirschend annehmen. Eine Seite, die niemand findet. Ein Raum voller anständiger Leute, die eine Sprache sprechen, in der nichts falsch sein kann.

Ich tue nicht so, als wäre das alles im Brownfield leicht zu reparieren. Verträge wie das dritte Ding werden für Jahre unterschrieben, und das Problem klar zu sehen garantiert noch nicht das Standing, es laut auszusprechen. Aber Beständigkeit wirkt in beide Richtungen. Ein kaputtes Modell überdauert, weil es die Menschen überlebt, die dagegen ankämpfen. Ein repariertes Modell überdauert auf genau dieselbe Weise. Repariere die Form einmal, und die Reparatur wirkt noch lange, nachdem alle Beteiligten das Projekt gewechselt haben. Einmal gehört zu werden genügt. Und die Chancen, gehört zu werden, kommen immer wieder: jede Verlängerung, jede Erweiterung, jede Krise, in der eine Drohung ausgesprochen wird, weil nichts anderes mehr übrig ist.

Und wenn die Chance kommt, denk daran: Die Teilung kostet niemanden den Job. Dieselben Leute, sortiert in Formen, in denen sie an dem gemessen werden, was sie wirklich gut können. Die Wissenschaftler dürfen Wissenschaftler sein. Der Manager bekommt echte Hebel statt Schuldzuweisungen. Niemand muss mehr die Tabelle pflegen oder das Daily absitzen oder in Floskeln antworten. Das ist die hoffnungsvollste Tatsache an alledem. Niemand in diesen Räumen will den Bullshit. Nicht der Veteran, nicht der Manager, nicht der Lieferant. Also stell die vier Fragen, laut, selbst wenn du die neueste Person im Raum bist; eine Frage ist keine Anklage. Menschen kehren zu schlichten Sätzen zurück, sobald es wieder bezahlbar ist. Nicht die Menschen musst du reparieren, sondern das Modell.