Die Ökonomie von Software-Teams: Warum die meisten Engineering-Organisationen finanziell „blind“ sind

• Die meisten Engineering-Organisationen werden betrieben, ohne Kosten und Wertschöpfung auf Teamebene quantitativ zu erfassen, was zu finanzieller Ineffizienz führt
• Die jährlichen Kosten eines 8-köpfigen Teams liegen bei rund 1,04 Mio. € (87.000 € pro Monat, 4.000 € pro Tag), sodass jede Entscheidung – von Feature-Entwicklung bis zu verzögerten Verbesserungen – klare finanzielle Auswirkungen hat
• Sowohl interne Plattformteams als auch kundenorientierte Produktteams können Break-even und den Maßstab von 3- bis 5-facher Wertschöpfung berechnen, doch nur wenige Organisationen verfolgen das tatsächlich
• Die Niedrigzins- und wachstumsorientierte Kultur der vergangenen 20 Jahre hat die finanzielle Disziplin geschwächt und große Organisationen sowie komplexe Codebasen von Vermögenswerten in Verbindlichkeiten verwandelt
• Mit dem Aufkommen von LLMs werden diese strukturellen Ineffizienzen sichtbar, und Organisationen, die Kosten, Wertschöpfung und Profitabilität pro Team quantitativ messen, werden sich langfristige Wettbewerbsvorteile sichern

---

Die Ökonomie von Software-Teams: Warum die meisten Engineering-Organisationen finanziell „blind“ sind

• Eine numerische Analyse der Kostenstruktur der Softwareentwicklung und der wirtschaftlichen Tragfähigkeit auf Teamebene zeigt, dass die meisten Organisationen arbeiten, ohne diese Daten überhaupt wahrzunehmen
• Bei einem Team mit 8 Personen fallen pro Jahr rund 1,04 Mio. € (87.000 € pro Monat) an, was etwa 4.000 € pro Tag entspricht
• Sowohl interne Plattformteams als auch kundenorientierte Produktteams können berechnen, wie viel Wertschöpfung nötig ist, um den Break-even zu überschreiten, doch kaum eine Organisation verfolgt dies tatsächlich
• Das Niedrigzinsumfeld und die wachstumsorientierte Kultur der letzten 20 Jahre haben die finanzielle Disziplin geschwächt und große Engineering-Organisationen sowie komplexe Codebasen fälschlich wie „Assets“ erscheinen lassen
• Mit dem Aufkommen von LLM (Large Language Models) werden diese strukturellen Ineffizienzen sichtbar, und Organisationen, die Kosten und Wertschöpfung jedes Teams klar messen, verschaffen sich einen Wettbewerbsvorteil

Tatsächliche Kostenstruktur eines Teams

• In Westeuropa liegen die jährlichen Gesamtkosten pro Softwareentwickler bei 120.000 bis 150.000 €, im Durchschnitt bei 130.000 €
  • Einschließlich Gehalt, Sozialabgaben, Altersvorsorge, Ausstattung, Verwaltungskosten und Bürofläche
• Die gesamten jährlichen Kosten eines 8-köpfigen Teams betragen 1.040.000 €, monatlich 86.667 €, täglich 4.000 €
• Selbst die meisten Engineers und Manager kennen diese Zahlen nicht, und Kostenbewusstsein fließt nicht in Priorisierungsentscheidungen ein
• Jede Entscheidung – Feature-Entwicklung, verzögerte Verbesserungen, Neuaufbau einer Plattform – bringt eindeutige finanzielle Kosten mit sich
  • Beispiel: Drei Wochen Entwicklung eines Features für 2 % der Nutzer sind eine Entscheidung im Wert von rund 60.000 €

Break-even-Berechnung für interne Plattformteams

• Angenommen, ein Plattformteam mit 8 Personen unterstützt 100 Engineers
  • Monatliche Kosten: 87.000 €; um diese auszugleichen, muss entsprechend viel Wert geschaffen werden
• Die monatlichen Kosten pro Engineer liegen bei 10.800 € (65 € pro Stunde)
  • Bei 100 Personen wird der Break-even erreicht, wenn monatlich 1.340 Stunden eingespart werden (3 Stunden pro Woche und Person)
