Bis heute fällt es mir schwer zu sagen, was der Kern von OrgIQ.org ist. Klar es geht um Kollaboration. Aber warum so und warum funktioniert es?
Und wenn ich zu sehr in die Neurologie, Psychologie, Kybernetik oder Anthropologie eintauche, dann verliere ich immer paar Menschen auf dem Weg. Je nachdem woher wer kommt.
Wobei Psychologie/Neurologie finden viele spannend, weil es eben um uns Menschen geht. Darin finden wir uns alle wieder.
Aber dafür gibt in Unternehmen nicht wirklich jemand Geld aus, weil das eben “nice to have” ist, aber nicht wirklich was bringt.
Tatsächlich geht es mir um eine intelligente Organisation. Und Organisation kann von der Familie bis zum Konzern alles sein. Und intelligent bedeutet nur “ich habe die Fähigkeit gut zu überleben”. Also wahrnehmen, vorausschauen, lernen, anpassen.
Und das mit so wenig Energie wie möglich. Intelligente Systeme sind sparsam. Sie geben das aus, was etwas bringt. Aber alle unnütze Reibung kann weg.
Und dafür brauchen sie eine passende Architektur. Denn die Architektur beschriebt das System. Und da ich aus der Software komme, nutzen wir doch das Wissen und die Erfahrung aus 34 Jahren Software-Architektur. Denn was bei Software klappt (das ist ja immer noch das Komplizierteste und Komplexeste was Menschen je gebaut haben), wird auch in Organisationen funktionieren.
Schauen wir uns meine persönliche Favoriten an…
Zwei Dimension
Funktionale Betrachtung machen wir alle. Aber da ist die Architektur eigentlich egal. Wir müssen nur alles unterbekommen.
Architektur organisiert Funktionen (oder Themen, Milieus, Silos) so, dass die nicht-funktionalen Anforderungen optimal umgesetzt werden. Das ist die Kunst.
Und während uns die funktionalen Themen alle mehr oder weniger bekannt sind (oben), tun wir uns mit den nicht-funktionalen Themen (unten) schwerer. Natürlich brauchen und wollen wir die, aber wir wussten eben nie, wie man die organisieren kann.
Und das ist der blinde Fleck bei fast jeder Organisation. Denn diese Elemente gelten überall. Sie werden also nicht über funktionale Einheiten abgebildet, sondern über eine entsprechende Architektur sichergestellt. Die Umsetzung liegt also in der Struktur und in der Qualität der Kanten, nicht in neuen Knoten.
Diese “nicht-funktionalen” Elemente, letztlich sind da alle Werte drin kodiert und noch viel mehr, setzten wir immer um. Das macht jede Organisation zwangsweise. Die Frage ist wieder “zu welchen Kosten”?
Wir können es einmal in die Architektur einbauen, dann ist es sicher, gesteuert und effizient, oder wir machen es zur Laufzeit jedes mal völlig unklar und ungesteuert.
Da es die meisten Organisationen unbewusst machen, ist es “ad hoc” zur Laufzeit. Das schafft die meiste Unruhe, Verwirrung und Kosten. Extrem viel Reibung. Das hat viele Gründe. Einer ist, dass es eben nicht stimmig mit der definierten und gelebten Architektur ist, aber eben auch, dass es jede Person nach bestem Wissen und Gewissen macht. Da gibt es dann enorme Streuung und damit Reibung.
Schnittstelle oder Gateway?
Warum haben wir in Populationen Spezialisten und Generalisten?
Wer denkt, dass der Text jetzt nicht zur Überschrift passt, muss sich nur wenige Sekunden gedulden.
Also innerhalb eines “Milieus”, also eines thematischen Architektur-Bereichs, einer Funktion, verstehen wir uns. Weltbilder, Sprache und Denkmuster sind sich nah genug. Innerhalb eines Bereichs haben wir einfache Schnittstellen. Ich dar Verständnis voraussetzen.
Wenn wir aber zwischen Bereichen kommunizieren, brauchen wir eine Übersetzung. Das sind Gateways: Wie unsere Übergänge von Flugzeug zu Zug, oder Zug zu S-Bahn, oder S-Bahn zu U-Bahn. Alles hat miteinander zu tun, aber es sind unterschiedliche Technologien und Regeln.
Gateways (zum Beispiel zwischen den “Silos”) brauchen also Übersetzung und Integration. Übersetzung in beide Richtungen, dass beide Seiten sich verstehen. Und die Integration, damit alles einem gemeinsamen Zweck dient. Das ist wie bei einer Reise: Für den Kunden zählt der Weg von Tür zu Tür. Je transparenter die einzelnen Unterschiede werden, desto besser. Wir wollen die verschiedenen Technologien, Ticket-Formate und Abrechnungen vor dem Kunden verstecken. Und je besser wir das machen, desto besser ist die Integration.
Damit sind wir am Anfang angekommen: Während die Spezialisten tief im Thema drin sind, bilden Generalisten die natürlichen Gateways. Im Bild oben sind das die Grenzbereiche. Dort sitzen die Generalisten als Gateways. Wenn möglich sogar über mehrere Funktionen. Wir müssen sie nur kennen und passend einsetzen.
Zwei Zeiten: Design-Zeit und Laufzeit
Kommen wir noch mal zum Anfang, zu Leadership. Leadership ist die Verantwortung für das System. Simon Sinek hatte es fast richtig dargestellt, als er sagte, dass die Leader verantwortlich für die Leute sind, die verantwortlich für die Outcomes sind.
Aber nur fast richtig. Ich kann nicht wirklich verantwortlich für erwachsene Menschen sein, ohne dass es sofort wieder dysfunktional ist.
Daher bin ich als Leader für das System, die Umgebung, verantwortlich. Und ich baue eine Umgebung, in der die Wahrscheinlichkeit, dass es “optimal läuft” extrem hoch ist.
Also Leadership ist der Bau und die Pflege des Systems.
Deswegen sollte Leadership nie in den Betrieb des Systems eingebunden sein. Wenn ich in einer Führungs- oder Management-Rolle im operativen Ablauf involviert bin oder sogar “führen” muss, dann bedeutet das nur, dass dem System Richtung und Klarheit fehlt. Das ist dann nämlich nicht führen, sondern nachsteuern. Nacharbeit.
Alles was ich vorher vergessen habe, muss ich dann zur Laufzeit korrigieren. Das wäre so, als ob ein Programmierer einen Fehler in der Software drin lässt und bei jeder Ausführung das Ergebnis korrigiert. Kann man so machen, ist aber nicht sparsam.
Führung- oder Management im operativen Ablauf bedeutet vor allem unnötige Kosten. Dazu kommen Folgekosten, die durch Unklarheit und Unsicherheit entstehen.
Wir müssen bei Systemen also das System-Design von der Laufzeit unterscheiden. Design ist Führung und Laufzeit ist Kollaboration.
Wenn wir also die Collaboration Capability Maturity messen, dann ist es indirekt das System-Design. Wir schauen, wie gut die Architektur wirklich zur Laufzeit des Systems ist. Ist es intelligent und sparsam?
Produkt- & Organisationsentwicklung in einem Kästchen?
Noch eine operative Beobachtung, die aber mit der Architektur zu tun hat. Auch wenn ich es noch nirgendwo richtig gesehen habe.
Bei der operativen Themen ist Produkt- und Organisationsentwicklung ein Kästchen. Also R&D und Prozess-Management zusammen. Oder besser: Produkt-Architektur und Organisations-Architektur als Einheit.
Das klingt erstmal merkwürdig, weil es eben völlig unterschiedliche Bereiche und Skills sind. Auch unterschiedliche Standards, denen ich folgen muss.
Was uns verbindet ist Conway. Denn Conway’s Law gilt ohnehin.
“Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure”
„Jede Organisation, die ein System (im weitesten Sinne) entwirft, wird ein Design hervorbringen, dessen Struktur ein Abbild der Kommunikationsstruktur der Organisation ist.“
Was das Gesetz sagt ist, dass die Organisationsstruktur ohnehin immer führen wird. Nicht die aufgemalte Struktur, sondern die Laufzeit. Wenn die Laufzeit das Modell der Nachsteuerung ist, also Modell “kopfloser Hühnerhaufen”, dann werden wir das in der echten Produkt-Architektur auch wiederfinden.
Wenn wir also clever sind, dann bauen und leben wir Organisation so, dass es zum Produkt (oder der Dienstleistung) passt. Und wir begnügen uns nicht nur mit dem Entwurf, sondern stellen vor allem eine saubere Architektur zur Laufzeit sicher.
Und nun?
Also eine intelligent Organisation hat eine intelligente Architektur. Und wenn wir an Leadership denken, dann wissen wir jetzt: Leadership ist aktiv im Design und untätig zur Laufzeit.
Wenn wir in der Laufzeit eingreifen wollen und müssen, dann sind wir die Störung. Und wir haben unseren Job beim Design nicht gut gemacht. Gutes Leadership geht immer wieder zurück zum Design und repariert das System, anstatt die Störungen zu vergrößern. Das gibt Struktur und Richtung. Und es ist ein extrem einfacher Test, ob wir an der richtigen Stelle unterwegs sind.
Leave a Reply