Digitale Souveränität als Selbstverständnis

This article is also available in English

Dieser Artikel ist Teil einer Reihe.

• Teil 1: Von Datenfriedhöfen zu Wissenslandschaften
• Teil 2: Digitale Souveränität als Selbstverständnis (dieser Artikel)

Der Artikel wendet den Begriff „digitale Souveränität“ auf Umsetzungsteams als Netzwerke von Menschen mit je eigenen Fähigkeiten, Wünschen, Bedürfnissen und Visionen an. Ausgehend von der Prämisse, dass die Basis für technische und organisatorische Souveränität komplexer Systeme in den Fähigkeiten der Menschen besteht, die diese Systeme aufbauen, analysiert der Artikel Eigenschaften schlagkräftiger Umsetzungsteams und einige Stellschrauben, an denen Organisationen drehen können, um auf der operativen Ebene souveräner zu werden. Wie überwinden wir als Einzelpersonen und als Teams in der europäischen digitalen Industrie das Gefühl, dass wir Google, Meta und Co. immer nur hinterherlaufen, und wie ermächtigen wir uns mehr und mehr, im Sinne unserer europäischen Wertvorstellungen eigene Lösungen für eigene Probleme zu finden?

Wir sind nicht Google?

Wir sind nicht Google. Dieser Satz ist in der IT oft zu hören. Wenn wir über digitale Souveränität sprechen, dann muss er uns innehalten lassen, denn er kann Ausdruck eines Selbstverständnisses sein, das mit Souveränität nichts zu tun hat. Vorweg: Es ist richtig, Nutzerbasis und Wichtigkeit einer Software realistisch einzuschätzen: Eine interne Konstruktionssoftware für ein mittelständisches deutsches Unternehmen hat andere Anforderungen an Skalierbarkeit und Durchsatz als Google – geschenkt. Aber da schwingt oft noch etwas anderes mit. Wir sind nicht Google. Selbstzweifel. Neid. Die Amerikaner sind uns softwaretechnisch Lichtjahre voraus, das holen wir nicht mehr ein. Im Silicon Valley sind mehr Ressourcen, technische Intelligenz und Macht konzentriert als wir hier im altmodischen Europa je versammeln könnten. Dieses Gefühl, dass wir nur kleine Brötchen backen, während andere die „echte“ Software bauen (und damit ein Heidengeld verdienen), die wir täglich nutzen und ohne die wir, mit Verlaub, aufgeschmissen wären: Windows/MacOS/iOS, MS365, die Google-Suite, AWS, ChatGPT/Claude… was kommt als nächstes? Die gespannte Vorfreude, wenn der Apple-CEO in Kalifornien vor der Weltpresse auf die Bühne tritt… fast wie Weihnachten! Nur warum eigentlich nicht in Berlin? In Paris? London? Warum sind es immer „die Amerikaner“, die das Rad der Zeit vorantreiben?

Zu tun gäbe es genug

Nicht falsch verstehen: Das ist kein Plädoyer dafür, in Europa „das nächste Facebook zu bauen“. Unsere Rahmenbedingungen sind andere. Souveränität hat für uns, im ganz altmodischen Sinne, etwas mit Verantwortung zu tun; und vielleicht ist Digitalkapitalismus auch gar nicht so unser Ding. Aber das heißt nicht, dass es hier nichts zu tun gäbe. Könnte zum Beispiel GenAI das ur-europäische Dickicht aus Regularien und Gesetzen navigierbar machen? Für Normalsterbliche? Es suchen doch gerade alle ganz wuselig nach Nägeln für diesen Hammer. Hier wäre einer – wohlgemerkt, für die kommende europäische Hammer-KI, die genau den gleichen horrenden Energiehunger haben wird wie ihre amerikanischen und chinesischen Geschwister. Wie der gestillt und bestenfalls eingehegt werden kann, möglichst ohne gleich ein Atomkraftwerk neben das Rechenzentrum zu stellen… ungeklärt. Und dann (Verzeihung bitte) noch die ganz große Moralkeule: Irgendwo in der Welt wurde der menschgemachte Klimawandel im letzten November abgewählt. Wärmer wird es aber immer noch und Lösungen, auch digitale, sind gefragt. Green IT anyone?