• Über reine Zeiteinsparung hinaus ist auch ein direkter Umsatzschutz durch weniger Ausfälle möglich
• Dennoch messen die meisten Teams diese Zahlen nicht und beziehen sie nicht in Entscheidungen ein
• Ein realistischer Maßstab für finanzielle Solidität ist eine 3- bis 5-fache Wertschöpfung (260.000 bis 430.000 € pro Monat)
  • Wartungs- und Ersatzkosten des Systems sowie Fehlerraten von 50 bis 70 % müssen berücksichtigt werden
  • Es geht nicht um bloßen „Break-even“, sondern um nachhaltige Profitabilität

Dieselbe Logik für kundenorientierte Produktteams

• Auch ein kundenorientiertes 8-köpfiges Team hat monatliche Kosten von 87.000 €
  • Wenn der Monatsumsatz pro Nutzer 50 € beträgt, liegt der Break-even bei einem Gegenwert von 1.740 Nutzern, bei einem 3- bis 5-fachen Maßstab sind 5.000 bis 8.700 Nutzer an Wertschöpfung nötig
• Die Verbesserung der Abwanderungsrate (Churn) ist der direkteste Hebel
  • Beispiel: Bei 50.000 Nutzern und 2 % monatlicher Abwanderung (1.000 Nutzer, 50.000 € Verlust) deckt die Beseitigung der Ursache bereits einen Großteil des Break-even ab
• Auch die Verbesserung der Aktivierungsrate (Activation) ist wichtig
  • Von 10.000 neuen Nutzern pro Monat werden nur 30 % aktiviert → eine Verbesserung um 5 Prozentpunkte ergibt 500 zusätzliche Konversionen und 25.000 € zusätzlichen Umsatz
• Eine höhere Konversionsrate (Conversion) hat denselben Effekt
  • Bei 20.000 Testnutzern führt eine Steigerung von 4 % auf 4,5 % zu 100 zusätzlichen zahlenden Nutzern und 5.000 € mehr Umsatz
• Kleine Verbesserungen über mehrere Kennzahlen hinweg können sich zu großen finanziellen Effekten aufsummieren, doch die meisten Teams messen die Verbindung zwischen diesen Kennzahlen und finanziellen Ergebnissen nicht

Warum wird finanziell nicht gemessen?

• Viele Teams verfolgen nur Velocity, Ticket-Anzahl, Feature-Anzahl, NPS, CSAT und ähnliche Aktivitäts- oder Stimmungsmetriken
  • Diese sind kein Ersatz für Finanzkennzahlen, sondern gehören zu einer völlig anderen Kategorie
• Selbst wenn Aktivitätsmetriken besser werden, kann sich die finanzielle Leistung verschlechtern
  • Mehr Features → möglicherweise die falschen Features
  • Mehr Engagement → vielleicht weniger Nutzer, die tatsächlich zum Umsatz beitragen
• Solche Kennzahlen werden gewählt, weil sie leicht messbar, berichtbar und als Erfolg darstellbar sind
  • Finanzkennzahlen können unbequeme Wahrheiten offenlegen
• Die meisten Organisationen bauen bewusst keine Kultur transparenter finanzieller Messung auf

Der Hintergrund der vergangenen 20 Jahre

• 2002–2011: Die Zinsen waren niedrig, aber Risikovermeidung der Investoren hielt die finanzielle Disziplin aufrecht
• 2011–2022: Nullzinsen, wiederkehrende Risikobereitschaft und die SaaS-Wachstumslogik kamen zusammen
  • Über 11 Jahre hinweg wurden Unternehmen Wachstumsraten zuliebe hohe Personalaufstockungen, geringe Effizienz und falsche Prioritäten verziehen
• Die in dieser Zeit geprägte Führungsgeneration ist in einem Umfeld aufgewachsen, in dem keine finanziellen Ergebnisse eingefordert wurden
  • Deshalb passt sich das Verhalten auch nach 2022 trotz steigender Kapitalkosten nicht automatisch an

Die als „Asset“ missverstandenen Verbindlichkeiten von Engineering-Organisationen

• Große Codebasen und Engineering-Organisationen wurden traditionell als Asset betrachtet
  • Angesammelte Geschäftslogik, technische Grundlage, organisatorische Fähigkeiten usw.
• Tatsächlich handelt es sich um eine Struktur aus Verbindlichkeiten, in der sich Wartungsaufwand, Koordinationskosten und verzögerte Entscheidungen aufstauen
  • Mehr Komplexität senkt die Produktivität, erhöht die Kosten und lässt den Umsatz stagnieren
