Moin.

Wir sind eine große Familie, sang Peter Alexander 1973, und mancher Chef holt den Schlager auch heute nochmal heraus. Während das Lied eine Geschmacksfrage ist, lädt der Satz im Firmenkontext dazu ein, aufmerksam zu werden. „Wir sind eine große Familie“, sagt der Chef. Klingt super, finde ich. Oder doch nicht?

Auch Familien haben ihre Schattenseiten. So wurden 2023 mehr als 250.000 Menschen das Opfer häuslicher Gewalt. Davon sind mehr als 78.000 Opfer innerfamiliärer Gewalt zwischen nahen Angehörigen. (Quelle: BKA-Lagebild, BMFSFJ)

Vermutlich meint mein Chef das nicht, wenn er von Familie spricht, aber was denn dann? Welchen Zweck verfolgt er mit seiner Aussage? Was will er von mir? Welches Verhalten soll meinerseits hervorgerufen werden? Und, last, but not least: Wie gehe ich damit um?

Am liebsten würde ich es bei den Fragen belassen, weil Ihr bestimmt auch eigene Antworten parat habt. Dann wäre der Beitrag allerdings sehr kurz. Deshalb ein Vorschlag: Macht beim Lesen eine Pause, denkt über die Fragen nach und schreibt Antworten in die Kommentare. Danach könnt Ihr meine Antworten lesen. Ich bedanke mich im Voraus für Eure Beiträge.

Ein Märchen

Zum Zweck der Äußerung: Meine beste Antwort lautet „Bindung“. Wer das sagt, möchte andere an sich binden; möglicherweise vor dem Hintergrund einer unangenehmen Aufgabe oder bevorstehenden negativen Veränderung. Zumindest denke ich, dass es nicht nötig ist, bei der Bindung nachzuhelfen, wenn das Arbeitsleben im Augenblick das reinste Paradies ist. Wer sollte dann gehen wollen?

Bindung an sich ist ja nicht so schlecht, allerdings stellt sich eine weitere Frage: Was ist, wenn die wirtschaftliche Lage für die Firma schlechter wird? Wir sind doch eine große Familie, oder? Hier wird doch niemand gefeuert, oder? Wir alle kennen die Wahrheit und das genügt, um die Mär der großen Familie als genau das zu entlarven: ein Märchen. Es gibt Firmen, die eine Ausnahme darstellen, aber dort ist es vermutlich nicht nötig, auf die starke Bindung mit der Familienaussage hinzuweisen.

Damit kommen wir zur wichtigsten Frage: Wie gehe ich damit um? Das hängt natürlich stark vom Einzelfall ab, sodass ich hier keine universelle Antwort anbieten kann. Mein Vorschlag ist, klar zu kommunizieren, wie das, was man gerade hört, ankommt.

Zum Einstieg vielleicht eine Erwiderung der Art: „Wenn ich höre, dass wir eine Familie sind, habe ich den Eindruck/bekomme ich das Gefühl, dass …“

Bindung funktioniert anders

Wenn es um Bindung geht, kann man deutlich machen, dass wir keine Familie sind und Bindung anders funktioniert. Das ist der richtige Zeitpunkt, die eigene Motivation auszusprechen. Was treibt Dich an und was möchtest Du demnächst oder mittelfristig erreichen? Wenn die Wir-sind-eine-Familie-Aussage mit der unangenehmen Aufgabe wie Überstunden für einen längeren Zeitraum verbunden ist, ist es ein guter Zeitpunkt, über Gegenleistungen zu sprechen. Die Palette ist breit gefächert. Man kann über Überstundenausgleich, Sonderurlaub, Fortbildungen oder natürlich Prämien sprechen. Das sind alles persönliche Benefits.

Alternativ kann man auch Veränderung in der Arbeit ansprechen. Geht es beispielsweise darum, dass ein vorgegebener Termin in der Produktentwicklung nicht ohne Überstunden des Teams gehalten werden kann, ist es vielleicht der richtige Zeitpunkt, auf die Ursache einzugehen. Eine mögliche Forderung wäre dann Mitspracherecht bei zukünftigen Terminen. Wozu sollte man für das anstehende Release Überstunden machen, wenn absehbar ist, dass es beim nächsten Release genauso läuft?