Die Liste wäre beliebig fortzusetzen — der Punkt ist: Wenn wir digitale Souveränität einmal herauslösen aus dem Kontext einer bedrohlichen globalpolitischen „Zeitenwende“, aus dem ihre Notwendigkeit im deutschen Diskurs für gewöhnlich abgeleitet wird, dann können wir sie positiver verstehen, konstruktiver: Dann machen uns nicht unaufhörlich die Alarmsirenen im Hinterkopf kirre, und wir agieren nicht wie Getriebene sondern, ganz genau, souverän. So verstanden ist digitale Souveränität die intellektuelle und organisatorische Kapazität, komplizierte Probleme selbst digital zu lösen.

Ja, das beinhaltet die Fähigkeit, europäische Alternativen für Google, AWS und MS365 zu entwickeln. Vor allem aber ist das die Fähigkeit, Herausforderungen jeglicher Art anzupacken – die oben genannten sind da nur Beispiele. Sich das zu trauen ist eine strategische Entscheidung, durch die aber noch keine Welt verändert ist. Die beste Idee ist wertlos, wenn sie nicht zur rechten Zeit und mit angemessenen Mitteln umgesetzt wird. Eins ist sicher: Damit das gelingen kann, muss das Wir-sind-nicht-Google-Mindset aus den Köpfen verschwinden – auf allen Ebenen, aber vor allem bei den Umsetzungsteams. Schauen wir uns genauer an, was souveräne Entwicklungsteams auszeichnet, und an welchen Stellschrauben wir drehen können, um Souveränität auf der operativen Ebene zu fördern.[1]

Das souveräne Team

Wir nähern uns der Sache von außen: Ein Team von Informatiker:innen und Fachexpert:innen entwickelt Software für eine Organisation, die digital souverän sein will. Unser Team möchte das unterstützen. Wie können wir beurteilen, ob es das tut?

Der Blick des Zielstrebers

Da wir zunächst annehmen, dass wir die inneren Abläufe des Teams nicht kennen, bleibt uns nur der Blick aufs Ergebnis. Reflexhaft ziehen wir die Standardmetriken Effektivität und Effizienz heran: Ein Team, das genau das liefert, was gebraucht wird, ist effektiv. Wenn es dabei nicht mehr Ressourcen verbraucht als nötig, ist es effizient. Das sind Eigenschaften, die wir umgangssprachlich als Ausdruck von Souveränität bezeichnen würden. Und es sind Eigenschaften, die der Organisation als ganzer helfen, ihre Ziele zu erreichen, sowie Erreichbarkeit und Ressourcenbedarf künftiger Ziele einzuschätzen. Die Organisation wird sich dadurch seltener als andere verkalkulieren. Die Qualität ihrer Software wird ihr einen Wettbewerbsvorteil verschaffen. Ihre Teams sind in der Lage, für Probleme adäquate Lösungen zu finden und diese umzusetzen – ohne, oder mit Unterstützung von außen in angemessenem Maße. All das zahlt darauf ein, dass die Menschen in der Organisation sich selbst als souverän erleben; und es qualifiziert die Organisation als digital souverän im oben vorgeschlagenen konstruktiven Sinne.

Effektivität und Effizienz sind schön für Menschen, die Menschen und Prozesse verwalten, denn sie sind messbar (Effizienz) und entscheidbar (Effektivität) – allerdings erst in der Rückschau. Vom Ergebnis ausgehend kann ich beurteilen, ob der Weg dahin gut gewesen ist. Ich kann Zahlen anschauen und „ja“ sagen, „so machen wir das wieder“ – oder eben „nein, das war nicht gut“. Ich kann zwar unterwegs schon anfangen zu messen, Vergleichswerte heranziehen, und mich im Steuern und Gegensteuern versuchen. Aber die unbequeme Wahrheit ist: Meine Zahlen werden mir wenig dabei helfen, mein Team zu beschleunigen. Niemand mag es, gemessen zu werden, beurteilt und dann in eine Richtung geschubst. Außerdem stimulieren Zahlen und Diagramme intrinsische Motivation nur bedingt – wenn überhaupt.