• Früher hat das Niedrigzinsumfeld diese Verbindlichkeiten verdeckt

• Die Realität, die LLMs offengelegt haben

  • Der Entwickler Nathan Cavaglione nutzte einen LLM-Agenten, um 95 % der Kernfunktionen von Slack in nur 14 Tagen nachzubauen
  • Slack wurde über mehr als 10 Jahre von Tausenden Engineers entwickelt, bei Investitionen in Milliardenhöhe
  • Nathan stellte in kurzer Zeit ein ähnliches Produkt fertig – ohne organisatorische Komplexität, bestehende Architektur oder Koordinationskosten
  • Das zeigt, dass die Annahme, Größe, Komplexität und angesammelter Code großer Organisationen seien ein Wettbewerbsvorteil, nicht mehr gilt
  • Probleme bei der Wartbarkeit von LLM-generiertem Code bestehen zwar, doch in einer Agent-zu-Agent-Umgebung ist er gegenüber menschlicher Wartung bei Kosten und Geschwindigkeit im Vorteil

Voraussetzungen für Organisationen, die künftig voraus sein werden

• Der Kern der Wettbewerbsfähigkeit ist nicht die Technologie, sondern die Analysefähigkeit
  • Organisationen, die die Kosten-, Wert- und Profitabilitätsschwellen jedes Teams klar kennen, sind strukturell im Vorteil
• Solche Organisationen können Folgendes leisten
  • Build-vs-Buy-Entscheidungen auf Basis realer Wirtschaftlichkeit treffen
  • Teams unterhalb der Rentabilitätsschwelle identifizieren
  • Wertverluste durch Verzögerungen quantifizieren und Prioritäten entsprechend anpassen
• Den meisten Organisationen fehlen derzeit Messinfrastruktur, Datenflüsse und Gewohnheiten
  • Der Aufbau ist unangenehm, aber unverzichtbar
  • Dabei kann sich herausstellen, dass Teams ein ganzes Quartal für Arbeit ohne finanzielle Anbindung verbraucht haben
• Früher wurden solche Zustände durch Niedrigzinsen und wachstumsorientierte Logik toleriert, doch in einem Umfeld, in dem AI die Entwicklungskosten drastisch senkt und Investoren finanzielle Ergebnisse einfordern, ist das nicht mehr tragfähig
• Organisationen, die sich angewöhnen, die Wirtschaftlichkeit auf Teamebene klar zu hinterfragen und zu messen, bauen mit der Zeit einen Wettbewerbsvorteil mit Zinseszinseffekt auf

[GN⁺]

Hacker-News-Kommentare

• Der Kern des Artikels ist, dass nicht das Programmieren selbst schwierig ist, sondern herauszufinden, was überhaupt programmiert werden soll, der wirklich harte Teil ist
  In der Praxis besteht ein Großteil der Arbeit darin, den Problemraum zu erkunden, indem man erst etwas Falsches baut und es dann mehrfach ersetzt
  Programmieren ist oft nicht das Endprodukt, sondern eher ein Mittel, um die Problemdefinition zu schärfen

  • Ich glaube nicht, dass das immer stimmt. Bei manchen Projekten ist klar, was gebaut werden muss, aber die technische Schwierigkeit selbst ist extrem hoch
    Wenn es nur darum geht, Frameworks zusammenzusetzen, mag es einfach sein, aber in Umgebungen mit komplexen Systemen ist Programmieren an sich wirklich schwer
  • Viel Software schafft in der Praxis keinen Wert, sondern vernichtet ihn eher
    Ich habe oft gesehen, wie aus einer simplen Anfrage ein riesiges System wurde. Andererseits kann man wie Google durch kluge Investitionen in Infrastruktur auch einen Wettbewerbsvorteil gewinnen
  • Dieses Konzept gibt es auch außerhalb des Engineerings. Wie das Internet-Sprichwort sagt, dass man schneller die richtige Antwort bekommt, wenn man eine falsche postet, können falsche Versuche manchmal zu besseren Einsichten führen
    Solche Ansätze wirken jedoch oft unproduktiv oder führen leicht dazu, dass man als „jemand, der Falsches sagt“ missverstanden wird
  • Auch wenn Programmieren vielleicht nicht das Allerschwierigste ist, sollte man nicht vergessen, dass es immer noch keine leichte Arbeit ist
  • Für Berufseinsteiger mag das zutreffen, aber erfahrene Engineers wissen bereits, wie man effizient baut
    Viele Entwickler halten ihr Projekt für besonders, obwohl es in Wirklichkeit oft reicht, bewährte Designs zu kopieren

