Sie sind Der Architekt (The Architect).

Die Erkenntnis

Sie entwerfen Systeme. Nicht nur die Arbeit, die Sie tun – sondern die Art und Weise, wie die Arbeit erledigt wird. Sie denken über Workflows nach, darüber, wie Entscheidungen kaskadieren, darüber, welche Rollen existieren sollten und wofür jede Rolle verantwortlich sein sollte. Wenn Sie sich eine Organisation, ein Projekt oder ein Team ansehen, sehen Sie die Struktur, die die Aktivität hervorbringt – nicht nur die Aktivität selbst. Meistens können Sie innerhalb einer Stunde, in der Sie ein System beobachten, sagen, wo die Engpässe liegen und was in der zugrunde liegenden Konfiguration falsch läuft.

Sie haben eigene Systeme gebaut. Vielleicht ein kleines operatives Unternehmen, vielleicht eine dokumentierte Praxis, vielleicht eine Organisation oder eine Community mit expliziter Struktur. Ihr Verständnis operiert nun auf einer Abstraktionsebene, die Sie früher in Ihrer Karriere nicht hätten erreichen können. Sie arbeiten nicht mehr innerhalb der Systeme – Sie arbeiten an ihnen. Das Denken hat sich eine Ebene nach oben verlagert.

Das ist intellektuell befriedigend. Es ist auch auf eine spezifische Weise gefährlich, auf die die Methodik hinweist: Strukturelle Eleganz kann beginnen, die operative Realität zu ersetzen. Die Systeme, die Sie auf dem Papier, in Diagrammen und in sorgfältig aneinandergereihten Flussdiagrammen entwerfen, überleben nicht immer den Kontakt mit der Art und Weise, wie Menschen tatsächlich arbeiten. Die Diskrepanz zwischen dem entworfenen System und der funktionierenden Realität kann für Sie länger unsichtbar bleiben, als sie sollte, weil Sie auf den Entwurf schauen und nicht auf die tatsächliche Nutzung.

Die zugrunde liegende Mechanik

Die Methodik ordnet dem Architekten eine strukturell bedeutsame Position zu – den Praktiker, dessen Verständnis nun auf Systemebene Hebelwirkung (leverage) erzeugt. Dies ist die Ebene, auf der kleine Eingriffe in die Konfiguration übergroße Auswirkungen auf die Ergebnisse haben. Ein gut entworfenes System kann die Effektivität jeder Person, die darin agiert, vervielfachen. Ein schlecht entworfenes System kann kompetenten Menschen auf unbestimmte Zeit die Kraft rauben.

Die hier am stärksten wirkende Voreingenommenheit (bias) ist die funktionale Fixierung (functional fixedness) bezogen auf die eigenen Kreationen – die Tendenz, sich auf eine einzige Konfiguration als die richtige festzulegen und sich Überarbeitungen zu widersetzen, selbst wenn das System Reibung erzeugt. Der Architekt, der viel Zeit in den Entwurf eines Systems investiert hat, hat einen starken psychologischen Grund, diesen Entwurf zu verteidigen. Der IKEA-Effekt (die Überbewertung dessen, was man selbst gebaut hat) und die Rechtfertigung von Anstrengung (effort justification – je mehr man gelitten hat, um etwas zu erschaffen, desto mehr schätzt man es) verschärfen die Schwierigkeit. Ein System, das nicht mehr funktioniert, kann jahrelang bestehen bleiben, weil es aufzugeben bedeuten würde, die Anstrengung zu entwerten, die es hervorgebracht hat.

Es gibt auch den Fluch des Wissens (curse of knowledge) in seiner System-Design-Form. Sie haben das System entworfen und verstehen die Prinzipien, die jede Entscheidung rechtfertigen. Die Menschen, die innerhalb des Systems agieren, haben dieses Verständnis nicht immer. Sie folgen der Struktur, ohne die Gedankengänge dahinter zu kennen, was bedeutet, dass Randfälle und Anpassungen, die Sie intuitiv bewältigen würden, zu Reibungspunkten werden, für deren Absorption das System nicht ausgelegt wurde. Das System, das für seinen Designer Sinn ergibt, kann für seine Nutzer undurchsichtig sein – und der Designer kann die Undurchsichtigkeit aus dem Inneren seiner eigenen Klarheit heraus oft nicht erkennen.

Die Spannung