Schlagkraft

Nehmen wir an, unser Team agiert tatsächlich souverän. Wir schauen auf das Ergebnis und stellen fest: Das war effektiv und effizient. Welche Eigenschaften hat das Team dann wahrscheinlich? Wir suchen nach Qualitäten, die flüchtiger sind als das in Zahlen fassbare. Frei assoziiert und ungeordnet: Energie – Lern- und Leidensfähigkeit – Einsatzbereitschaft – Fachwissen – technische Kompetenz – Disziplin – gute Teamdynamik – Entscheidungsfreude und -fähigkeit – Identifikation mit dem Produkt – Geduld – … Die Menge ist nicht scharf begrenzt und keineswegs vollständig: Viele schwer messbare Qualitäten, die wir der Einfachheit halber mit dem energischen Wort Schlagkraft zusammenfassen werden. Schlagkräftige Menschen und Teams werden sich sehr wahrscheinlich als souverän erweisen. Ein schlagkräftiges Team kann liefern – rasch und präzise, und nicht nur einmal. Ein schlagkräftiges Team will liefern. Und wahrscheinlich tut es das sogar mit jedem Mal überzeugender.

Das Dumme ist, dass ich Schlagkraft nicht herbei-organisieren kann. Es gibt sie einfach nicht, die drei goldenen Regeln der Teambildung, die meine Entwickler über Nacht zum Dreamteam zusammenschweißen werden. Schlagkraft entzieht sich einer genauen Definition, und damit jeder wiederholbaren Strategie, sie herbeizuführen — und das ist gut so. Das sind Menschen, die unsere Software entwickeln: eigentümliche, komplizierte Wesen mit je eigenen Stärken, Schwächen, Wünschen und Visionen. Ganz zu schweigen vom Team, diesem fragilen sozialen System, von dem am Anfang niemand mit Sicherheit sagen kann, welche Dynamiken es entwickeln wird.

Schlagkraft des Teams setzt Schlagkraft des Einzelnen voraus. Schlagkraft des Einzelnen setzt aufgabenspezifische Fachkompetenz voraus – und individuelle Reife: Ich muss gelernt haben, meine Energie auszurichten und dosiert einzusetzen. Ich muss erlebt haben, wie be-stärkend es ist, Verantwortung zu übernehmen, und wie befriedigend, meinen eigenen Teil zu einem großen Ganzen beigetragen zu haben. Ich habe wahrscheinlich verstanden, dass weder der Obstkorb noch der in-house-Barista hinreichende Kriterien für ein gutes Arbeitsumfeld sind. Vielleicht ist es mir am Ende des Tages sogar wichtiger, zuzupacken und etwas zu schaffen, als mich wohl zu fühlen… Es ist klar, dass wir uns solche Menschen nicht backen können. Wir können das alles auch irgendwie schlecht unter „Was du mitbringst“ in Stellenausschreibungen auflisten: „Du brennst für XY“ fühlt sich auf gut Neudeutsch einfach cringe an; und wenn wir anfangen, Nachweise für Lebenserfahrung oder geleistete Therapiestunden einzufordern, wird uns erst HR den Vogel zeigen, und dann der DSGVO-Beauftragte.

Zusammengefasst: Wir wollen schlagkräftige Teams, weil die warscheinlich effektiv und effizient, lies: souverän sind. Schlagkraft entsteht und wirkt auf einer Ebene, die sich der Beurteilung und der managenden Manipulation von außen entzieht. Das heißt aber nicht, dass wir machtlos sind: Schlagkraft ist Ausdruck des ungehemmten Zusammenspiels verschiedener gesunder, grundmeschlicher Eigenschaften. Schlagkräftig zu sein fühlt sich einfach gut an, und wenn ich Inspiration und Gelegenheit dazu habe, werde ich mich wahrscheinlich mit der Zeit zu einer schlagkräftigeren Person entwickeln. Welche Rahmenbedingungen sind dafür günstig? Wie könen wir unseren Entwicklern und Teams Gelegenheit dazu geben, aus sich selbst heraus souveräner zu werden?