• Wie im Artikel gesagt, ist die Sorge berechtigt, dass schnell erzeugter Code schwer zu pflegen ist, aber das sei weniger wichtig, solange keine Menschen ihn warten müssen
  Ich finde jedoch, dass sich diese Logik auch auf einen „Agile-Coach-LLM“ anwenden lässt. Ein LLM kann die meisten Einsichten bereits viel günstiger liefern
  Am Ende können sich Menschen vielleicht am Pool entspannen

  • Wenn AGI meine Arbeit ersetzt, werde ich immer noch Validierung und Verantwortung übernehmen. Wenn die Management-Ebene verschwindet, könnte es sogar friedlicher werden
  • In letzter Zeit wirken die meisten Texte über LLMs so, als wären sie von LLMs geschrieben. Sogar die verkauften Schulungsunterlagen scheinen sich durch eine einzige Prompt-Zeile ersetzen zu lassen
  • Wir leben inzwischen in einer Zeit, in der Lernen fast nichts kostet und Dozenten nur noch die Rolle haben, Lernen zu erzwingen

• Ich stimme der Behauptung nicht zu, dass man selbst eine chaotische Codebasis durch den Einsatz mehrerer Agenten lösen könne
  In Wirklichkeit gibt es viel Code, der oberflächlich perfekt aussieht, intern aber strukturell falsch ist, wie ein Gebäude aus Schaumstoff
  Solcher Code lässt sich mit der Zeit nicht mehr erweitern und verhärtet am Ende wie Ziegelstein

  • Mit ausreichend Architekturdesign und Guardrails können auch Agenten gut funktionieren. Andernfalls ist sorgfältige menschliche Aufsicht unverzichtbar
  • Wenn Agenten zu viel „cleveren Code“ schreiben, stellt sich die Frage: Wer soll das Debugging übernehmen?
  • Die Formulierung „Kunst trägt die Last“ fand ich wirklich eindrucksvoll
  • Wenn das Management glaubt, AI werde alles lösen, ist das eine gefährliche Illusion. Reine Computing Power reicht dafür nicht aus
  • Wenn solche Probleme auftreten, fehlt dann nicht grundsätzlich etwas im Testsystem selbst?

• Ich habe selbst erlebt, dass zwei von AI erstellte Projekte komplett gescheitert sind
  Selbst mit mehr Agenten gab es keinen Fortschritt, und die Ergebnisse gingen meist in die falsche Richtung

  • Ich hatte eine ähnliche Erfahrung. Ich habe mehr als 40.000 Zeilen Code gelöscht. Von AI erzeugter Code verwendet fast immer die falschen Abstraktionen
  • Das wirkt wie eine Art Mythical Machine Month. Selbst wenn man statt Menschen mehr Maschinen einsetzt, steigt die Produktivität nicht
  • Im Umgang mit AI sieht man oft Muster, die an menschliche Aufmerksamkeitsfehler erinnern. Am Ende geht es um Kontext und Fokus
  • Die Verantwortung für den Code liegt weiterhin beim Menschen. Nur weil AI ihn erzeugt, verschwindet diese Verantwortung nicht
  • AI gerät bei Technical Debt nicht anders in Schwierigkeiten als Menschen. Allerdings hat sie Potenzial als Werkzeug, das Rewrites erleichtert

• Ich stimme der Aussage zu, dass Softwareentwicklung kapitalintensiv ist, aber der Kontext ist je nach Branche unterschiedlich
  Bei Energieversorgern oder Herstellern sind die Kosten für den Erhalt physischer Infrastruktur viel höher als IT-Kosten
  Allerdings fragen sich inzwischen mehr Unternehmen, ob es wirtschaftlicher ist, LLM-Entwickler einzustellen, weil es zu viele SaaS-Verträge gibt

  • Selbst bei öffentlichen Einrichtungen wie Verkehrsbehörden entsteht das Bewusstsein, dass die SaaS-Ausgaben überzogen sind. Sobald das Management das erkennt, werden viele unnötige Verträge wohl bereinigt
  • SaaS wird aber nicht vollständig verschwinden. Man braucht Strukturen, die Zuständigkeit und rechtliche Risiken tragen können
  • Der Bau einer Pharmafabrik kostet allein mehrere Milliarden Dollar. In solchen Industrien sind Softwarekosten vernachlässigbar gering