In jedem Fall verstehe ich „Wir sind eine Familie“ als Einstieg in eine Verhandlung. Wer sie als Person oder als Team nicht nutzt, verschenkt die Chance für eine Verbesserung.

Erst Lesen, dann Hören

Im Podcast Escape the Feature Factory greife ich ausgewählte Themen des Blogs auf und diskutiere sie mit einem Gast. Durch den Austausch lerne ich eine zweite Perspektive kennen. Wenn Du auch daran interessiert bist, findest Du den Podcast bei Spotify, Deezer, Amazon Music, und Apple Podcasts. Wenn Du die Themen, die ich im Blog anspreche, in Deiner Firma verbessern möchtest, komm‘ in unsere Leadership-Community für Softwareentwicklung.

(rme)

In modernen Softwareprojekten ist das Deployment längst keine einmalige Aktion mehr, sondern ein kontinuierlicher Prozess. Anwendungen bestehen aus Dutzenden oder Hunderten von Services, laufen in Containern und erhalten oft mehrmals am Tag ein Update. Um neue Funktionen schrittweise zu aktivieren, greifen Teams auf Feature Flags oder Konfigurationsschalter zurück. Diese Flexibilität ist ein Segen – und gleichzeitig eine erhebliche Gefahrenquelle.

Muster 5: Deployment, Konfiguration und Flags: Wenn ein Schalter Millionen kostet

Ein eindrückliches Beispiel liefert der Fall Knight Capital aus dem Jahr 2012. Das Unternehmen war ein Schwergewicht im elektronischen Handel an der US-Börse und wickelte täglich Millionen von Transaktionen ab. Am 1. August 2012 spielte Knight ein neues Softwareupdate aus, das eine Funktion namens „Retail Liquidity Program“ unterstützen sollte. Die Bereitstellung lief jedoch schief: Ein Feature Flag, das ursprünglich für Testzwecke existierte, wurde auf einem von acht Servern nicht korrekt aktualisiert.

Was folgte, war ein Paradebeispiel für die Kaskade aus Konfigurationsfehlern und fehlender Deployment-Sicherheit: Auf sieben Servern lief die neue Logik wie geplant, ein einzelner Server führte beim Start jedoch alten Code aus, der längst nicht mehr produktiv sein sollte – weil das Flag dort nicht korrekt gesetzt war.

Dieser alte Code enthielt eine Legacy-Routine, die fälschlicherweise massenhaft Kaufaufträge generierte. Innerhalb von nur 45 Minuten verursachte Knight Capital rund 440 Millionen US-Dollar Verlust. Das Unternehmen stand am Rand der Insolvenz, nur eine schnelle Übernahme und externe Finanzierung retteten es vor dem Aus.

Die Lehren aus diesem Vorfall sind für jede Organisation relevant – ob Börsenhandel, E-Commerce oder SaaS-Betrieb:

1. Feature Flags brauchen einen Lebenszyklus: Ein Schalter, der nicht dokumentiert, nicht versioniert und nicht befristet ist, wird irgendwann zum Risiko. Flags müssen ein Ablaufdatum, einen Owner und eine Entfernungsperspektive haben.
2. Deployments müssen atomar und konsistent sein: Es reicht nicht, acht Server irgendwann nacheinander zu aktualisieren. Ohne Sicherstellung, dass alle Instanzen dasselbe Release und dieselbe Konfiguration fahren, entstehen Split-Brain-Situationen. Moderne CI/CD-Pipelines oder Kubernetes-Rollouts lösen dieses Problem durch atomare Deployments und Health-Checks. „Atomar“ bedeutet hier nicht, dass alle Instanzen gleichzeitig umgestellt werden, sondern dass innerhalb eines Deployments keine Mischzustände existieren.
3. Immutable Infrastructure ist die beste Versicherung: Systeme, die man nicht nachträglich verändert, sondern bei Änderungen komplett neu instanziiert, vermeiden Zombiecode. Wer ein neues Image ausrollt, kann sicher sein, dass kein Server alten Code im RAM behält.
4. Staged Rollouts und Kill-Switches reduzieren den Schaden: Große Änderungen sollten zunächst bei einem Bruchteil der Instanzen aktiviert werden, am besten begleitet von automatisierten Metriken. Ein zentraler Schalter zum sofortigen Abschalten (Kill-Switch) kann Milliardenverluste verhindern. Jede Stufe eines Rollouts ist dabei für sich konsistent, aber die Ausweitung auf alle Instanzen erfolgt schrittweise.
5. Runbooks und Übung unter Realbedingungen: Selbst die beste Technik hilft wenig, wenn im Ernstfall niemand weiß, wie man reagiert. Unternehmen, die Notfallprozeduren für fehlerhafte Deployments proben, reagieren schneller und souveräner.

Interessant ist, dass Knight Capital nicht am Fehlen von Technologie scheiterte. Die Tools für sichere Deployments existierten längst. Es war vielmehr ein Organisations- und Prozessversagen, bei dem technische Schulden (wie Legacy-Code und Flag-Wildwuchs) und menschliche Routine („haben wir immer so gemacht“) zusammenkamen.

Für moderne Cloud- und Webprojekte gilt übrigens dasselbe Muster: Wer Feature Flags einsetzt, ohne Lifecycle und Dokumentation zu etablieren, erzeugt unbemerkt eine tickende Zeitbombe. Und wer Deployments manuell oder halbautomatisch ausrollt, nimmt Inkonsistenzen in Kauf, die sich irgendwann rächen.

Die Lösung ist eine Kombination aus Disziplin und Automatisierung:

• Feature Flags werden wie Code behandelt, mit Versionierung, Owner und Entfernungspflicht.
• Deployments laufen atomar und reproduzierbar, am besten als Infrastructure as Code.
• Ein zentraler Kill-Switch schützt vor irreversiblen Schäden.

Knight Capital ist das prominenteste Beispiel, aber ähnliche Zwischenfälle gab es seither mehrfach – von falschen Cloudkonfigurationen bis zu versehentlich aktivierten Debug-Modi in der Produktion. Und jedes Mal zeigt sich erneut: Ein einziger vergessener Schalter kann ausreichen, um ein Unternehmen ins Wanken zu bringen.

(who)

Apple hat sein Monopol im App Store für iPhones und iPads missbraucht und jahrelang viel zu hohe Gebühren verrechnet. So urteilt das für England und Wales zuständige Wettbewerbsgericht Competition Apeal Tribunal. Es schreibt Apple umfangreiche Rückerstattungen an Kunden vor, denen in den meisten Fällen zweistellige Pfundbeträge winken. Da es aber Millionen betroffene Kunden gibt, geht es in Summe um hunderte Millionen Pfund. Sollte die Gerichtsentscheidung rechtskräftig werden, ist sie eine empfindlichere Niederlage für Apple, als es dieser Betrag erscheinen lässt.

Denn das Urteil betrifft den Zeitraum 1. Oktober 2015 bis 15. November 2024, und damit mehr als fünf Jahre vor dem EU-Austritt Großbritanniens. Entsprechend stellen die drei Richter auch auf EU-Recht ab. Ihre einstimmige Entscheidung hat also Vorbildwirkung nicht nur für Schottland und Nordirland, sondern für die gesamte EU. Außerdem läuft seit 2023 beim selben Gericht eine parallele Sammelklage im Namen jener App-Anbieter, die ihre Software sowie In-App-Verkäufe über denselben App Store abwickeln mussten. Ein Urteil zugunsten Apples in dem Parallelverfahren wäre eine Überraschung.

