Wenn ich durch LinkedIn oder Instagram scrolle sehe sie überall Menschen, die sich als “Manager” oder “Leader” positionieren und Führungsweisheiten in Karussell-Posts und schönen Videos verpacken. Sowas wie “5 Dinge, die ich als Führungskraft gelernt habe”, “Warum gute Manager Nein sagen” oder “Was ihr tun müsst um Manager zu werden” sieht man häufig. Betrachtet man dieese Profile genau, findet man schnell heraus, dass der eine seit zwei Jahren Projekt Manager, die andere 9 Monate Abteilungsleiter und viele manchmal nicht einmal das sind. (Das Gleiche gilt heute auch für KI.)

Meine erste Reaktion ist Abneigung. Ich weiß, ich weiß, nicht sehr fein. Der zweite Gedanke ist aber unangenehmer, denn er richtet sich an mich selbst: Und was machst du? Mit welcher Berechtigung schreibst du eigentlich diesen Newsletter? Was ist deine Erfahrugn?

Das soll keine Abrechnung mit LinkedIn-Coaches und Instagram-XYZ-Managern werden, sondern eine Selbstbefragung oder Reflexion. Denn wann hat man genug Erfahrung, um sie weiterzugeben? Und woran merkt man das überhaupt?

Projekte, Marketing oder Social Media managen ist nicht Menschen führen

Fangen wir mit der einfachsten Unterscheidung an, die trotzdem ständig verwechselt wird. Ein Projektmanager verantwortet Termine, Budgets, Lieferobjekte. Das ist anspruchsvoll und keine einfache Arbeit. Aber es ist etwas anderes als Führung. Dasselbe gilt für Sales-, Social Media-, Produkt- oder “Wen auch immer”-Manager.

Führung beginnt dort, wo es in der Regel unbequem wird. Bspw. wenn man jemandem sagen muss, dass die Gehaltserhöhung nicht kommt. Wenn man eine Kündigung ausspricht. Wenn man ein Jahr lang Zahlen verantwortet und im Dezember erklären muss, warum sie nicht stimmen. Wenn man eine Entscheidung trifft, die sich als falsch herausstellt und die Folgen für das Team trotzdem tragen muss, weil man sie nicht delegieren kann. Man nimmt aber auch als Führungskraft so einiges mit, Dinge die einem im Kopf brennen und die man nicht einfach an der Bürotür zurücklässt. Das sind so Sachen wie die Sorgen und Ängste seiner Mitarbeiter, die Ups und Downs. So wirken sich die privaten Themen auch auf die Arbeit aus, was besonders schwierig zu handhaben ist.

Wer das noch nie erlebt hat, hat kein schlechteres Wissen. Er hat ein anderes Wissen.

Jahre sind die falsche Einheit

Eine naheliegende Antwort auf die Frage “Wann habe ich genug Erfahrung?” lautet: nach so und so vielen Jahren. Ich halte das für falsch. Ich kenne Menschen mit fünfzehn Jahren Führungsverantwortung, die im Grunde ein Jahr fünfzehn Mal wiederholt haben. Und ich kenne Leute, die in drei Jahren mehr durchgemacht haben als andere in einem Jahrzehnt, weil sie ein Team durch einen schwerwiegenden Kundenverlust, eine große Umstrukturierung und einen stillen Generationswechsel geführt haben.

Erfahrung misst sich nicht in Jahren, sondern in Zyklen, in komprimierten Zeiteinheiten. Ein Zyklus ist eine Situation, die man von Anfang bis Ende durchlebt hat, inklusive der Konsequenzen. Jemanden eingestellt, entwickelt und dann verloren. Ein Budget geplant, verteidigt, verfehlt, korrigiert. Einen Konflikt im Team ignoriert, eskalieren sehen, gelöst. Erst der volle Zyklus erzeugt das, was man später weitergeben kann, also die Erfahrung. Alles davor, wenn ich quasi abbrehce, ist Beobachtung.

Die meisten Erkenntnisse, die ich heute für belastbar halte, stammen aus Zyklen, die schlecht ausgegangen sind oder zumindest richtig richtig unangenehm waren. Die, die erfolgreich ausgegangen sind, liefern zwar auch nette Einsichten, aber das vertiefen wir gleich noch weiter.

Das, was man erst nach dem Scheitern weiß, lässt sich nicht abkürzen.

Jetzt abonnieren

Laut ist nicht erfahren

Meiner Meinung nach gibt es einen Grund, warum die Zwei-Jahres-Manager so präsent sind; Sie haben noch nicht genug erlebt, um an sich zu zweifeln. Ihre Modelle und Ansätze sind ok, ihre Regeln haben keine Ausnahmen, ihre Karussell-Posts brauchen keine Fußnoten.

Auf der anderen Seite werden viele mit jedem Zyklus leiser. Nicht weil man weniger weiß, sondern weil man weiß, wie kontextabhängig das Wissen ist und weil man weiß, wie wenig man oft weiß. Was in einem Beratungsteam mit 30 Leuten funktioniert, kann in einem Konzernbereich mit 300 Leuten schädlich sein. Und andersherum.

Das Problem, das daraus entsteht, ist, dass die Leute, die am meisten zu sagen hätten, am wenigsten sagen. Die daraus entstehende Lücke füllen die, die noch nicht wissen, was sie nicht wissen.

(Zusätzlich wird leichter, seichter Content am besten mit einem nichtssagenden Bild von einem selbst vom Social Media Algorithmus belohnt, so auch auf Linkedin.)

Das ist nicht nur ein Ärgernis. Es ist ein echtes Problem für alle, die gerade in ihre erste Führungsrolle kommen und Orientierung suchen. Sie bekommen die selbstsichersten Antworten von denen mit der dünnsten Grundlage.

Meine drei Fragen an mich selbst

Ich habe für mich drei Fragen überlegt, die für mich zur Orientierung dienen, bevor ich etwas als “Erfahrung” weitergebe. Sie sind nicht wissenschaftlich, aber sie geben mir eine Richtung.

Habe ich die Konsequenzen selbst getragen? Wenn ich über schwierige Entscheidungen kommuniziere, dann nur über solche, bei denen ich am Ende derjenige war, der die Verantwortung hatte. Nicht der, der daneben stand und zugeschaut hat, wie jemand anderes sie getroffen hat.

Kenne ich den Gegenfall? Für jede Regel, die ich formuliere, sollte ich eine Situation kennen, in der sie nicht galt. Wenn ich das nicht kann, ist es keine Erfahrung, sondern eine Meinung, die ich noch nicht getestet habe.

Kann ich sagen, wo mein Rat aufhört? Ich führe ein Beratungsunternehmen mit Cloud-Engineers und Architekten, das souveräne Plattformen, Plattformen für AI baut und beim Einführen von Plattform-Engineering hilft. Darüber hinaus arbeite ich viel in und mit Open Source. Ich habe aber keine Ahnung, wie man eine Fabrik führt, eine Pflegestation oder ein Ministerium. Meine Erfahrung hat einen Geltungsbereich und den sollte ich benennen, statt so zu tun, als hätte ich universelle Führungsprinzipien entdeckt. (Und ja, manchmal kann ich abstrahieren. Aber auch das muss klar sein, wenn ich das tue.)

Was ich daraus für mich ableite

Die ehrliche Antwort auf “Wann hat man genug Erfahrung?” lautet: Man hat nie genug und das ist auch nicht das Kriterium. Das Kriterium ist, ob man ehrlich über die Grenzen dessen sprechen kann, was man weiß.

Deswegen ist es wichtig, die Zyklen zu benennen, aus denen eine Erkenntnis stammt, statt sie als allgemeingültig zu präsentieren. Auch wenn es oft unpassend scheint, steckt viel Wert darin, den Kontext mitzuliefern, in dem sie entstanden ist. Und die Fälle zu erwähnen, in denen ich falsch lag, weil sie meistens interessanter sind als die, in denen ich recht hatte.