• Ich fand den Artikel interessant, verlor aber beim Beispiel eines Slack-Klons das Vertrauen
  Die Aussage zeigt keinerlei Verständnis für den tatsächlichen Umfang, die Stabilität und den Funktionsreichtum von Slack

  • Slack ist kein Produkt, das man einfach kopieren kann. Es ist das Ergebnis unzähliger Iterationen und eines ausgeprägten Produktgespürs
  • Schon bei der Aussage „95 % Klon“ war das Vertrauen weg
  • Auch Studierende bauen Twitter-Klone, aber der echte Wettbewerber ist nicht der Code, sondern Markt und Ökosystem
  • Ich könnte in zwei Wochen auch einen Slack-Klon bauen, aber schon eine einzige Legal-Hold-Funktion sauber umzusetzen würde Monate dauern
    Bei Enterprise-Produkten sind Hunderte solcher Detailfunktionen Pflicht. Eine simple Kopie ist keine Konkurrenz
  • Slack zu bauen war nicht bloß Coding, sondern ein Prozess des Entdeckens, was überhaupt gebaut werden muss

• Ein Text, der nur mit Zahlen und Diagrammen um sich wirft, wirkt wie der Text einer Person, die eine Debatte gewinnen will
  Wie Rory Sutherland sagt, sind „Finance People“ von Gewissheit und Vorhersagbarkeit besessen
  Aber die Welt ist nicht so einfach

  • Präzise Berechnungen helfen als Nebeneffekt dabei, Probleme zu zerlegen. Aber den Markt erobert am Ende tiefes Problemverständnis und Vision
  • Seine Mathematik passt nicht zur Realität. Produkterfolg ist unvorhersehbar, und Investitionen sind letztlich ein Glücksspiel
  • Die Wahrheit liegt wie so oft irgendwo dazwischen. Man braucht ein Gleichgewicht aus Zahlen und Gespür
  • Teams mit den richtigen Messwerkzeugen und Kennzahlen erzielen langfristig bessere Ergebnisse
  • Trotzdem muss man zumindest eine Hypothese darüber aufstellen, wie sich ein Feature auf den Umsatz auswirkt, wenn man ein nachhaltiges Geschäft aufbauen will

• Mehr als die Details des Artikels spricht mich die Engineering-Kultur an, die nicht über Wert im Verhältnis zu Kosten nachdenkt
  In Meetings oder bei Incident-Response werden oft überzogene Maßnahmen ergriffen, ohne Kosten und Wirkung gegeneinander abzuwägen
  Bei Technical Debt ist es genauso: Wenn man die Kosten nicht kennt, kann man keine verantwortungsvollen Entscheidungen treffen

  • Noch größere Verschwendung als Meetings sind die falschen Projekte oder Features. Sie ziehen Wartung und Komplexität endlos nach sich

• Die einfache Rechnung, dass Plattform-Teams ihren Wert über Zeitersparnis beweisen müssen, ist falsch
  Plattform-Teams sparen nicht nur Zeit, sondern reduzieren Geschäftsrisiken und sichern zentrale Qualitätsmerkmale

  • Der Daseinszweck von Plattform-Teams besteht darin, doppelte Arbeit zu zentralisieren und die Trennung von Sicherheit und Betrieb aufrechtzuerhalten
    Das ist nicht bloß ökonomische Logik, sondern eine Frage unverzichtbarer organisatorischer Infrastruktur

• Letztlich ist entscheidend, ob ein Team das Produkt wirklich am Herzen liegt
  Nur Teams, denen das Produkt wichtiger ist als kurzfristige Karriereschritte, erzielen echte Ergebnisse, die über Kennzahlen und Managementmethoden hinausgehen
  Aber manche Projekte sind von Anfang an so angelegt, dass man gar keine echte Bindung dazu entwickeln kann, und dann sind den Produktivitätsgrenzen klare Grenzen gesetzt