Overcompliance

Wer versucht in grossen Organisationen Bürokratie zu bekämpfen, der wird möglicherweise an der folgenden paradoxen Situation vorbeigekommen sein: während die Ausführungs-Ebene unter der Last der Prozesse und Vorschriften ächzt, ist sich die Führungsebene keiner Schuld bewusst, und kann sogar darauf verweisen, dass das offizielle Regelwerk sogar relativ schlank ist. Für diesen scheinbar widersinnigen Zustand gibt es einen häufigen Grund: Overcompliance.

Um das besser begreifen zu können schauen wir uns zunächst den zugrundeliegenden Begriff an: die Compliance. Hinter ihm verbirgt sich die anzustrebende Regelkonformität von Unternehmen, Behörden und sonstigen Organisationen, also die Einhaltung von Gesetzen, Richtlinien und internen Vorschriften. Compliance zu haben (bzw. Compliant zu sein) ist als Folge dessen das Ziel zahlreicher Prozesse, Tätigkeiten und Organisationseinheiten, die nur zu diesem einen Zweck existieren.

Das Problem bei der Herstellung von Compliance ist allerdings, dass es an ihren Rändern eine Grauzone gibt. Ab wann wird aus einer Routine ein zu dokumentierender Prozess? Gibt es Bagatellgrenzen für Zeit-, Qualitäts- und Budgetabweichungen? Wann können Anweisungen mündlich erfolgen, wann ist die Text-Form ausreichend und wann ist die Schriftform nötig? Alle diese Fragen sind in den Einzelfällen nicht immer eindeutig zu beantworten und lassen einen Interpretationsspielraum offen.

So lange dieses freie Interpretieren innerhalb der Grauzone keine negativen Folgen hat, ist das auch meistens unproblematisch, schwierig kann es aber werden, wenn das zu Unfällen, Qualitätsmängeln oder versehentlichen Regelverstössen führt. Viele Organisationen kehren in derartigen Situationen den Interpretationsspielraum um - alles woraus sich eine wie auch immer geartete Verantwortlichkeit ableiten lässt, wird rückwirkend zur Norm erklärt - oft mit disziplinarischen Folgen für die Betroffenen.

Und an dieser Stelle kommt es zur Overcompliance: um nicht ebenfalls oder erneut für etwas zur Verantwortung gezogen zu werden, was sich innerhalb einer Grauzone abspielt, beginnen die Mitarbeiter jetzt die jeweils strengste (und für sie sicherste) Auslegung der Gesetze, Richtlinien und internen Vorschriften anzuwenden. Im Zweifel also alles dokumentieren und schriftlich genehmigen zu lassen, und bereits kleinste Abweichungen zu verfolgen und zu eskalieren.

Bereits das kann lähmende Auswirkungen auf nahezu alle Abläufe haben, im schlimmsten Fall kann es aber sogar noch schlimmer werden - wenn es als Reaktion auf eine kontrollierende und überwachende Variante der Overcompliance dazu kommt, dass selbst für kleinste Aufwände explizite und schriftliche Anweisungen und Abnahmen nötig sind (gewissermassen Gegen-Overcompliance), ist es nicht mehr weit bis zu gegenseitigen Blockaden und bis zum totalen und dauerhaften Stillstand.

Um sich aus einer derartigen Situation zu befreien (oder um es gar nicht erst soweit kommen zu lassen) sind zwei Dinge notwändig: zum einen muss man akzeptieren, dass sich nicht alle Eventualitäten vorhersehen und mit vertretbarem Aufwand regulieren lassen, und zum anderen muss man darauf verzichten, nach in Grauzonen stattgefundenen Unfällen, Qualitätsmängeln oder versehentlichen Regelverstössen immer nach einem Schuldigen zu suchen und ihn bestrafen zu wollen.¹

Was darüber hinaus ein sinnvolles Werkzeug für die Verhinderung von Overcompliance sein kann, ist eine Vereinbarung, bei allen Regel-Umsetzungen immer die am wenigsten restriktive Variante anzustreben und von anderen zu fordern. Idealerweise kann das sogar Teil eines "Gesellschaftsvertrages" werden, an dem sich die gemeinsame Zusammenarbeit ausrichtet und auf den man sich bei Prozessgestaltungen, in Konflikten und bei Meinungsverschiedenheiten berufen kann.

Ein Bild sagt mehr als 1000 Worte (XLVI)

Grafik: Forrest Brazeal - CC BY-NC-ND 4.0

Thermal Teams

Bild: Pixabay / Ferafba - Lizenz