Wenn ihr also in Zukunft etwas lest, das wie eine allgemeingültige Regel klingt, dann fragt nach, worauf das beruht. Und fragt nach dem Gegenfall. Ich denke, dass genau dafür Erfahrung da ist; nicht um sie zu verkünden, sondern um sie hinterfragbar zu machen.

Wenn du gerade mehr als zehn E-Mails in deinem Postfach hast, lass mir ein ❤️ da. Mehr als 100? Schreib mir einen Kommentar. Tausend, sagst du? Du brauchst ernsthaft Hilfe!

Ein übervolles Postfach mit gelesenen und ungelesenen Mails zu öffnen, erhöht deinen Stresspegel (Habe ich vergessen zu antworten? War da nicht eine wichtige Nachricht?). Manche Leute markieren E-Mails zusätzlich als wichtig oder mit einem Aufgaben-Flag.

Und ich bin mir ziemlich sicher, dass du dein Mailprogramm auch als Datenbank bzw. Ablage für all die wichtigen PowerPoints und Excel-Sheets nutzt, die sonst nirgendwo gespeichert sind. Wie gesagt: ein kaputtes System.

Zero Mail Inbox

Das Konzept von Zero Inbox ist einfach: Du hast das Ziel, zu Beginn bzw. am Ende jedes Tages ein leeres Postfach zu haben. Das heißt, du löschst, archivierst, delegierst oder beantwortest jede E-Mail, die bei dir eingeht. Es ist ein systematischer Umgang mit E-Mails, der dafür sorgt, dass du nichts Wichtiges verpasst und dein Postfach gleichzeitig aufgeräumt bleibt.

Einer der größten Vorteile von Zero Inbox ist, dass du bei deinen Aufgaben den Überblick behältst. Du kannst deine Arbeit effektiv priorisieren, wenn du genau weißt, welche E-Mails du beantworten oder nachverfolgen musst. Du brauchst dafür eine Routine, ein E-Mail-Programm, das dich gut unterstützt, und eine strikte, starke Mentalität (denn Routinen entstehen nicht über Nacht).

Tools

Viele Artikel zu diesem Thema steigen direkt tief beim Aufbau der Routine ein. Ich fange bei den Tools an, denn wenn die dich nicht gut unterstützen, wird eine Routine aufzubauen X-mal schwieriger.

Als Erstes brauchst du eine To-do-App, die auf dem Handy und auf dem Rechner verfügbar ist. Das ist nötig, weil es bei Zero Mail Inboxing um Prioritäten geht. Ich habe einiges ausprobiert und bin inzwischen bei Superlist gelandet (keine Werbung, Free to use, Sitz in Deutschland).

Warum eine ToDo App? Ich versuche, meine Aufgaben in natürlicher Sprache zu formulieren. Das zwingt mich, über die eigentliche Handlung nachzudenken und dadurch wird sie automatisch klarer! Alternativen zu Superlist gibt’s genug, ich glaube, das ist reine Geschmackssache.

Wichtig ist, dass du Aufgaben mit Datum und Uhrzeit anlegst und sie mit @ oder # labelst und kategorisierst.

Ein Beispiel

Als Nächstes: Um effizient mit E-Mails zu arbeiten und sie leichter zu sortieren, ist eine gute E-Mail-Software essenziell, mit der du schnell und einfach suchen und organisieren kannst.

Privat habe ich anfangs Gmail genutzt und bin während meines Lernprozesses auf Proton Mail umgestiegen (auch aus Souveränitätsgründen). Tatsächlich spare ich mir dabei sogar finanziell was und die User Experience auf Desktop, Mobile und im Web ist fantastisch. Beruflich nutze ich Outlook, geht auch, ist etwas langsam.

Die Archivfunktion ist extrem nützlich und ja, jeder Mail-Dienst bietet sie an, nur wird sie nie benutzt. Deswegen ist es wichtig, den Shortcut zu lernen oder zu konfigurieren. In Proton ist das einfach die Taste “A”.

In der Web Variante von Proton Mail gibt es auch Deeplinks zu den E-Mails. Das ist besonders praktisch, wenn du in deinen To-dos auf eine E-Mail verweist. Du kopierst den Link zur Mail und nutzt ihn in der zugehörigen Aufgabe. Wenn du die Aufgabe später nachverfolgst, kommst du direkt an die E-Mail, ohne sie im Postfach suchen zu müssen.

Vorbereitung

Um wirklich mit einem Zero Mail Inbox zu starten, musst du erst einmal auf null E-Mails im Postfach kommen. 🎉Surprise!!!🎉 Du könntest den harten Weg gehen und einfach alle Mails ins Archiv schieben. Ich würde das nicht empfehlen, weil du damit nur die Symptome behandelst und nicht die Ursache, und weil es dir nicht hilft, in deiner Routine zu bleiben.

Ich bin mit den folgenden Schritten gestartet:

1. Suche in deinen E-Mails nach dem Wort „unsubscribe“ oder „abmelden“ und melde dich von allen Newslettern ab, die dich wirklich nicht interessieren. (Lösche oder archiviere diese dann auch gleich.)

2. Geh in deinen Spam- bzw. Junk-Ordner und schau nach, ob dort aus Versehen Mails gelandet sind. Wenn ja, verschieb sie zurück ins Postfach. Das ist wichtig, weil es wegen des nächsten Schritts irgendwann schwierig wird, diese Mails wiederzufinden.

3. Geh die E-Mails des letzten Monats in deinem Postfach durch. Alles, was Spam ist (Headhunter, direkte Verkaufsversuche und so weiter), kannst du in den Spam- bzw. Junk-Ordner verschieben oder als Junk markieren. In Zukunft übernimmt dein Mail-Anbieter das für dich.

4. Benachrichtigungen. Dieser Punkt liegt bei dir. In meinem Job bekomme ich Unmengen an Notifications aus unserem internen Wiki, von GitHub und von anderen Plattformen, die wir mit unseren Kunden nutzen. Ich schalte sie ab und packe sie in meine tägliche Checkliste, die als wiederkehrende Aufgabe für jeden Tag angelegt ist.

5. Mail-Trains: Manchmal braucht es etwas Aufklärung bei den anderen. E-Mails sind furchtbar, um zu diskutieren oder sich gegenseitig zu kommentieren. Identifiziere Mail-Trains und verlagere sie in ein passendes Format wie Slack, oder mach einfach ein Meeting, um die Sache zu klären.

Mit diesen Schritten bist du bereit, an deinem Zero Mail Inbox zu arbeiten:

Geh alle E-Mails durch und räum auf. Ehrlich gesagt habe ich das nur für den letzten Monat gemacht und ansonsten gezielt nach relevanten Themen und Personen gesucht. Alles andere ist ins Archiv gewandert. Wenn etwas dringend oder wichtig ist, bleibt es keinen Monat liegen, die Leute kommen schon von selbst auf dich zurück.

Jetzt kannst du anfangen, deine Gewohnheiten zu formen. Und das wird kein Spaziergang.

Gewohnheiten

Vom E-Mail-Sklaven zu vier Wochen am Stück mit leerem Postfach hat es bei mir fast ein halbes Jahr gedauert. Und selbst jetzt fällt es mir schwer, es sauber zu halten. Ein langes Wochenende, Urlaub oder ein paar Tage beim Kunden oder auf einer Konferenz zerlegen deine Gewohnheit schneller, als du „Ich will nicht mit einem dreckigen Postfach leben“ sagen kannst.

Die Dinge aus der Vorbereitung sind gleichzeitig die Dinge, die du beibehalten musst, um deine Gewohnheiten zu etablieren.

Bei jeder eingehenden E-Mail musst du in Sekundenbruchteilen entscheiden:

• Kann ich schnell antworten und die Mail ins Archiv schieben?

• Ist es Müll (löschen) oder Spam (in den Spam-/Junk-Ordner)?

• Ist es eine systemgenerierte Mail (abmelden oder Konfiguration ändern)?

• Ist es eine größere Sache, für deren Beantwortung du ordentlich Zeit brauchst (Aufgabe anlegen, Mail verlinken, Mail archivieren)?

Einfach, oder? Diese Routine musst du mindestens 100 Tage lang jeden Tag durchziehen. Das ist deine Challenge. Und erst wenn du so lange erfolgreich warst, darfst du es Routine nennen.

Zero Mail Inboxing hat mir geholfen:

• Müll in Sekundenbruchteilen auszusortieren

• klare Prioritäten zu haben

• meine Zeit besser zu managen

• mich auf die wichtigen Dinge zu konzentrieren

• aufgabengetrieben und fokussiert zu arbeiten

Ein Zeichen für zu viel Arbeit oder Stress

Jetzt, wo ich in einer sehr guten Routine bin, zeigt mir ein über längere Zeit volles Postfach, dass ich gerade zu viel auf dem Teller habe. Widerspricht sich das nicht? ROutine und volles Postfach? Nein, wenn ich Zero Inbox einfach weiter durchziehe nach einer schwachen Phase, dann ist das ok.

Am Ende ist das für mich ein Indikator, dass ich etwas ändern oder bestimmte Aktivitäten zurückfahren muss. Vor Zero Mail Inbox war mein Postfach einfach immer voll, jetzt ist es ein Leuchtturm, der ein klares Signal gibt.

Zum Schluss: Der Zero-Inbox-Ansatz war für mich ein echter Gamechanger. Simple, effektiv durchzusetzen und verleitet nicht zu viel unnötigem Schnickschnack wie Regeln zum Verschieben in Ordnern. Es hat mir geholfen, meine Arbeitslast effizienter zu managen und lässt mich bei meinen Aufgaben den Überblick behalten.

Es ist aber wichtig, sich klarzumachen, dass dieser Ansatz Disziplin und Organisation braucht. Ich habe über sechs Monate gebraucht, um in die Routine zu kommen und gelegentlich kämpfe ich immer noch. Vor allem mit dem Erfassen von Aufgaben in einer ToDo App hapert es ganz oft. Aber die Vorteile von Zero Inbox sind unbestreitbar. Es hilft, den Kopf freizubekommen und erlaubt es sich auf das Wichtige zu konzentrieren.

Also probier es aus und schau, wie es deine Art zu arbeiten verändern kann!

KI und der Manager: Wo’s glänzt

Vor einigen Monaten hatten ich ein Gespräch mit einem noch recht frisch gebackenen Manager. Er erzählte mir doch recht begeistert darüber, dass er vor kurzem einen Kurs gemacht hat, wie man als Manager AI einsetzt und hätte sich darauf hin gleich noch zu zwei weiteren Kurses angemeldet. Hauptsächlich ginge es darum, wie man seine Meetings besser vorbereitet, Emails schreibt und sein Mitarbeiter managed. Genau in der Reihenfolge bin ich zunehmend skeptischer geworden. Bei letzterem wollte ich wissen wie er das so anwendet. Bei seiner Ausführung darüber wie er die 1:1s, Team Meetings und “Kaffemaschinen”-Gespräche in die AI Füttert um dan hinweise zu bekommen, was er tun sollte, wie er gesagtes zu interpretieren hat und wie er seine Kommunikation gestalten sollte; wurde mir ehrlich gesagt schlecht.

KI ist unschlagbar, wenn es um Effizienz, Skalierbarkeit und datenbasierte Entscheidungen geht.

Ein paar “Stärken” kurz aufgelistet:

• Datenanalyse in Echtzeit: KI verarbeitet riesige Mengen an Daten und erkennt Muster, die Menschen übersehen würden.

• Prozessoptimierung: Sie automatisiert repetitive Aufgaben und spart Zeit bspw. von der Produktionsplanung bis zur Überarbeitung von Kundenkommunikation.

• Objektive Entscheidungen: Freie von emotionalen Verzerrungen trifft KI Entscheidungen, bzw. gibt Handlungsempfehlungen auf Basis von Fakten und Algorithmen.

• 24/7-Verfügbarkeit: Kein Mensch kann rund um die Uhr arbeiten, KI schon. (Zumindest so lange es die Kreditkarte zulässt)

Was KI nicht kann, ist, den Menschen zu lesen (noch nicht, und ja das kann man lang und breit diskutieren, aus der Schreibweise/Ton usw. kann eine KI schon ablesen, ob jemand genervt ist oder glücklich etc.). Vor allem nicht aus der subjektiven Wahrnehmung einer unerfahrenen Führungskraft.

KI ist meiner Meinung nach auch nicht geeignet, Kommunikation alleine zu gestalten, so wie es gerade in vielen YouTube-Videos und Trittbrettfahrer-Schulungen vorgekaut wird. Zum einen reduziert es das eigene Sachverständnis von dem, was passiert, zum anderen kommen wir am Ende in einen KI-generierten Mail-Train. Würde man dann jemanden im Verteiler fragen, um was es geht, gäbe ich Brief und Siegel darauf, sie wissen es nicht.

KI und Leadership: Wo’s scheitert

Führung ist mehr als Effizienz.

Wer führt, arbeitet mit Menschen. Wer führt, ist verantwortlich für Ideen, Visionen, Inspirationen und dafür, Dinge möglich zu machen. Wer führt, managt auch oft: Projekte, Aufgaben, finanziellen Erfolg etc.

Doch es gibt einen Unterschied zwischen Mitarbeitern zu führen und deren Aufgaben und Tätigkeiten zu managen. Echtes Leadership erfordert Eigenschaften, die KI (noch) nicht replizieren kann:

• Empathie und emotionale Intelligenz: Menschen führen bedeutet, Ängste zu verstehen, Motivation zu wecken und Vertrauen aufzubauen. KI kann Stimmungen analysieren, künstlichen Zuspruch bieten, aber nicht echte Verbundenheit schaffen.

• Vision und Inspiration: Leader malen ein Bild der Zukunft, das Teams begeistert. KI kann Trends vorhersagen, aber keine emotionale Bewegung auslösen.

• Ethik und Werte: Führungskräfte treffen Entscheidungen nicht nur auf Basis von Daten, sondern auch von Moral und Intuition. KI handelt innerhalb ihrer Programmierung, Richtlinien und Vorgaben, sie hat kein Gewissen. (egal wie viel sich der Papst damit beschäftigt)

• Kreativität und Innovation: Echte Durchbrüche entstehen oft durch unkonventionelles Denken, etwas, das KI nur begrenzt nachahmen kann.

In einer Krise brauchen Mitarbeiter nicht nur klare Anweisungen, sondern auch Sicherheit und Orientierung. Eine KI könnte zwar Handlungsanweisungen geben – aber sie kann keinen echten Trost spenden oder ernst gemeinten Mut machen.

Nicht jeder Manager ist eine Führungskraft, aber jede Führungskraft muss auch managen

Manchmal beschäftigt einen ein Mitarbeiter über Tage hinweg. Oder wenn jemand gesundheitliche Probleme hat, versucht man herauszufinden, wie man diese Person am besten unterstützen kann.

Die Rolle der Führungskraft im Zeitalter der KI

KI wird nicht mehr verschwinden, ganz im Gegenteil: Sie wird immer “mächtiger“ und allgegenwärtiger. Doch statt uns zu fragen, ob KI uns ersetzen wird, sollten wir uns fragen: Wie können wir mit KI arbeiten, um effizienter zu managen und dadurch mehr Zeit fürs Leader sein zu haben?

KI ist ein Werkzeug