Stellschrauben und Fußangeln

Es seien im Folgenden wahllos und ungeordnet Beobachtungen aus unserem eigenen Projektalltag herausgegriffen, die in diesen Kontext passen. Sie können den Blick für Randbedingungen schärfen, die Entwicklungsteams mittelfristig schlagkräftiger machen – oder eben nicht. Viele davon sind Dinge, „die ja jeder weiß“ – die aber zu oft unter den Tisch fallen, weil sie als weich und schwer beeinflussbar gelten.

Keep it simple, stupid

Jeder Entwickler, der sich schon mal in eine große, unbekannte Codebasis einlesen musste, wird bestätigen: KISS ist grundsätzlich eine gute Idee. Auf der organisatorischen Ebene wird das Konzept seltener angewendet. Dabei liegen die Vorteile auf der Hand: Je einfacher Organisationsstrukturen und Prozesse sind, desto weniger kommt es zu Indirektion und Reibungsverlusten. Je weniger Zeit die Teams dafür aufwenden, unnötig komplizierte Strukturen zu verstehen oder sogar selbst aufzubauen, desto mehr Zeit bleibt für die eigentliche Arbeit. Wohlgemerkt, das ist kein Appell für Anarchie: Arbeitsteilung muss organisiert werden – aber jedes Team ist anders, und die Grundannahme sollte sein, dass eine Gruppe erwachsener Menschen mit einem klaren Ziel vor Augen in der Lage ist, sich ad hoc selbst zu organisieren – anhand weniger etablierter Grundprinzipien. Wenn ich einem Team dieses Vertrauen entgegenbringe, wird es ein Bewusstsein für Autonomie und Entscheidungsmacht über die eigenen Abläufe entwickeln – eine Grundvoraussetzung für energisches Handeln und Entscheidungsfreude.

Keine Scheu vor Hierarchien

Das ist auch kein Plädoyer dafür, Hierarchien abzuschaffen. Flache Hierarchien sind wahrscheinlich eine gute Idee, weil sie effizienter sind als lange Befehlsketten. Keine Hierarchien – das endet im Chaos. Wo es darauf ankommt, dass Dinge trotz widriger Umstände und begrenzter Ressourcen funktionieren, da gibt es Hierarchien[2]. Die Schwierigkeiten mit Hierarchien liegen nicht darin, dass Dinge an anderer Stelle entschieden werden. Probleme entstehen, (a) wenn Entscheidungen zu lange dauern, weil sie die Befehlskette hoch- und wieder runterwandern, (b) wenn die Teams Ziele, die zwei, drei Ebenen weiter oben postuliert wurden, nicht verstehen oder sich nicht damit identifizieren können, und (c) wenn der schale Beigeschmack von Unterordnung und Machtgefälle zu stark ist, der jedes Gefühl persönlicher Souveränität zersetzen kann. Verstehen wir Hierarchien aber nicht vertikal („die da oben“) sondern horizontal, dann geht es nicht um Hackordnungen, sondern um klare Aufgabenzuteilung: Diese Entscheidung trifft X, weil er dafür qua Expertise gut geeignet ist, und die Zeit hat, den organisatorischen Kontext im Blick zu behalten. Betrifft die Entscheidung Einheiten außerhalb des näheren Umfeldes, dann schalte ich Y ein, die die Dinge aus größerem Abstand mit weiterem Blickfeld sieht. Lange Rede kurzer Sinn: Hierarchien sind wirklich besser als ihr Ruf, solange sie nicht durch Dynamiken belastet sind, die sachfremd und ungesund sind.

Sinnvolle Ziele mit Identifikationspotenzial

