Engineering Manifesto

Unsere Position. Agents haben das Betriebsmodell von Software Engineering nicht verändert. Sie haben offengelegt, ob ein Team überhaupt eines hatte (AI-native teams (öffnet in einem neuen Tab)).

Die fünf Werte stammen aus OTTOs öffentlichem Tech Manifest (öffnet in einem neuen Tab) (Apache-2.0), geschrieben für Systeme unter echtem Business-Druck. Werte beschreiben, was ein Team wichtig findet und worauf es Gewicht legt. Sie leiten die tägliche Arbeit und die Entscheidungen.

Die elf Architekturprinzipien übersetzen diese Werte in konkrete Entscheidungen.

Warum folgt Tech dem Business?

Engineering-Arbeit hat einen einzigen Zweck: Business Value zu schaffen. Jede technische Entscheidung muss das Business unterstützen. Je früher, desto besser.

Business-Anforderungen verschieben sich, Roadmaps ändern sich. Wir unterstützen das, statt uns dagegen zu wehren. Business-Ideen zu entwickeln ist Aufgabe des ganzen Teams, nicht allein der produktnahen Teammitglieder. Teams bauen Produkte für Partner:innen und Kund:innen, keine bloßen Software-Artefakte.

Business Value entsteht erst, wenn Software in Produktion geht. Dokumente und Konzepte haben für sich genommen keinen Wert.

Der Nutzen für das Unternehmen zählt für uns mehr als der Nutzen für unser Team oder für uns selbst.

Warum move fast und fail fast?

Wir setzen auf schnelle Iteration in kurzen Zyklen aus Build, Measure und Learn. Fail fast empfehlen wir ausdrücklich, oft umgesetzt mit vollautomatisierten Pipelines. So zeigen sich Fehler so früh wie möglich im Entwicklungsprozess.

Teams brauchen die nötigen Leute und Befugnisse, um Features und Produkte mit möglichst wenigen Abhängigkeiten zu anderen Teams zu bauen. Wir berücksichtigen, dass Systemgrenzen die Kommunikationsstrukturen spiegeln. Domänen schneiden wir so, dass lose Kopplung und mehr Teamautonomie möglich werden.

Unklare Business-Anforderungen werden klarer und greifbar, sobald Teams potenziell auslieferbare Softwareprodukte bauen und deployen. Ein laufendes System mit minimalen Funktionen ist wertvoller als jede Diskussion über Konzepte.

Wir schätzen Refactoring und folgen dem Pareto-Prinzip, um Business-Anforderungen zu erfüllen. Iteratives Design und Feedback-Schleifen mit Partner:innen und Kund:innen führen tendenziell zu kundenorientierten Lösungen.

Software ist darauf ausgelegt, auszufallen. Ausfälle lassen sich nicht vollständig verhindern. Wir konzentrieren uns auf die Mean Time to Recovery, statt die Mean Time between Failures zu optimieren.

Wie halten Teams technische Hürden niedrig?

Wir streben unabhängige Teams an, aber kein Team steht allein. Wir helfen einander und bauen technische Hürden ab. Den Wissensaustausch zwischen Teams bauen wir aus. Wo es nützt, schätzen wir eine teamübergreifende Standardisierung von Technologien und Prozessen. Offene Standards ziehen wir proprietären vor.

Wie viel Sorgfalt brauchen nichtfunktionale Aspekte?

Die nichtfunktionalen Aspekte unserer Software bekommen besondere Aufmerksamkeit. Wie viel Aufwand in Resilienz fließt, entscheiden wir nach Kritikalität und Reife eines Produkts.

Erkennen wir Probleme, reagieren wir mit Dringlichkeit. Security Best Practices wenden wir auf alle Anwendungen an. Performance messen wir auch unter hoher Last und sichern angemessene Antwortzeiten.

Das Infrastruktur-Setup ist weitgehend automatisiert. So können wir im Disaster-Recovery-Fall die gesamte Umgebung neu aufbauen. Qualität ist eine nicht verhandelbare Dimension, und wir erreichen sie über die Testpyramide.

Was verlangt Full Ownership von einem Team?

Teams verantworten Support, Monitoring, Alerting, Betrieb und Stilllegung von allem, was sie bauen und pflegen, Qualitätsaspekte eingeschlossen. You build it, you run it.

Zuständigkeiten und Ownership müssen immer klar und öffentlich sein. Alles, was in Produktion läuft oder von mehreren Teams geteilt wird, braucht eine klare Ownership.

Wir streben abgestimmte, autonome und cross-funktionale Teams an. Ein Team soll seinen Auftrag so autonom wie möglich erfüllen. Wo Synergien nützen könnten, stimmt es Konzepte und technische Lösungen trotzdem mit anderen Teams ab.

Teams verantworten auch ihre Kosten und arbeiten daran, sie zu optimieren.

Verwandte Seiten

• Architekturprinzipien: die elf Prinzipien, die diese Werte operationalisieren.
• Engineering-Philosophie: die Begründung, auf der sie stehen.
• Die drei Wege: Flow, Feedback und Lernen hinter “move fast, fail fast”.
• Menschliche Verantwortung: was Full Ownership bedeutet, wenn ein Agent den Code geschrieben hat.
• Dynamisch-robuste Organisation: die Teamautonomie und die Schnittstellen, die diese Werte voraussetzen.

Quellen

Posts

• AI-native teams (öffnet in einem neuen Tab) - LinkedIn-Post mit der These, dass Agents das Betriebsmodell von Software Engineering nicht verändert haben. Sie haben offengelegt, ob ein Team eines hatte.

Tools und Repositories

• Tech Manifest (öffnet in einem neuen Tab) - das Manifest der Engineering-Werte von otto-de, Quelle der fünf Werte dieser Seite, geschrieben für Systeme unter Business-Druck. Apache-2.0, archiviertes Repository.