# Die Entscheidung zu treffen reicht nicht

*Daniel Schmeiß · 2026-10-11*

Ich schaue mir einen Service an und stolpere über Python-Code. Neu geschrieben, vor ein paar Monaten.

Vor über zwei Jahren haben wir entschieden, im Backend nur noch TypeScript und Java einzusetzen. Kein Python mehr. Wenn ich nachfrage, höre ich fast immer eine dieser Antworten:

> „Das ist hier ein Sonderfall.“
> „Wir hatten keine Zeit, das umzubauen.“
> „Es läuft doch.“

Jede davon ist aus Sicht des Teams nachvollziehbar. So entstehen solche Ausnahmen.

## An der Entscheidung lag es nicht

Die Entscheidung ist klar. Wir haben sie in einem öffentlichen Dokument erarbeitet, mit Situation, Zielen, Rahmenbedingungen und Optionen. Alle Betroffenen konnten von Anfang an mitlesen und mitreden. Die Kolleginnen und Kollegen kennen sie.

Sie halten sie nur nicht für dringend. Für ihr Team funktioniert der Python-Service ja. Der Umbau kostet Zeit, die sie lieber in Features stecken.

**Der Aufwand entsteht sofort im Team, der Nutzen später in der ganzen Organisation.** Code wechselt das Team. Menschen wechseln die Firma. Irgendwann muss jemand den Service betreuen, der kein Python kann.

**„People move, tech stays.“**

Dafür haben wir den Standard beschlossen.

## Mein Teil

Rückblickend habe ich die Entscheidung als erledigt behandelt, sobald sie dokumentiert war. Ich hätte mehr hinterher sein müssen.

Vor allem hätte ich die Engineers und Manager stärker ermutigen sollen, die Entscheidung in ihren Teams selbst zu vertreten. Kommt sie dort nur als Vorgabe von außen an, fehlt jemand, der bei der nächsten Ausnahme fragt, ob sie wirklich notwendig ist.

Zwei Jahre später stehe ich deshalb vor neuem Python-Code und frage nach.

## Was ich heute anders machen würde

Bei einer größeren Entscheidung würde ich von Anfang an sichtbar machen, wie weit wir mit der Umsetzung sind.

Keine große Reporting-Struktur. Eine einfache monatliche Übersicht reicht, für alle einsehbar: Wo entsprechen wir dem Ziel, wo noch nicht, und welche Ausnahmen gibt es?

Damit sehen alle denselben Stand. Ausnahmen werden sichtbar, bevor sie sich festsetzen. Und wir können konkret besprechen, warum ein Team noch nicht umgebaut hat und was dafür fehlt.

Vor der nächsten größeren Entscheidung würde ich mir vier Fragen stellen:

- Woran erkennen wir, dass die Entscheidung umgesetzt ist?
- Wer sieht regelmäßig, wo wir stehen?
- Wer vertritt die Entscheidung in den Teams, wenn ich nicht im Raum bin?
- Wie entscheiden wir über Ausnahmen, bevor sie stillschweigend zur Regel werden?

## Dranbleiben

Die Entscheidung von damals halte ich weiterhin für richtig. Mein Fehler war, zu wenig auf die Umsetzung danach zu schauen.

Eine Entscheidung zu treffen und zu dokumentieren ist der kürzere Teil. Danach muss über Monate sichtbar bleiben, ob sich tatsächlich etwas verändert.

Wenn du selbst vor so einer Entscheidung stehst, etwa in der [Jahresplanung](https://www.reflacto.com/de/moments/annual-planning), plane den längeren Teil gleich mit ein. Und bau zu Beginn auf, wie ihr messt, ob ihr das Ziel erreicht.

---

Originalseite: https://www.reflacto.com/de/blog/die-entscheidung-zu-treffen-reicht-nicht