KI ist kein Ersatz für das, was als Manager und/oder Leader getan werden muss. Und sollte die KI dies erfolgreich tun, dann ist die Rolle selbst obsolet. Nutzt KI, um Daten zu analysieren, um Informationen aus vielen Systemen aggregieren zu lassen: eine tägliche Summary anstehender Termine, unbeantworteter E-Mails und Aufgaben. Alles, was euch in eurer Arbeit hilft, mehr zu entlasten, diese schneller und effizienter zu erledigen und Prozesse effektiver zu gestalten.

Aber behaltet das Führen von Mitarbeitern in der Hand und nicht im Prompt.

Arbeitet an euren Soft Skills

Für jeden Copilot-Kurs, How-to-Prompt-Engineer und “Wie werde ich ein besserer Manager mit KI?“ solltet ihr auch gleichzeitig eine professionelle Soft-Skill-Schulung oder sogar Coaching buchen. KI liefert euch harte Fakten.

Aber es liegt an euch, Empathie, Kreativität und emotionale Intelligenz an den Tag zu legen. Diese lassen sich nur leider nicht für 9.99€ auf Udemy kaufen. Dafür braucht es Zeit, Möglichkeiten (Erfahrungen zu sammeln) und Offenheit. Sucht euch dazu ein professionelles Coaching oder, wenn möglich, einen Mentor.

Teilen

Zu viel KI, wird euch schaden

Zum einen bekommen es die Wenigsten hin, einen kontinuierlichen Kontextwechsel zu haben. Je mehr KI wir einsetzen, desto mehr Kontextwechsel haben wir und desto energiefressender wird es sein, seine Arbeit zu erledigen. Gleichzeitig bedeutet viel KI auch, dass ihr viel kontrollieren müsst, ansonsten leidet eure Reputation darunter. Und “das war die KI” ist keine gute Ausrede. Ich sehe es leider schon heute, dass viel zu viel oberflächliches Yadda produziert wird.

Zum anderen, leidet eure Kommunikation mit euren Mitarbeitern darunter. Wenn ihr schon keine persönliche Zeit in die Kommunikation investiert, welchen Wert schreibt ihr euren Mitarbeitern also zu? Dieser Bruch in der Vertrauensbasis ist nur der erste Schritt, damit am Ende euch keiner mehr ernst nimmt.

Leadership und Management in der Zukunft

KI ist ein starker Manager aber kein Leader. Die besten Führungskräfte der Zukunft werden diejenigen sein, die die Stärken der KI nutzen und gleichzeitig ihre eigenen, einzigartig menschlichen Fähigkeiten ausbauen.

Für jede Kompetenz, die ihr auf KI-Seite aufbaut, müsst ihr euch auch persönlich weiterentwickeln. Ihr müsst in der Lage sein, mit beiden Seiten zu jonglieren.

Wo siehst du in deinem Berufsalltag die größten Chancen und die größten Grenzen von KI in der Führung?

Hier ist eine Übersicht der Tools, die ich nutze, das Geld, das ich spare, und die wenigen Hürden, über die ich noch (immer) stolpere.

Übrigens: Dieser Beitrag richtet sich an persönliche Setups, nicht an Unternehmen. Die meisten Tools lassen sich aber auch für Teams und Firmen nutzen.

Das Rückgrat: Das Proton-Ökosystem

Den größten Einfluss auf diese Migration hatte Proton. Das Unternehmen hat sich von einem einfachen Anbieter verschlüsselter E-Mails zu einem (fast) vollständigen Produktivitäts-Komplettpaket entwickelt.

Kurze Anmerkung vorab: Ja, Proton ist nicht in der EU ansässig, aber der Schweizer Datenschutz ist mit den EU-Anforderungen abgestimmt und in manchen Bereichen sogar strenger, in anderen wiederum flexibler für Nutzer und Anbieter.

Mein Abonnement umfasst jetzt:

• Mail & Kalender: Verschlüsselt und aufgeräumt.

• Drive: Sicherer Cloud-Speicher, seit einer Weile mit Docs, und jetzt auch mit Tables.

• Proton Pass: Ein solider Passwortmanager mit 2FA-Integration.

• VPN: Schnell und zuverlässig.

• Meet: Recht neu, brauch ich nicht wirklich oft aber funktioniert auch sauber

• Lumo AI: Eine datenschutzorientierte KI, ich nutze sie noch nicht regelmäßig, hab kein Abo dazu. aber dazu gleich mehr.

Außerdem benutze ich Standard Notes: Mein bevorzugtes Notiztool, unterstützt vom Proton-Team. (ABER, es ist ein US Unternehmen. Warum nutze ich es trotzdem? a) Sourcecode ist offen, ich kann jederzeit davon Weg b) ich kann es selber hosten c) starke Verschlüsselung ((ja, ja, kann man immer knacken etc…))).

Zurück zu Proton: Alles ist integriert und die Nutzererfahrung ist Gut. Proton Drive ist auf dem Smartphone viel zu langsam. Nutze es dort aber auch selten.

Dieses Setup ersetzt für mich Google Drive und das Gmail-Ökosystem plus NordVPN, Notion, 1Password und einen Authenticator.

Neugierig? Ich hinterlasse hier meinen Empfehlungslink.

Meine gemischte KI-Strategie

KI ist das Schwierigste, von Big Tech zu lösen.

Für sehr sensible KI-Aufgaben in meinem Workflow nutze ich Lumo AI. Es eignet sich gut für schnelle, private Anfragen, ohne großes Reasoning, Research etc., jedoch habe ich kein Abo, der Free Tier reicht mir aus.

Manchmal braucht man aber rohe Rechenleistung. Dafür habe ich angefangen, Mammouth zu nutzen, weniger aus Datenschutzgründen, sondern wegen des unschlagbaren Preis-Leistungs-Verhältnisses. Für 10€ Zugang zu allen gängigen KI-Modellen (einschließlich Bildgenerierung) ist einfach unglaublich.

Meine Standardauswahl bei Mammouth sieht so aus, man kann die Modelle nach Priorität sortieren, das ganz linke ist der Standard:

Die zwei Modelle, die ich am häufigsten nutze, sind Mistral Medium 3.1 und Flux 2 Pro oder Flux Fast. Für einfache Coding-Aufgaben verwende ich ebenfalls Mistral, bei größeren Codebasen gebe ich aber zu, dass ich auf Claude Code mit Opus zurückgreife.

Für Recherchen erledigt Mistral seinen Job. Bei komplexeren Themen liefert Gemini oft die besten Ergebnisse.

Und Flux für Bilder ist fantastisch, hat aber meiner Meinung nach einen großen Nachteil: Man muss sehr präzise Anweisungen geben. Während ein „Nano Banana” auch aus kurzen, einfachen Eingaben kreativ wird, braucht Flux genaue Vorgaben.

Was sich noch stark geändert hat: Ich nutze lokal in AnythingLLM Whisper um quasi Sprachnotizen zu machen oder aber auch Meetings aufzuzeichnen. Whisper ist hier imo 100 mal besser als Copilot (muss/darf ich an der Arbeit verwenden), weil es Multi-Lingual kann, was Copilot nicht beherrscht. Meeting Summaries etc. kann es auch und das alles lokal.

Browser, Suche und Sprache

• Browser: Ich bin zu Vivaldi gewechselt. Hochgradig anpassbar und respektiert die Nutzerdaten. Und nutze als Backup wenns mal auf ner Webseite klemmt Brave.

• Suche: Mein Standard ist Ecosia. Es funktioniert gut und Bäume beim Suchen zu pflanzen gibt dem gedankenlosen Scrollen eine nette Bedeutung. Manchmal muss ich aber doch auf Google zurückgreifen.

• Übersetzung: DeepL nutze ich schon ewig. Es ist nach meiner Einschätzung Google Translate in Sachen Nuancen und Qualität noch immer weit voraus.