Die Weisheit ist nicht neu: Wenn ich viele intelligente Menschen dazu bringen will, in dieselbe Richtung zu laufen, muss ich ihnen dafür einen Grund geben. Ich muss klare Ziele formulieren, und diese Ziele müssen geeignet sein, intrinsische Motivation zu wecken. Zu diesem alignment innerhalb großer Organisationen haben sich viele kluge Menschen Gedanken gemacht – gerade weil es oft eine Herausforderung bleibt. Wer viel mit Menschen zu tun gehabt hat, die Software bauen (oder andere komplizierte Engineering-Aufgaben bewältigen), der weiß, dass diese Menschen oft ein tiefes inhaltliches Interesse an ihrer Arbeit haben, und dass ihnen die Aufgaben an sich oft wichtiger sind als finanzieller Erfolg. Wenn es in einer Organisation einen Wert hat, qualitativ hochwertige, nachhaltige Software zu bauen, die sinnvolle Dinge für Menschen tut, dann wird es dieser Organisation vergleichsweise leicht fallen, ihre Teams dazu zu bringen, sich mit ihren Aufgaben und Produkten zu identifizieren. Umgekehrt fördert eine Unternehmenskultur, in der Umsatz das wichtigste Ziel ist, und in der entsprechende Kennzahlen und Diagramme das zentrale Steuerungsvehikel sind, bei den kreativ und konzeptionell arbeitenden Menschen auf der Umsetzungsebene eher innere Distanz zum eigenen Tun.

Fordern, wenn es sinnvoll ist

Das Schöne ist: Wenn Teams sich mit ihren Zielen identifizieren, kann Leistung durchaus eingefordert werden, sogar über das gewöhnliche Maß hinaus. Den Over-Nighter, wenn ein Feature einfach fertig werden muss, oder wenn ein unvorhergesehenes Problem den Produktivgang verzögert, haben die meisten Softwareentwickler:innen schon erlebt. Bei echter Identifikation mit dem eigenen Tun ist so etwas absolut möglich. Der Witz ist ja: Es fühlt sich – ausreichend Erholungsphasen vorausgesetzt – gut an, über die eigenen Grenzen hinaus zu gehen, um etwas zu leisten, das man vorher für unmöglich gehalten hat. Je umfassender ich meine kreative Energie in die Aufgabe gießen kann, desto besser, selbst wenn die Trägheit der Masse und eine gewisse Bequemlichkeit mir vorher sagen werden: Streng dich nicht an. Schlagkraft heißt eben auch Lust zu schaffen. Es versteht sich von selbst, dass sich davon niemand dazu verleiten lassen sollte, ein Team zu verbrennen. Regelmäßige Überlastungsphasen sind desktruktiv und deuten auf Defizite in der Planung oder im Prozess hin, die unbedingt behoben werden müssen.

Knappheit als Ansporn

Die Fülle der finanziellen Mittel ist in der IT verglichen mit vielen anderen Branchen noch immer enorm. Unser Beruf kann deshalb sehr bequem sein. Machen uns unsere hohen Gehälter produktiver? — Es gibt ein schönes Zitat von Leonard Bernstein: „Um etwas großes zu schaffen, braucht es zwei Dinge: Eine gute Idee, und zu wenig Zeit.“ Ressourcen sind immer begrenzt – aber vorausgesetzt, was ich tun will ist wirklich „groß“ (oder in unserem Kontext: sinnvoll und erstrebenswert), kann gerade das Bewusstsein, dass „es knapp wird“, einen ungemeinen Energieschub bewirken. Wenn also die Zeit drängt, dann gilt es, das Bewusstsein dafür bis in die Teams hinein zu tragen – aber bitte mit Begründung! „Wir haben richtig Stress weil X sich Ende des Quartals im Steuerungskommitee vor Y verantworten muss“ – na ja, hoffen wir, dass die Teammitglieder X mögen…

Entscheidungsfreude

