Tech-Ego vs. Geschäftsrealität

In meinem LinkedIn-Beitrag - Tech-Ego vs. Business Reality - wurde ein Muster beschrieben, das sich in vielen IT-Projekten wiederholt: Nicht schlechter Code sabotiert vielversprechende Projekte, sondern Entwickler-Ego und die Verliebtheit ins technische Detail. Genau dieses Muster zeigt sich auch bei Modernisierungsentscheidungen in gewachsenen Unternehmenssystemen - nur mit höherem Einsatz, weil dort echter Geschäftsbetrieb dranhängt.

Bleeding Edge, aber teuer

Neue, glänzende Frameworks fühlen sich nach Fortschritt an - kosten aber oft mehr, als sie einbringen. Stabile, "langweilige" Technologie schlägt in der Praxis regelmäßig die brandneue Lösung. Eine überkomplexe Architektur, die niemand im Unternehmen mehr vollständig durchschaut, ist am Ende teurer als eine einfache Lösung, die tatsächlich zum Bedarf passt - selbst wenn sie auf einer Konferenzbühne weniger herzeigbar wäre.

Dieselbe Masche, neu verpackt: KI-generierter Code als Statussymbol

Generierter Code

Das Muster wiederholt sich gerade in neuer Form: Schnell generierter Code, der beeindruckend wirkt, weil er in Minuten statt Tagen entsteht - aber genauso selten hinterfragt wird wie das brandneue Framework von eben. Die eigentliche Frage bleibt dieselbe: Löst der generierte Vorschlag das tatsächliche Geschäftsproblem, oder wurde er vor allem übernommen, weil er schnell und eindrucksvoll wirkte? Geschwindigkeit bei der Entstehung ersetzt nicht die Prüfung, ob eine Lösung wirklich zum Bedarf passt - und ob das Team sie in zwei Jahren noch warten kann.

Generierte Dokumentation

Dasselbe gilt für KI-generierte Dokumentation: Dutzende Confluence-Seiten, in Minuten erzeugt, wirken auf den ersten Blick nach gründlicher Arbeit - ob sie tatsächlich korrekt, aktuell und für das Team brauchbar sind, ist eine andere Frage, die die reine Seitenzahl nicht beantwortet.

Wenn die lautesten Stimmen gewinnen

In vielen Architektur-Diskussionen setzen sich die lautesten Stimmen durch, während sich leisere Teammitglieder zurückziehen. Vorgeschlagen wird dann nicht zwangsläufig die Lösung, die dem Geschäft am meisten nützt, sondern die, die am meisten herzeigbar ist - für das nächste Bewerbungsgespräch oder das LinkedIn-Profil. Für ein Unternehmen, das ein bestehendes Software-System langfristig verantworten muss, ist das eine teure Verwechslung von Zielen.

Der Praxistest für Entscheider

• Löst der Vorschlag ein echtes Geschäftsproblem - oder vor allem das Profilbedürfnis des Entwicklerteams?
• Zahlt sich der Mehraufwand in messbaren Effekten aus: Time-to-Market, Wartungskosten, Ausfallsicherheit?
• Kann das eigene Team die Lösung in zwei Jahren noch warten, wenn die Person, die sie gebaut hat, nicht mehr da ist?

Drei einfache Fragen, die die meisten Über-Engineering-Vorschläge schon im Ansatz entlarven - und die sich auch stellen lassen, ohne selbst tief in der Technik zu stecken.

Warum das zur eigenen Arbeitsweise passt

Genau dieser Gedanke steckt auch im eigenen Ansatz: verstehen, bevor sich etwas ändert, den Bereich mit dem größten Hebel isolieren, und schrittweise statt big-bang vorgehen. Eine technisch beeindruckende Lösung, die am eigentlichen Bedarf vorbeigeht, ist kein Fortschritt - sie ist ein neues Risiko, das sich nur anders anfühlt als das alte.