Das am Donnerstag ergangene Urteil geht auf eine bereits 2021 erhobene Sammelklage der Britin Dr. Rachael Kent zurück. Laut eigener Angabe ist sie die erste Frau, die je eine Sammelklage in Großbritannien angestrengt hat. Die Wissenschaftlerin forscht im Bereich digitale Kultur und Gesellschaft und lehrt am King’s College London. Als Besitzerin eines iPhones konnte sie Apps für ihr Handy ausschließlich über Apples App Store beziehen, weil Apple seit jeher alternative Vertriebswege verbietet. Dieses Monopol macht die Sache teuer, denn Apple verrechnet regelmäßig 30 Prozent Gebühren. Kent ging zu Gericht (Dr. Rachael Kent v Apple Inc and Apple Distribution International Ltd, Az. 1403/7/7/21).

30 Prozent Gebühr „exzessiv und unfair“

Laut Urteilsbegründung hat Apple tatsächlich sein Monopol in zwei Märkten missbraucht: (Ver)Kauf von Apps, sowie Umsätze in Apps. In beiden Märkten hat Apple jeglichen Wettbewerb ausgeschlossen. Apple argumentierte, das sei durch Leistungswettbewerb gerechtfertigt, schließlich seien iPhones und iPads eine feine Sache. „Apples Verhalten kann in diesem Zusammenhang nicht als Leistungswettbewerb gerechtfertigt werden, da Apple überhaupt nicht im Wettbewerb steht“, heißt es in der Zusammenfassung der fast 400 Seiten dicken Urteilsausfertigung. Verschärfend komme hinzu, dass Apple auch für In-App-Käufe zur Nutzung seines Zahlungsabwicklungssystems zwinge.

Damit habe Apple mehrfach gegen Artikel 102 des Vertrages über die Arbeitsweise der Europäischen Union sowie gegen Kapitel II des britischen Wettbewerbsgesetzes verstoßen. „Apple hat seine Marktmacht missbraucht, indem es exzessive und unfaire Preise verlangt hat, in Form von Kommissionen für den Vertrieb von iOS-Apps und für die Zahlungsabwicklung von In-App-Käufen“, heißt es in der Urteilszusammenfassung weiter.

Die Differenz zwischen den verlangten Gebühren und den Kosten sei signifikant und dauerhaft. Das zeige, dass die Preise überhöht sind. Der Tarif sei sowohl für sich genommen unfair, als auch im Vergleich zu den Online-Shops Epic Games‘, Microsofts und Steams.

Apples Argumente fallen flach

Apple versuchte sich dadurch zu rechtfertigen, dass der Wettbewerbsausschluss zur Erreichung legitimer Ziele notwendig und verhältnismäßig sei. Beides lehnt das Gericht ab. Außerdem meinte Apple, ein einzelner App Store sei effizienter; davon würden Verbraucher in größerem Umfang profitieren, als sie durch die hohen Preise belastet würden. Auch das akzeptiert das Gericht nicht, schließlich schließe Apple jeglichen Wettbewerb in den beiden Märkten von vornherein aus.

Statt 30 Prozent sind laut Urteil maximal zehn Prozent für In-App-Käufe und maximal 17,5 Prozent für App-Käufe gerechtfertigt. Die Differenz habe allerdings nicht nur Kunden, sondern auch die Anbieter der Apps und App-Inhalte belastet. Die Anbieter hätten nur die Hälfte der Mehrbelastung an ihre Kunden weiter verrechnet.

Diese Hälfte soll Apple für den gut neun Jahre langen relevanten Zeitraum rückerstatten, zuzüglich acht Prozent Zinsen. Die andere Hälfte müssen sich die App-Anbieter erstreiten. Das dafür anhängige Verfahren heißt Dr Sean Ennis v Apple Inc and Others (Az. 1601/7/7/23).

Über die genauen Modalitäten der Rückerstattung sollen sich die Streitparteien tunlichst einigen und das Ergebnis bei der nächsten Tagsatzung, frühestens im November, präsentieren. Parallel kann Apple die Zulassung von Rechtsmitteln beantragen, was das Unternehmen sicher tun wird. Das Gericht muss dann entscheiden, gegen welche Teile des Urteils Apple berufen kann.

(ds)