Softwareentwicklung ist eine Abfolge von fachlichen und technischen Entscheidungen, durchsetzt von Phasen, in denen Entscheidungen umgesetzt, getestet, angepasst, oder verworfen werden. Wenn Entscheidungen zu lange dauern, oder gar regelmäßig in der Befehlskette nach oben delegiert werden, dann ist etwas faul. Zwei mögliche Ursachen sind (a) vertikal, also als Machtgefälle verstandene Hierarchien, verbunden mit dem Misstrauen, dass „das Management“ Entscheidungen nicht mittragen wird und (b) mangelndes Vertrauen der Teammitglieder untereinander, das dazu führt, dass zu viele Personen in Entscheidungsprozesse eingebunden sein wollen. Ersteres ist, wenn der Zustand chronisch ist, wahrscheinlich ohne externe Unterstützung nicht mehr zu lösen. Für letzteres hilft, ein Bewusstsein dafür zu schaffen, dass die Aufteilung (nicht primär von Aufgaben-, sondern) von Verantwortungsbereichen ein Team langfristig effizienter macht, und kein Zeichen von Misstrauen in die Fähigkeiten einzelner Teammitglieder ist. Der Kerngedanke von „wir machen das gemeinsam“ ist nicht „wir beschäftigen zehn Gehirne mit Problemen, für die zwei Gehirne ausreichend wären“, sondern „wir koordinieren die Arbeit von zehn Gehirnen so, dass die Lösungen für die sieben Probleme, die sie auf unterschiedlichen Ebenen bearbeitet haben, am Ende gut ineinandergreifen“.

In Köpfe investieren

Zu guter Letzt ein Aufruf, der uns bei INNOQ am Herzen liegt, und der als Quintessenz all dieser Überlegungen gelten kann: Das größte Kapital eines digital souveränen Unternehmens sind seine Mitarbeiter:innen. In ihre Intelligenz, in ihre fachliche und technische Kompetenz, in ihre Problemlösungsfähigkeiten und Lernbereitschaft, in ihre Vertrautheit mit modernen Werkzeugen, aber auch in ihr persönliches Wachstum, in ihre Begeisterungsfähigkeit und Resilienz zu investieren, zahlt sich langfristig aus. Teams, die gemeinsam lernen und die Mittel bekommen, an ihren gegenwärtigen Herausforderungen tatsächlich zu wachsen, werden die kommenden Herausforderungen besser bewältigen, und die dann folgenden noch besser, und so weiter. Ich will wissen, dass das Unternehmen, dessen Zielen ich einen großen Teil meiner Lebenszeit widme, nicht nur meine Arbeitskraft mietet, sondern mit mir eine langfristige Partnerschaft eingeht. Ich will, dass dieses Unternehmen ein Interesse daran hat, dass ich meine Fähigkeiten stärke und neue gewinne – zu unser beider Nutzen! Dann wird aus „ich arbeite für euch und ihr bezahlt mich dafür“ ein echtes Geben und Nehmen, und ich mache mir die Ziele des Unternehmens nach und nach zu eigen. Wenn es einer Organisation im Bereich der digitalen Industrie gelingt, so eine Dynamik mit möglichst vielen ihr angehörenden Personen zu entwickeln, dann trägt langfristig das immer schlagkräftigere Zusammenwirken der Einzelpersonen signifikant zur konstruktiv verstandenen digitalen Souveränität der Organisation bei.

1. Die folgenden Beobachtungen sind auf kreativ und konzeptionell arbeitende Teams jedweder Art anwendbar. Wir beschränken uns hier aufgrund eigener Vertrautheit und im Sinne der Gegenständlichkeit auf die Domäne Softwareentwicklung.  ↩

2. Im militärischen Kontext käme niemand auf die Idee, Entscheidungen, die innerhalb von Minuten, vielleicht Sekunden getroffen werden müssen, einem Kommitee zu übertragen. Und die Berliner Philharmoniker, ein Team von hochspezialisierten Handwerkern von Weltrang, entscheiden nicht basisdemokratisch, wie Brahms IV gespielt werden soll. Warum? Weil sie wissen, dass sie für ein sehr mediokres Ergebnis unendlich viel Zeit in Diskussionen verbrennen würden: Zeit, die es in der Branche Kultur nicht gibt, ganz einfach, weil es kein Geld gibt.  ↩