Fast immer wenn in grossen Organisationen der Handlungsdruck gross ist, Termine stark in Gefahr geraten oder irgendwie Nichts weitergeht, werden Task Forces gegründet - kleine, crossfunktionale und auf eine einzige Aufgabe focussierte Einheiten, die die anstehenden Aufgaben schnell erledigen können. Eine Frage die in solchen Situationen häufig gestellt wird ist die, ob sich dieser Arbeitsmodus nicht formalisieren lässt, um in Zukunft von Anfang an derartig lieferfähig sein zu können.

Die Antwort: natürlich geht das, und in verschiedenen Unternehmen gibt es auch Beispiele dafür. Ein prominentes sind die Thermal Teams oder Thermal Projects bei Twitter, bzw. X, deren Funktionsweise die beiden Manager Keith Coleman (VP of Product) und Jay Baxter (ML Lead) in Lenny's Podcast erklärt haben. In Anlehneng an die thermischen Aufwinde, die Vögeln das Fliegen erleichtern, handelt es sich bei ihnen um vom Top-Management geförderte Vorhaben mit besonders guten Rahmenbedingungen.¹

Wie immer in solchen Fällen gilt natürlich auch in diesem hier, dass es sich um eine Fallstudie aus einem sehr spezifischen, nicht in allen Asspekten nachvollziehbaren Kontext handelt, die darum nicht mit Copy & Paste in andere Unternehmen übertragbar ist. Allerdings handelt es sich auch um eine der bekanntesten und erfolgreichsten IT-Firmen der Welt, so dass es durchaus interessant und inspirierend sein kann, sich deren Vorgehensmodell anzuschauen.²

Die erste der oben genannten fördernden Rahmenbedingungen ist bei Twitter/X das Vorhandensein eines möglichst hochrangigen Sponsors (idealerweise in Person von Elon Musk selbst), der auch als Eskalations-Instanz dient, wenn es mit anderen Team zu Konflikten über Architektur, Ressourcen oder Sonstiges kommt. Das sorgt nicht nur für ein schnelles Lösen von Blockaden, es limitiert indirekt auch die Zahl der Thermal Teams, da die Anzahl möglicher Sponsoren nur klein ist.

Bei der nächsten fördernden Rahmenbedingung handelt es sich um die Selbst-Auswahl der Teammitglieder. Wenn der Start eines neuen derartigen Teams verkündet wird, sucht nicht das Management die aus seiner sicht passenden Entwickler aus, sondern diejenigen die Interesse haben melden sich selbst.³ Dadurch ist sichergestellt, dass alle Beteiligten intrinsisch motiviert sind und bereit sind, ihr gesamtes Leistungsvermögen einzubringen.

Als nächste Besonderheit sind die so entstehenden Einheiten möglichst klein, mit im besten Fall deutlich weniger als zehn Teammitgliedern, wodurch die interne Kommunikation einfacher und schneller wird. Ein begrenzender Faktor ist dabei, dass möglichst crossfunktionale Einheiten angestrebt werden, die alle in Frage kommenden Arbeiten selbst ausführen können. Dort wo hohe Spezialisierung nötig ist, führt das ggf. zu grösseren Gruppen.

Wichtig ist ausserdem, dass Thermal Teams soweit wie möglich von allen anderen Verpflichtungen und Vorschriften befreit sind. Das bedeutet vor allem, dass sie nicht parallel in anderen Projekten mitarbeiten dürfen und sich nicht mehr an anderen Meetings und Reportings beteiligen müssen, es bedeutet aber auch, dass sonst vorgehebene Tools und Standards nicht mehr benutzt werden müssen. Coleman und Baxter nennen als Beispiel Jira, von dessen Nutzung Thermal Teams befreit sind.

Als letztes ist von Bedeutung, dass diese Art von Teams bei Twitter/X nur jeweils für eine begrenzte Zeit bestehen sollen (daher auch die alternative Benennung Thermal Projects). Die Grümde dafür dürften offensichtlich sein: zum einen wird so ein Abrutschen in Routinen und ein Zurückgehen der besonderen Motivation verhindert, zum anderen können die Teammitglieder in ihre ursprünglichen Einheiten zurückkehren, in denen ihre Beteiligung schliesslich auch benötigt wird.

Wie oben gesagt, die Idee der Thermal Teams ist nichts was andere Unternehmen einfach kopieren sollten, dafür ist der Kontext in dem sie funktionieren zu spezifisch. Es kann aber eine gute Idee sein, einzelne Elemente davon zu übernehmen, bei sich zu testen, ggf. anzupassen und so sein eigenes Vorgehensmodell zu entwickeln, mit dem sich der eher unstrukturierte Taskforce-Modus ablösen lässt.