Attractiveness Principle

Beschreibung

Das Attractiveness Principle (Attraktivitätsprinzip) ist eine Variation des "Limits to Growth" Archetyps. Es besagt, dass jedes wachsende, hocherfolgreiche Konstrukt irgendwann auf harte Grenzen stößt. Die Besonderheit hier: Ein System kann meist nicht alle Wachstumsfaktoren gleichzeitig auf maximalem Niveau halten. Ein Produkt, das wächst, weil es superschnell, billig und extrem feature-reich ist, wird ab einer gewissen Größe eine (oder mehrere) dieser Eigenschaften opfern müssen, um nicht völlig zu kollabieren. Wenn man als Firma nicht bewusst wählt, welche Eigenschaft man schlechter werden lässt, entscheidet das System blindlings für einen – meistens mit dramatischen Folgen.

Feedback Loops

Die Engine ist ein riesiger, wachstumsfördernder *Reinforcing Loop* (Gutes Produkt -> Mehr User -> Mehr Umsatz -> Gutes Produkt). Dieser treibt das System gegen mehrere, parallele *Balancing Loops* (Grenze der Serverkapazität, Grenze des Supports, Grenze der Entwickler-Kognition). Je härter der Wachstums-Motor pusht, desto brutaler schlagen die Kapazitätsgrenzen zurück und bremsen das Wachstum schmerzhaft ab.

Architekturbeispiel

Ein kleines Startup baut eine monolithische SaaS-Applikation. Weil sie blitzschnell neue Features einbauen (Time-to-Market = Top Attraktivität), strömen Tausende Neukunden ins System. Dadurch platzt die Datenbank aus allen Nähten, was die Antwortzeiten extrem erhöht (Performance sinkt). Die Entwickler versuchen, die Performance zu retten (Balancing Loop 1), müssen dafür aber das Feature-Tempo stoppen (Attraktivität 2 sinkt). Als nächstes kollabiert der Customer-Support unter Bug-Reports. Die Firma kann nicht alles gleichzeitig skalieren (Performance + Feature-Geschwindigkeit + Support-Qualität) und muss bewusst entscheiden, welche Eigenschaft sie "verschlechtert", um weiter wachsen zu können.

Organisationsbeispiel

Ein bestimmtes Platform-Engineering-Team leistet exzellente Arbeit und ist extrem hilfsbereit ("Full Glove Service"). Dadurch wird es in der ganzen IT rasend beliebt. Innerhalb kurzer Zeit lagern hunderte Feature-Teams all ihre Infrastruktur-Tickets bei diesem kleinen Team ab. Das Platform-Team erstickt an der eigenen Attraktivität. Da sie nicht "Nein" sagen wollen, leiden die Ticket-Antwortzeiten massiv. Die Entwickler sind plötzlich unfassbar wütend auf das einstige Wunder-Team. Die ungesteuerte Nachfrage hat das Angebot zerstört.

Diagnosefragen

1.Haben wir intern eine so brillante, aber nicht skalierbare "Paved Road" gebaut, dass das verantwortliche Team unter der Last der Adoption gerade ausbrennt?

2.Weigern wir uns als Management konsequent, Abstriche bei einem Verkaufsargument (Geschwindigkeit, Preis, Qualität) zu machen, und zerschießen uns dadurch das gesamte System?

3.Welche verdeckten Kapazitätsgrenzen (z.B. Onboarding-Tempo neuer Entwickler) werden unser aktuelles Hyperscaling im Markt in 6 Monaten brutal abwürgen?

Diagramm

Wie du das Muster im Alltag erkennst

Die kybernetische Lektion lautet: Akzeptiere, dass du nicht alle Bälle gleichzeitig oben halten kannst, wenn das System das Limit erreicht. Wahre Strategie ist nicht die Entscheidung, worin man großartig sein will, sondern die fundamentale Wahl, worin man bewusst "schlecht" sein wird (Trade-off). Man muss gezielt Wachstumsbremsen einbauen (z.B. Wartelisten für das Produkt, harte API-Rate-Limits), solange man noch nicht bereit ist, die nächste Stufe der Systemkomplexität zu meistern.

Wodurch sich das Muster von ähnlichen Dynamiken unterscheidet

Während *Limits to Growth* meist nur *eine* offensichtliche Grenze hat, die gebrochen wird, zeichnet sich das *Attractiveness Principle* durch die Qual der Wahl zwischen *mehreren* umkämpften Attraktivitäts-Dimensionen (Preis VS Performance VS Features) aus, die sich gegenseitig kannibalisieren.

Wie du vom Muster zur Reaktion kommst

Wenn dein System unter seinem eigenen Erfolg zu zerbrechen droht:

1.Identifiziere die verschiedenen Dimensionen, die euch attraktiv gemacht haben (Geschwindigkeit, Qualität, Erreichbarkeit, Null Bugs).

2.Triff eine bewusste Entscheidung als Architektur-Board, welche Eigenschaft ihr für die nächsten 12 Monate *absichtlich* vernachlässigt (z.B. "Wir bauen 6 Monate keine neuen Features, sondern nur Stabilität").

3.Kommuniziere diesen Trade-Off gnadenlos an Stakeholder, bevor das System von alleine und ungeplant kollabiert.

Erste nächste Schritte

Verwende das "Eisenhower Matrix"-Prinzip des CAP-Theorems (Consistency, Availability, Partition Tolerance) zur Erklärung: Es ist physikalisch unmöglich, in verteilten Systemen alles gleichzeitig auf 100% zu haben. Die Organisation muss wählen.

Woran du das Muster sicher erkennst

Hat das stark wachsende Plattform-Team einen klaren Schwellenwert (z.B. "Maximal 5 Onboardings pro Monat"), ab dem sie Anfragen einfach hart ablehnen, um ihre Service-Qualität zu bewahren?

Quellen

The Systems Thinker: The Attractiveness Principle

Daniel Kim — Systems Archetypes at a Glance

Wikipedia: System Archetypes