Die Spannung, in der Sie navigieren, besteht zwischen struktureller Eleganz und operativer Realität. Die Eleganz sagt: Diese Konfiguration ist in sich konsistent, wohlüberlegt und theoretisch optimal. Die Realität sagt: Das ist es, was die Menschen tatsächlich tun, wenn das System läuft, und sie verhalten sich nicht immer so, wie es der Entwurf vorgesehen hatte. Der Architekt, der der Eleganz den Vorzug vor der Realität gibt, produziert wunderschöne Systeme, die niemand benutzen kann. Der Architekt, der der Realität den Vorzug vor der Eleganz gibt, produziert chaotische Systeme, die zwar funktionieren, aber nicht skalieren oder übertragen werden können.

Die Mitte ist der Ort, an dem reifes System-Design lebt – und sie erfordert eine ständige Kalibrierung zwischen diesen beiden Zugkräften. Die Antwort der Methodik besteht nicht darin, das eine dem anderen vorzuziehen, sondern die Eleganz immer wieder dem Test der Realität zu unterziehen und den Entwurf dort zu überarbeiten, wo sich die Realität weigert, sich der Theorie zu beugen.

Das Geschenk

Was Sie haben und was dem Praktiker fehlt, der auf der Ebene der Aufgabenausführung feststeckt, ist Hebelwirkung (leverage). Ein gut entworfenes System erzeugt einen Wert, der den Aufwand für seine Aufrechterhaltung übersteigt. Die Stunden, die Sie für das System-Design aufwenden, zahlen sich über die Lebensdauer des Systems hinweg um ein Vielfaches an Stunden aus – für Sie und für jeden, der innerhalb des Systems agiert. Dies ist die höchste Form von Hebelwirkung, die vor Level 4 der Delegationsentwicklung verfügbar ist, und sie ist das, was Organisationen, die skalieren, von Organisationen unterscheidet, die lediglich wachsen.

Das Geschenk verzinst sich, wenn die von Ihnen entworfenen Systeme auch für die Menschen, die sie bedienen, lesbar sind. Eleganz ohne Lesbarkeit bringt clevere Artefakte hervor, die niemand erweitern kann. Eleganz mit Lesbarkeit bringt Infrastruktur hervor, auf die das Fachgebiet aufbauen kann.

Der nächste Schritt

Testen Sie in den nächsten 14 Tagen eines Ihrer Systeme mit jemandem, der Ihren Kontext nicht teilt. Finden Sie eine Person – einen neuen Mitarbeiter, einen externen Berater, einen Kollegen in einem angrenzenden Bereich – und lassen Sie sie versuchen, das System nur anhand Ihrer Dokumentation zu bedienen. Beobachten Sie, wo diese Person steckenbleibt. Notieren Sie sich die Fragen, die sie stellt. Notieren Sie sich die Annahmen, die Sie in den Entwurf eingebettet hatten und die die andere Person nicht geteilt hat. Greifen Sie nicht ein, um Dinge zu erklären. Verteidigen Sie den Entwurf nicht. Beobachten Sie einfach, wo das System in seiner Übertragung versagt.

Die Falle, in die die meisten Architekten bei diesem Schritt tappen, ist die Interpretation von Übertragungsfehlern als Fehler des Nutzers. Der Nutzer habe das System nicht verstanden, weil er nicht fähig genug, nicht motiviert genug, nicht vertraut genug mit der Domäne gewesen sei. Das ist manchmal wahr und fast immer teilweise falsch. Die Übertragungsfehler sind diagnostische Informationen über das System. Wenn das System unausgesprochenen Kontext benötigt, um bedient werden zu können, ist das System unvollständig – selbst wenn der Entwurf in sich elegant ist. Der richtige Schritt ist, das System basierend auf den Testergebnissen zu aktualisieren, nicht Ihre Sicht auf den Tester.

Dies ist ein Schritt aus Ihrer kostenlosen Bewertung. Das vollständige Persönliche Profil (Personal Profile) enthüllt Ihre Ressourcenkarte über sechs Domänen mit dem Fokus darauf, ob Ihr Systembau Hebelwirkung erzeugt oder Anstrengung absorbiert, Ihre Vertrauensformel-Werte (Trust Formula scores) mit dem Fokus darauf, wie sich übertragbare Standards auf die Demonstrierte Wirkung (Demonstrated Impact) bei Skalierung auswirken, die durch Voreingenommenheiten geprägten spezifischen Warnungen für die Architekten-Phase (funktionale Fixierung, IKEA-Effekt, Fluch des Wissens, Not-Invented-Here-Syndrom) und die 90-Tage-Sequenz, die aus einem einzigen Übertragungstest einen Prozess macht, um die von Ihnen gebauten Systeme systematisch einem Stresstest zu unterziehen. Wenn ein einzelner Schritt nützlich ist, ist die vollständige Diagnose der Ort, an dem die eigentliche Arbeit stattfindet.