• Rechtschreibprüfung: … Hier habe ich noch keine gute Alternative gefunden und bleibe bei Grammarly.

Infrastruktur: Hosting & Domains

Für meine Website und Domains habe ich alles zu Scaleway umgezogen.

Wer technisch versiert ist, wird diesen Wechsel zu schätzen wissen. Der Dienst ist schlank, einfach und bietet alles, was man als Cloud-Anbieter braucht ohne den Overhead von AWS oder Azure. Und günstiger ist er auch.

Kreativität & Aufgabenverwaltung

Canva… was soll ich sagen.

Dank einer Diskussion auf LinkedIn habe ich Superlist entdeckt, zu dem ich von Todoist gewechselt bin. Zwischendurch hatte ich auch kurz MeisterTask ausprobiert, aber das war reine Zeitverschwendung.

MeisterTask fühlt sich an wie ein Kindergartenspielplatz: zu viel buntes Design und zu wenig echte Funktionalität. Es ist zu 100% nicht intuitiv für irgendeinen Workflow.

Ich bin jetzt bei Superlist und sehr zufrieden.

Die Wirtschaftlichkeit: Datenschutz ist tatsächlich günstiger

Wir nehmen oft an, dass „Boutique”-Datenschutztools einen Aufpreis kosten. Meine Migration hat mir das Gegenteil bewiesen. Anfangs hatte ich nur von einer kleinen Ersparnis geschrieben, hatte aber die Kosten für Notion, Todoist, 1Password, Claude und Canva übersehen, da ich mich auf die „Office”-Suite konzentriert hatte.

• Alter Stack: ca. 83€/Monat

• Neuer EU-Stack: ca. 39€/Monat

Ich spare über 528€ im Jahr und besitze dabei den Großteil meiner Daten.

Was man dazu sagen muss:

Sovereignty ist kein An/Aus Schalter, sonder ergibt sich immer aus der Frage wie Souverän kann ich werden ohne das ich Autark bin und damit aber wiederum die Anknüpfung ans Weltgeschehen verliere. Denn…

Open Source und Autarkie oder wie man es in 2026 schafft wie im Mittelalter zu leben

Auf meinen original Post in Englisch hab ich sehr viel Feedback bekommen, positiv wie auch sämtliche Schwurbler, Weltverschwörer und “An jeder Ecke gibts nen Spion”. (Um die gehts mir aber nicht hierbei).

Denn wer sich auch sehr oft bemüht ist die Ecke “Souveränität gibts nicht”, “alles muss Open Source sein, koste es was es wolle”, “Du musst alles selbst hosten” usw.

Ganz ehrlich, das ist der größte Blödsinn. 99% der Menschen ist nicht in der Lage etwas selbst zu Hosten. Und das müssen sie auch nicht. Mir geht es darum einen Ansatz zu zeigen der für Jedermann/frau funktionieren kann.

Und natürlich gibt es Tools die noch losgelöster sind und noch mehr Autarkie versprechen. Viele dieser Lösungen sind aber er nicht Benutzerfreundlich oder Esthetisch in der Nutzung und Bedarfen sehr viel Pflege und Aufwand.

Wo Licht ist, ist auch Schatten

Ich möchte aber auch transparent sein: Nicht alles lässt sich vermeiden, und manches ist einfach umständlicher.

• Das „schlechte Gewissen”: Als Technikbegeisterter macht es mir zu viel Spaß mit Claude Code zu arbeiten. Das ist ein Luxus, den ich mir gönne. Ich schalte das Abo daher gelegentlich ein. Bin wieder im dauer Abo Modus, “Code” aber quasi täglich. Wer diesen Anwendungsfall nicht hat: → Mistral, Lumo

• Das soziale Netz: LinkedIn, GitHub, YouTube, Medium, Substack und Co. lassen sich einfach nicht umgehen, wenn man vernetzt bleiben will.

• Komfort: Google SSO fehlt mir. Es ist überall, und der Verlust dieses „Ein-Klick-Logins” macht das Leben ein kleines bisschen umständlicher. Ich habe alle Logins auf Proton Pass mit MFA und Passkey migriert, wo immer möglich. Aber man ist immer sehr in Versuchung den Google Knopf zu drücken.

• Office-Suite: Ich tue mich schwer, mich an LibreOffice und Collabora Online zu gewöhnen. Sie fühlen sich ähnlich wie MS Office an, aber eben „nicht ganz”. Da ich für den persönlichen Gebrauch nicht täglich Dokumente oder Tabellen erstelle, fühlt sich die Lernkurve steiler an als nötig. Egal → Proton Docs und Sheets erledigen das. Im schlimmsten Fall nehme ich für Präsentationen Canva, das zahle ich sowieso.

• Bloggen, Newsletter & Co.: Wie man sieht, schreibe ich auf Substack. Alternativen gibt es kaum, außer alles selbst zu hosten, aber das macht für mich gerade keinen Sinn.

Die unerwarteten Entdeckungen

Es gab auch einige positive Nebeneffekte. Die Proton-Plattform selbst bietet alles für den täglichen Bedarf.

Außerdem bin ich mit meiner Frau auf einen Duo-Plan umgestiegen. Gemeinsam haben wir 2TB Speicher für Mails, Dateien usw. Vorher hatten wir 30GB bei Gmail für etwas mehr Geld.

Proton Pass erstellt anonyme E-Mail-Adressen, falls man die echte Adresse nicht verwenden möchte, das spielt voll auf Protons Datenschutzphilosophie ein.

Superlist ist kostenlos für dieselben Funktionen, für die ich bei Todoist ein kleines Abo bezahlt habe.

Und schließlich kämpfe ich immer wieder mit Notizen. Ich habe alles getestet und angefangen, etwas Komplexes in Notion aufzubauen. Ich bin froh, dass ich es löschen und einfach Standard Notes jetzt nutze. Einfach gesagt: Es ist wie Notizen von Apple, aber Ende-zu-Ende-verschlüsselt und offline sicherbar. Am hilfreichsten war aber, dass ich endlich einen effizienten Umgang mit Notizen gefunden habe, schlank, sauber und funktional.

Fazit

Mit Proton, Scaleway, Mammouth, Vivaldi, Superlist und DeepL habe ich ein nützliches Werkzeugset aufgebaut, das meiner Meinung nach das übertrifft, was ich vorher hatte.

Die Apps sind übersichtlicher, die Benutzeroberflächen oft benutzerfreundlicher, und die Migration war überraschend einfach. Und das Beste: Ich kann mit meinem Tech-Stack mehr tun für weniger Geld.

Wer noch zögert, zu EU-gehosteten Lösungen zu wechseln: Wagt den Schritt. Es lohnt sich.

Aber die Antwort darauf ist nicht der Monolith. Das Problem ist nicht die Komplexität.
Was oft fehlt ist einfach ehrlich zu sein.

Was am Monolith-Argument stimmt

Ein Monolith ist im ersten Schritt einfacher. Ein Repository, ein Deployment, ein Logfile. Man braucht keinen großen CI/CD und GitOps Maschinerien, keine verteilte Tracing-Lösung, keine drei verschiedenen Datenbanken, die irgendwie konsistent bleiben müssen. Ein Entwickler kann das System lokal starten und verstehen, was passiert. Das kann ein riesen Vorteil sein. Und ja, für viele Unternehmen ist das genau die richtige Antwort. Nicht jedes Startup braucht die Architektur von Netflix.

So weit, so unstrittig.

Was gerne unter den Tisch fällt

Wenn der Monolith ausfällt, ist alles weg. Nicht ein Teilbereich, nicht “die Suche funktioniert gerade nicht, aber Checkout läuft”, sondern alles. Für viele Produkte ist das akzeptabel. Für andere existenzbedrohend. In einem meiner vorherigen Berufsleben wurde die Kernentwickler aus dem Urlaub zurück geflogen wenn unsere zentrale Anwendung stehengeblieben ist. Diese Abwägung wird in der aktuellen Debatte praktisch nie gemacht. Es geht immer um Entwicklungsgeschwindigkeit, Kosten, Komplexität und nie um operative Resilienz.

