archetypes

Attractiveness Principle

Ein aufstrebendes Produkt (oder Team) zieht so viel Nachfrage an, bis die Qualität kollabiert und die Attraktivitaet beeinträchtigt wird.

technologyorganization·4 min Lesezeit

Warum relevant?

Ein Archetyp hilft dir, wiederkehrende Dynamiken hinter lokalen Symptomen zu erkennen.

Nächster Schritt

Gehe als naechstes in eine Diagnosemethode, um die vermutete Struktur mit Beobachtungen zu pruefen.

~4 Min. Lesezeit

Beschreibung

Das Attractiveness Principle (Attraktivitätsprinzip) ist eine Variation des "Limits to Growth" Archetyps. Es besagt, dass jedes wachsende, sehr erfolgreiche Konstrukt irgendwann auf klare 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 sehr schnell, billig und stark 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 deutlichen Folgen.

Feedback Loops

Die Struktur ist ein wachstumsfördernder Reinforcing Loop (gutes Produkt -> mehr Nutzer -> mehr Umsatz -> besseres Produkt). Dieser treibt das System gegen mehrere parallele Balancing Loops, etwa Serverkapazität, Supportfähigkeit oder Entwicklerkognition. Je stärker das Wachstum wird, desto sichtbarer werden diese Kapazitätsgrenzen und desto stärker bremsen sie die weitere Entwicklung.

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 stark 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 stark 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 deutlich. Die Entwickler sind plötzlich außergewöhnlich wütend auf das einstige Wunder-Team. Die ungesteuerte Nachfrage hat das Angebot beeinträchtigt.

Diagnosefragen

1.Haben wir intern eine gut angenommene, aber nicht skalierbare "Paved Road" gebaut, dass das verantwortliche Team unter der Last der Adoption gerade überlastet ist?

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 deutlich 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 grundlegende Wahl, worin man bewusst "schlecht" sein wird (Trade-off). Man muss gezielt Wachstumsbremsen einbauen (z.B. Wartelisten für das Produkt, klare 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 konsequent 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 strukturell unwahrscheinlicher, 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 klar ablehnen, um ihre Service-Qualität zu bewahren?