Klar, wenn ich nur 400 User habe ist der Schaden vermutlich gering. Hab ich aber ein Produkt/Service der viel genutzt wird, steigen Kunden auch schnell um. Kunden zahlen für Verfügbarkeit.

Dazu kommt: Monolithen skalieren in einer Dimension miserabel und zwar in der Dimension, die sich am wenigsten messen lässt. Sobald mehr als ein Team daran arbeitet, wird jeder Merge zur Verhandlung, jedes Deployment zum Risiko, jede Datenbankänderung zur Migration mit Eskalationspotenzial. Das passiert nicht ab Tag eins. Aber es passiert verlässlich ab einer bestimmten Größe.

Interessanterweiße werden diese Argumente oft auch gegen Mircroservices herangezogen. Meine Antwort darauf: Wenn dass die Gründe sind warums bei euch nicht läuft, dann ist es kein Microservice, dann ist es ein Micro-Monolith. Schlecht gebaut, vermutlich fehlendes Wissen und Kompetenz.

Der eigentliche Punkt

Wir reden so, als wäre die Wahl zwischen “Monolith” und “Microservices” eine reine Architekturfrage. Das ist sie nicht. Sie ist zu einem nicht unerheblichen Teil eine Frage, was die Organisation und deren Engineers eigentlich kann.

Und da sehe ich ein Problem, das größer ist als jede Architekturdiskussion: Die Skill-Lücke in vielen Unternehmen wird breiter, nicht schmaler. Die Generation, die noch wusste, wie ein Betriebssystem funktioniert, wie TCP eigentlich tickt, was eine Datenbank tut, wenn niemand hinguckt, die geht in Rente. Und in den Pipelines dahinter steht oft erschreckend wenig. Nicht weil die jungen Leute dumm wären. Sie sind es nicht. Sondern weil unser Ausbildungs- und Anreizsystem darauf optimiert ist, schnell produktiv zu sein, nicht tief zu verstehen. Wer ein Framework bedienen kann, gilt als Senior, bevor er je einen Production-Incident debuggt hat.

“Früher” (jaaaa früher), konnte man von einer Senior stelle träumen wenn man ein absoluter Experte ist auf seinem gebiet und darüber hinaus. Wenn man sehr viel gesehen hat, sehr viel gemacht hat, sehr viel erlebt hat. Heute, erwartet man das mit 1-2 Jahren Arbeitserfahrung und nem Master, man auch automatisch Senior ist. Außerdem fehlt es bei vielen Menschen an dem Antrieb sich ständig weiter zu entwickeln, sich neuen Schwierigkeiten zu stellen, an Themen zu arbeiten die man noch nicht gemacht hat.

Diese Zurückhaltung ist ein Problem. Sehr oft ist es sogar Angst. Weil die Kompetenzen und Erfahrungen fehlen. Diese werden unterschätzt, auch weil sich viele “Junge Talente” ins internet Stellen und über ihre Erfolge sprechen, ohne das die jemals jemand hinterfragt hat. Dies vermittelt ein Vollkommen falsches Bild.

Wenn jetzt also Unternehmen reflexartig zum Monolithen zurückkehren, dann passiert oft etwas, das niemand offen ausspricht: Es ist nicht primär eine technische Entscheidung. Es ist eine Anpassung an die verfügbare Kompetenz. Wir bauen die Systeme einfacher, weil wir die Leute nicht mehr haben, die komplexere Systeme betreiben können. Das ist auf kurze Sicht klug. Auf lange Sicht ist es eine Spirale: Einfachere Systeme produzieren auch einfachere Anforderungen an Entwickler. Anforderungen formen Kompetenzen. In zehn Jahren ist das Wissen, wie man verteilte Systeme baut, nicht nur knapp, es ist weg. (etwas überzogen gesprochen)

(Monolithen hier als einfach zu bezeichnen ist etwas übergriffig, als Enterprise Architekt hatte ich oft mit System zu tun die zwischen 1-2 Millionen Codezeilen hatten, und die alles andere als einfach waren.)

Die unbequeme Position

Meine These ist deshalb: Komplexität ist kein Bug der modernen IT, den wir wegoptimieren können. Sie ist die natürliche Folge davon, dass wir global verfügbare, hochintegrierte, datenintensive Produkte bauen wollen. Wer die nicht bauen will, kann mit einem Monolithen glücklich werden. Wer sie bauen will und das werden viele müssen, ob sie wollen oder nicht, muss die Komplexität tragen können. Und das bedeutet: Skill, nicht Architektur, ist die eigentliche Engstelle.

Die Frage ist also nicht “Monolith oder Microservices?”. Die Frage ist: Bauen wir Unternehmen, die in der Lage sind, anspruchsvolle Systeme zu betreiben oder akzeptieren wir leise, dass wir das nicht mehr können, und richten unsere Technik daran aus?

Beides ist legitim. Aber wir sollten ehrlich sein, welche Entscheidung wir gerade treffen. Der Monolith-Hype auf LinkedIn klingt nach Pragmatismus. Manchmal ist er aber auch nur Kapitulation in hübscher Verpackung. Manchmal ist er das laute Plappern von den offensichtliche Fakten, aber ohne dem Verständnis was dahinter steht.

Was denkt ihr? Sind Architekturentscheidung in eurem Umfeld noch eine technische Diskussion, oder längst eine ehrliche Bestandsaufnahme der eigenen Kompetenz?

Es gibt diesen Moment in fast jedem Budgetmeeting, in dem die Cloud‑Rechnung auf dem Tisch landet und niemand mehr weiß, warum sie schon wieder gestiegen ist. Wer als IT‑Entscheider die letzten zehn Jahre mitgegangen ist, hat den Erzählbogen verinnerlicht: „Cloud‑First” galt als Vernunftgebot und wer sich verweigerte, war Bedenkenträger. Aber es lohnt sich, diese Erzählung kühl zu prüfen.

Die Datenlage und ein wachsender Chor prominenter Praktiker legt eine andere These nahe: Cloud‑Provider und Managed Services werden systematisch überbewertet, ihre Vorteile stehen für viele Workloads in einem schlechten Preis‑Leistungs‑Verhältnis und der Preis dafür ist nicht nur monetär, sondern auch ein Verlust an betrieblicher Fähigkeit und Substanz.

27 Prozent Verschwendung sind kein Betriebsunfall

Die Zahlen aus dem Flexera State of the Cloud 2025/2026 sind ernüchternd: 27 bis 29 Prozent aller Cloud‑Ausgaben gelten als verschwendet, 84 Prozent der Unternehmen nennen das Cloud‑Kostenmanagement als ihre größte IT‑Herausforderung, und Budgets werden im Schnitt um 17 Prozent überschritten. Die FinOps Foundation, eigentlich eine Lobby‑Organisation der Cloud‑Optimierung, kommt zu ähnlichen Werten: Seit fünf Jahren stagniert die Quote zwischen 27 und 32 Prozent.

Stagnation ist hier das Signal. Diese Verschwendung ist strukturell, nicht zyklisch. Die IDC schätzt das globale Public‑Cloud‑Volumen 2024 auf 805 Milliarden Dollar mit Verdopplung bis 2028. Das hochgerechnete Verschwendungsvolumen liegt damit weltweit oberhalb von mindestens 200 Milliarden Dollar pro Jahr, Geld, das eben nicht in Innovation, Mitarbeiter oder Wettbewerbsfähigkeit fließt.

Wer glaubt, das sei ein Lückenproblem, das sich mit „etwas mehr FinOps” lösen lässt, sollte einen Blick auf die Margen werfen. Hyperscaler operieren mit operativen Margen von 30 bis 40 Prozent. Anders formuliert: Für jeden Euro Infrastruktur, den Sie konsumieren, zahlen Sie 30 bis 40 Cent Marge an Ihren Vermieter. Das ist ein legitimes Geschäftsmodell, aber es als „kosteneffizient” zu verkaufen, ist Marketing.

Die Repatriation‑Welle ist real aber differenziert

Fast jedem ist das Beispiel von 37signals bekannt. Diese senkten ihre Infrastrukturkosten von 3,2 Millionen auf 1,3 Millionen Dollar im Jahr, bei etwa 700 000 Dollar Einmalinvestition in eigene Server, die sich binnen eines Jahres amortisierte. Oft werden hier von Skeptikern Migrations- und Personalkosten noch ins Feld geführt. Ein offizielles Statement gibt es dazu nicht, jedoch Kommentare, dass dasselbe Team für Cloud und Applikation die Migration durchgeführt hat und weiterhin den Betrieb gewährleistet hat.

Dropbox sparte mit seiner Eigenbau‑Initiative „Magic Pocket” laut S‑1‑Filing rund 75 Millionen Dollar in zwei Jahren. GEICO stand 2021 bei über 300 Millionen Dollar Cloud‑Spend pro Jahr, einem 2,5‑fachen Budget‑Overrun, und reduziert seither über offene Hardware‑Standards die Compute‑Kosten pro Core um 50 Prozent.

Der Barclays CIO Survey Q4 2024 zeigt, dass 83 Prozent der CIOs zumindest einige Public‑Cloud‑Workloads zurück on‑prem oder in Private Clouds verlagern wollen. IDC beziffert für 2024 den Anteil der Unternehmen mit Repatriation‑Plänen auf rund 80 Prozent.

Wichtig für die Einordnung: Es geht nicht um den theatralischen Cloud‑Exit. Nur 8 bis 9 Prozent der Unternehmen planen Voll‑Repatriationen. Die Bewegung ist selektiv und ökonomisch motiviert, aber die Ergebnisse sprechen für sich.

Der unterschätzte Schaden: Verlust an Betriebskompetenz

Aber es wird noch unbequemer. Die Linux Foundation berichtet, dass 92 Prozent der Organisationen Schwierigkeiten haben, qualifizierte Cloud‑Talente zu finden. Mehr als 75 Prozent haben Projekte wegen Skill‑Lücken abgebrochen. Das Problem dahinter ist eines, über das in Vorstandsetagen ungern gesprochen wird: Eine ganze Engineering‑Generation hat schlicht nie ein Storage‑Tier dimensioniert, ein Netzwerk segmentiert oder eine Datenbank auf Bare‑Metal getunt. Wer „Cloud‑Native” gelernt hat, kann oft Terraform schreiben, aber keine echte Kapazitätsplanung machen. Und AI wird uns noch nicht davor retten.

Cloud‑Veteran David Linthicum bringt es auf den Punkt: Die durchschnittliche IT‑Abteilung habe gar nicht mehr das Engineering‑Talent, um größere Cloud‑Workloads zu repatriieren. Das ist die eigentliche Lock‑in‑Falle, nicht die proprietären APIs, sondern das organisationale Vergessen.

Verschärft wird das durch Outsourcing und Offshoring. Studien zeigen, dass 22 Prozent der Outsourcing‑Beziehungen binnen zwei Jahren scheitern, 48 Prozent spätestens in fünf, vorrangig wegen Qualitäts‑ und Kommunikationsproblemen. Was als Effizienzhebel verkauft wird, ist häufig ein systematischer Kompetenztransfer aus dem eigenen Haus und im schlimmsten Fall eine Erosion der Fähigkeit, Architekturentscheidungen überhaupt noch zu beurteilen. Offshore‑Modelle multiplizieren diesen Effekt durch Zeitzonen‑, Sprach‑ und Kulturfriktion und durch fluktuationsbedingten Wissensabfluss.

Meiner Meinung nach ist es eine absolute Vollkatastrophe, die von den meisten Unternehmen bewusst ignoriert wird.

Der Multi‑Cloud‑Sumpf

Wer geglaubt hat, Multi‑Cloud sei die Antwort auf Vendor‑Lock‑in, ist meist enttäuscht: 99 Prozent der Unternehmen berichten von Schwierigkeiten beim Multi‑Cloud‑Management; im Schnitt nutzen sie 2,4 Public‑Cloud‑Provider, 73 Prozent sagen, Cloud habe ihre Operations komplexer gemacht. Egress‑ und Inter‑Region‑Gebühren machen laut Gartner 10 bis 15 Prozent der Gesamtkosten aus und wirken als ökonomische Mauer zwischen den Anbietern. Multi‑Cloud ohne übergreifende Steuerung ist nicht Freiheit, sondern multiplizierte Komplexität.

Übrigens sind hier europäische Anbieter in der Regel praktikabler, da sie selten Egress-Kosten verrechnen.

Die Lösung: Provider zur API degradieren

Die strategische Antwort liegt nicht im Schwarz‑Weiß‑Denken („alles raus” vs. „alles rein”), sondern in einer eigenen Plattform‑Schicht über den Cloud‑Providern. Konzeptionell bedeutet das:

• Provider = austauschbarer Infrastruktur‑Lieferant. Compute, Storage, Netzwerk und GPUs werden konsumiert wie Strom, in der Region, beim Anbieter und zur Tageszeit, an dem sie am günstigsten oder geeignetsten sind. Die Preisspreizung macht das ökonomisch zwingend: Bei aktuellen GPU‑Pricing‑Vergleichen liegen H100‑Stundenraten je nach Provider zwischen rund 0,47 und über 14 US‑Dollar pro GPU‑Stunde. Wer hier statisch einkauft, verschenkt Faktoren, nicht Prozente.

• Eine Abstraktionsschicht. Konzeptionell ein „Supercloud”‑ oder Plattform‑Engineering‑Layer, kapselt provider‑spezifische APIs, vereinheitlicht Identity, Policies, Observability und Deployment‑Pipelines. Gartner prognostiziert, dass bis 2026 80 Prozent der großen Engineering‑Organisationen eigene Plattform‑Teams aufbauen werden. Das ist kein Hype, sondern eine Konsequenz aus der gelebten Komplexität.

• Agentenbasierte Architektur‑Empfehlungen sind das nächste “künstliche” Glied: Multi‑Agent‑Systeme, die fortlaufend Kosten‑, Performance‑, Latenz‑ und Compliance‑Daten konsolidieren und Vorschläge machen, welcher Workload wohin gehört, idealerweise mit nachvollziehbarer Begründung statt Black‑Box‑Empfehlung.

Was IT‑Entscheider in Betracht ziehen sollten

Drei Konsequenzen, die sich aus der Datenlage ableiten:

Erstens: Operations‑Kompetenz wieder ins Haus holen. Ein eigener Plattform‑Layer braucht echte Engineers, die Hardware, Netzwerk, Storage und Workload‑Ökonomie verstehen. Das ist teuer, aber 27 Prozent verschwendete Cloud‑Ausgaben sind teurer.

Zweitens: Cloud strategisch nutzen, nicht religiös. Cloud bleibt brillant für Lastspitzen, schnelle Experimente und Greenfield‑Projekte, in denen Time‑to‑Market regiert. Sie ist aber typischerweise das schlechteste Modell für vorhersehbare, datenintensive, dauerlaufende Workloads. Kostentechnisch. Und Enterprises reitzen regelmäßig die Standardservices von Providern aus, sodass diese selbst gebaut werden müssen. Genau dort liegen die Repatriation‑Cases.

Drittens: In eine Abstraktionsschicht investieren. Wer seine Workloads so kapselt, dass sie ohne Architektur‑Rewrite zwischen Providern aber auch zu eigener Hardware wandern können, gewinnt sowohl Verhandlungsmacht als auch Resilienz. Das ist die einzig nachhaltige Antwort auf Egress‑Fees, Vendor‑Lock‑in und unkontrollierte Margen. Und vermutlich einer der wenigen Schritte in Richtung Souveränität.

Ich muss aber auch betonen, dass “die Cloud” nicht das Problem ist. Wer sie als das behandelt, was sie wirklich ist, ein Infrastruktur‑Lieferant unter mehreren, baut eine IT, die wieder beweglich, kompetent und wirtschaftlich gesund ist. Genau das ist heute der eigentliche Wettbewerbsvorteil.

Caveats zur Quellenlage

• Die 83‑%‑Repatriation‑Zahl (Barclays CIO Survey) wird von Channelnomics u. a. relativiert: Sie misst Unternehmen, die irgendeinen Workload zurückholen, nicht das Volumen. Die Aussagekraft ist eingeschränkt; richtig ist aber, dass Repatriation ein Trend, kein Massenexodus ist (IDC: nur 8–9 % Voll‑Repatriation).

• Einige der Repatriation‑Erfolgszahlen (37signals, Dropbox) stammen aus Selbstauskünften der Unternehmen bzw. SEC‑Filings. Sie sind plausibel, aber nicht unabhängig auditiert. 37signals selbst weist darauf hin, dass die Rechnung nicht 100 % apples‑to‑apples ist (Hardware‑Refresh, Power, Cooling werden je nach Berechnung mit/ohne berücksichtigt).

• Andrew Tanenbaum ist nicht primär ein Cloud‑Kritiker; seine Bekanntheit stammt aus der Linux‑Microkernel‑Debatte 1992. Im Artikel wurde er bewusst nicht als Cloud‑Kritiker zitiert. Wer eine akademisch fundierte Cloud‑Skepsis sucht, findet sie eher bei Bryan Ford (Yale, „Icebergs in the Clouds”).

• Die GPU‑Preise sind volatil; insbesondere H100‑Spot‑/Marketplace‑Preise schwanken stark. Der Punkt, mehrfache Preisspreizung zwischen Anbietern, bleibt aber stabil.

• Der „Supercloud”-Begriff ist konzeptionell, nicht standardisiert. Manche nennen es auch Sky Computing. Im Artikel wurde er deshalb umschrieben und nicht als Produktkategorie verwendet. Ich persönlich würde eher für eigens gebaute Platform-of-Platforms Ansätze plädieren.

• Cloud‑Waste‑Quoten variieren je nach Studie zwischen 21 % (Harness, eng definiert) und bis zu 47 % (manche Surveys, weit definiert). Die genannte Spanne 27–32 % ist der robuste Median über Flexera, FinOps Foundation und Datadog hinweg.

Daher steht dieser Blog/Newsletter/Brain Dump ganz im Sinne von:

Warum ich?

Mein persönlicher Anspruch ist es, realistische Perspektiven zu gewinnen. Wirklich zu verstehen, was möglich ist, welche Auswirkungen das hat und diese entsprechend einzusortieren. Hypes betrachten, aber nicht selbst süchtig werden.

Seit über elf Jahren bin ich in der Technologie-Beratung unterwegs. Angefangen als Enterprise Architect im Office of the CIO bei ProSiebenSat.1, später als Management Consultant und Senior Cloud Native Architect, und heute als Gründer und Chief Technology Advisor von Liquid Reply. Diese Jahre haben mir eines sehr deutlich gezeigt: Zwischen dem, was auf Konferenzen versprochen wird, dem, was in Architektur-Boards beschlossen wird, und dem, was am Ende tatsächlich in Produktion läuft, liegen oft Welten. Genau in diesen Lücken bewege ich mich beruflich und genau darüber will ich hier schreiben.

Als Enterprise Architect habe ich gelernt, Technologieentscheidungen nicht isoliert zu betrachten, sondern im Kontext von Geschäftsmodellen, Organisationsstrukturen und langfristigen Auswirkungen. Als Berater habe ich gesehen, wie unterschiedlich die gleiche Technologie in einem DAX-Konzern, einem Mittelständler oder einem Scale-up wirkt und warum eine “Best Practice” selten überall passt. Und als Gründer habe ich am eigenen Leib erfahren, wie sich strategische Entscheidungen anfühlen, wenn man selbst die Verantwortung trägt.

Dazu kommen drei Welten, die sich selten in einem Raum treffen: der Maschinenraum von Engineering-Teams, die Vorstandsetagen, in denen über Strategie und Budget entschieden wird, und die internationale Open-Source-Community, in der die Technologien entstehen, über die der Rest der Welt erst Jahre später diskutiert.

Mein Open-Source-Hintergrund verankert das Ganze:

• knapp 3 Jahre im Kubernetes Release Team gearbeitet

• sitze im Advisory Board der Linux Foundation Europe

• bin Cloud Native Computing Foundation (CNCF) Ambassador und Governance Board Member

• organisiere Community Events/Meetups/Events wie den Cloud Native Summit Munich

• Als Speaker (zu Deutsch Vortragsredner), mit über 70 Vorträgen in den letzten Jahren, komme/kam ich in sehr intensive Austauschen mit Menschen aus aller Welt, Branchen und Profilen

Mein persönlicher Anspruch ist es, realistische Perspektiven zu gewinnen. Wirklich zu verstehen, was möglich ist, welche Auswirkungen das hat und diese entsprechend einzusortieren. Hypes betrachten, aber nicht selbst süchtig werden. Mein Ziel ist es, dass du danach besser entscheiden kannst, egal ob du Engineer, Architect, Founder oder Führungskraft bist.

Welche Themen erwarten dich hier?

Grob gesagt: alles, was an der Schnittstelle zwischen moderner IT, Geschäftsrealität und gesellschaftlicher Wirkung liegt. Konkret werden wiederkehrende Themen sein:

• (Cloud) Sovereignty & digitale Souveränität 👉 was sie wirklich bedeutet jenseits des politischen Schlagworts, und was sie für Unternehmen in Deutschland und Europa praktisch heißt.

• AI Engineering 🧠 wie (Gen)AI tatsächlich in Produktion landet, was funktioniert, was scheitert, und welche Architekturen sich gerade herauskristallisieren, und was bedeutet das für den Homo Sapiens.

• Platform Engineering 🧪 vom Internal Developer Platform zur AI-Developer Platform: Menschen, Prozesse und Kultur; ab und an etwas Technik.

• Open Source als strategischer Hebel 🏗️ wie Communities, Governance und Projekte das gesamte Spielfeld definieren und verschieben.

• Leadership & Entrepreneurship in der Tech-Welt 🧙 was es heißt, Engineering-Organisationen zu führen, ohne den Bezug zur Technik oder den Menschen zu verlieren.

• Soziotechnologische Beobachtungen 🪡 der eigentliche rote Faden: wie all das oben genannte unsere Arbeitsweise, unsere Unternehmen und letztlich unsere Gesellschaft formt.

Mal werden es kurze Brain Dumps sein, mal ausführlichere Analysen, mal einfach ein O-Ton aus einem Gespräch, der hängengeblieben ist. Versprochen ist nur eines: keine Pressemitteilungen, kein verkapptes Marketing, sondern das, was ich tatsächlich denke.

Mehr gibt’s hier

Normalerweise schreibe ich auf Englisch 👇

Zeitgeist of Bytes

Cloud sovereignty, AI, and the architecture of digital power. One byte at a time 📩

By Max

Zusätzlich können wir auf LinkedIn diskutieren. Ich komme mit regelmäßigem Input zu (Cloud) Sovereignty, AI Engineering, Platform Engineering, Leadership, und Entrepreneurship.

Sag Hallo ➡️ https://www.linkedin.com/in/maxkoerbaecher/