Sie brauchten nie einen Hype, um in Ihre Leute zu investieren

13 Min. Lesezeit

Erlaubnis durch Foliensatz erteilt

Das Muster ist immer das gleiche. Eine Beratungsfirma veröffentlicht einen Bericht. Ein Mitbewerber kündigt etwas an. Ein Vorstandsmitglied besucht eine Konferenz und kehrt alarmiert zurück. Plötzlich taucht ein Budget auf. Plötzlich ist Veränderung dringend. Plötzlich verdienen Menschen Unterstützung.

Niemand hat vor diesem Moment danach gefragt. Nicht, weil es unnötig war. Sondern weil die Organisation jahrelang das Unternehmertum aus ihren eigenen Leuten heraus trainiert hat. Initiative wird bestraft, ignoriert oder stillschweigend von jemand anderem als Erfolg verbucht. Nach genug Wiederholungen hören selbst starke Entwickler auf, etwas vorzuschlagen. Sie bearbeiten das Ticket. Sie gehen nach Hause. Die Kultur will Gehorsam und bekommt ihn — wundert sich dann aber, warum sich ohne externe Intervention nichts verbessert.

Das Vokabular ist meistens schon im Raum. Entwickler haben von TDD gehört. Sie wissen, dass Continuous Integration existiert. Sie wissen, dass Pair Programming ein Ding ist. Sie haben es nur nie praktiziert, weil niemand die Bedingungen geschaffen, die Erwartung gesetzt oder signalisiert hat, dass Eigenverantwortung willkommen ist. Ob das Unternehmen fünftausend Entwickler beschäftigt oder fünf, das Muster ist identisch. Der erfahrene Entwickler, der vielleicht sagen würde “wir sollten X tun”, hat schon lange gelernt, dass das Aussprechen nichts ändert, außer dem eigenen Ruf, schwierig zu sein.

Dann kommt jemand Externes — ein Coach, ein Berater, ein Framework-Evangelist — und innerhalb von Wochen schreiben dieselben Leute Tests, betreiben Pipelines und liefern im Fluss. Das Wissen kam nicht von außen. Die Erlaubnis schon.

Das macht die Abhängigkeit von Hypes so entlarvend. Die Leute waren immer fähig. Die Führung hat nur nie den Raum geschaffen. Dann gibt ein Markenname politische Deckung und alle tun so, als wäre der Bedarf neu.

Der Kreislauf der Hype-Abhängigkeit

Es funktioniert so. Eine Branchenbewegung gewinnt an Fahrt. Anbieter und Beratungen erkennen die Welle. Sie produzieren Zertifizierungen, Reifegradmodelle und Benchmark-Berichte. Diese Berichte erzeugen genug Angst, um Budgetkomitees zu bewegen. Plötzlich kann die Organisation in Dinge wie Mentoring, Werkzeuge, Entwicklererfahrung oder Praktiken der Zusammenarbeit investieren — aber nur unter dem Banner des neuen Frameworks.

In dem Moment, in dem der Hype verblasst, verdampft die Unterstützung. Nichts am zugrunde liegenden Bedarf hat sich geändert. Die Entwickler brauchen immer noch Lernzeit, bessere Werkzeuge, vernünftige Teamgrößen und technische Autorität. Aber die politische Deckung ist weg, also stirbt die Investition.

Das ist kein Zufall. Es offenbart, wie viele Organisationen zu ihrer eigenen technischen Belegschaft stehen. Sie investieren nicht, weil es offensichtlich nötig ist. Sie investieren, weil eine externe Autorität es gesellschaftlich sicher gemacht hat. Das ist ein Versagen der Führung, getarnt als strategische Geduld.

Und zwischen den Hypes sucht die Führung auch nicht aktiv nach Hilfe. Sie öffnen nicht LinkedIn und lesen, was Praktiker über moderne Entwicklung schreiben. Sie besuchen keine Meetups, wo tatsächliche Entwickler darüber sprechen, was funktioniert. Sie recherchieren nicht, wie andere Organisationen ähnliche Probleme gelöst haben. Sie rufen keine erfahrenen Spezialisten an und stellen Fragen. Sie machen keine der Hausaufgaben, die ein verantwortungsvoller Eigentümer machen würde, bevor er eine bedeutende operative Entscheidung trifft.

Was sie stattdessen tun, ist delegieren. Sie weisen HR an, jemanden für X einzustellen. Sie schreiben einen RFP aus. Sie fragen Gartner, was der Magic Quadrant sagt. Sie warten darauf, dass ein Anbieter ihnen etwas präsentiert. Sie besuchen eine Executive-Konferenz und hoffen, dass eine Keynote ihnen sagt, was sie als Nächstes tun sollen. Das Muster ist immer die passive Aufnahme verpackter Antworten anstatt der aktiven Untersuchung der eigenen Situation.

Diese Passivität ist der Grund, warum der Einstellungsfilter seinen Schaden anrichtet. Die Führung versteht nicht, wie gute Arbeit aussieht, also können sie es nicht beschreiben. HR erhält ein vages Briefing voller Schlagworte, baut einen Filter, der Schlagwort-Symmetrie belohnt, und sortiert genau die Leute aus, die hätten helfen können. Der darauf folgende Fachkräftemangel ist in Wirklichkeit ein Filterversagen — aber die Führung sieht das nie, weil sie nie mit genug Verständnis an der Suche teilgenommen hat, um zu bemerken, was fehlt.

Führung bedeutet, die Bedingungen zu verantworten, die gute Arbeit ermöglichen Publishes on July 6, 2026. Come back then. — nicht darauf zu warten, dass eine Beratung erklärt, wie gute Arbeit aussieht.

Die Treiber sind politisch, nicht rational

Die Hype-Abhängigkeit wird nicht durch Unwissenheit allein verursacht. Sie wird durch Organisationspolitik aufrechterhalten.

In den meisten Unternehmen sitzen die Leute, die Software bauen, in einer Schublade namens IT. Dieses Label ist nicht neutral. Es bedeutet Support-Funktion. Es bedeutet Kostenstelle. Es bedeutet, dass die Leute in dieser Schublade nicht die Richtung vorgeben — sie empfangen Tickets. Ihr Urteil wird nicht herangezogen, wenn Strategie gebildet wird. Ihre Einwände werden nicht protokolliert, wenn das Versprechen eines Anbieters der Realität widerspricht. Ihre Warnungen erreichen nicht den Raum, in dem die Budgetentscheidung fällt.

Dieses Arrangement ist politisch. Jemand hat, wahrscheinlich vor Jahrzehnten, entschieden, dass Software eher Infrastruktur als Produkt ist. Dass es Wartung anstatt Kreation ist. Dass die Leute, die das tun, austauschbare Dienstleister sind und keine Spezialisten, deren Wissen prägt, was das Unternehmen überhaupt versuchen kann.

Sobald diese politische Klassifizierung etabliert ist, folgt alles andere. Entwickler bekommen kein Budget ohne Framework, weil ihre Domäne nicht als strategisch anerkannt wird. Sie können sich nicht gegen unrealistische Fristen wehren, weil Support-Funktionen das Business nicht herausfordern dürfen. Sie können schädliche Architektur-Entscheidungen nicht ablehnen, weil Kostenstellen keine Autorität haben. Sie können nur Anweisungen entgegennehmen und beschuldigt werden, wenn das Ergebnis mangelhaft ist.

Der Hype ändert das vorübergehend — nicht, weil er die politische Struktur repariert, sondern weil er die Konversation kurzzeitig auf ein Niveau hebt, auf dem Budgetkomitees zuhören. Dann geht der Hype vorbei. Die politische Klassifizierung greift wieder. Entwickler sind wieder nur die IT.

Der Primadonna-Mythos und was er verbirgt

Es gibt ein Wort, das zuverlässig auftaucht, wenn die obere Führung über Softwareentwickler diskutiert, die widersprechen, Fragen stellen oder sich weigern, so zu tun, als würde ein schlechter Plan funktionieren. Primadonnen. Schwierig. Keine Teamplayer.

Dieses Label leistet nützliche politische Arbeit. Es deutet berechtigte fachliche Einwände in persönliche Defizite um. Der Entwickler, der sagt, diese Frist sei unrealistisch, wird zu jemandem mit einem Einstellungsproblem. Der Architekt, der sagt, dieses Produkt eines Anbieters könne nicht das leisten, was der Vertrieb versprochen hat, wird zu jemandem, mit dem es schwierig ist zu arbeiten. Der erfahrene Spezialist, der sagt, das Team brauche drei Monate fokussiertes Refactoring, bevor ein neues Feature sicher ausgeliefert werden kann, wird zu jemandem, der das Business nicht versteht.

Keiner dieser Einwände ist das Verhalten einer Primadonna. Es ist der normale Output kompetenter Fachleute, die das Material verstehen, mit dem sie arbeiten. Ein Statiker, der sagt, das Fundament könne kein weiteres Stockwerk tragen, ist keine Primadonna. Ein Chirurg, der sagt, der Patient brauche einen anderen Eingriff, ist nicht schwierig. Aber Softwareentwickler, die das gleiche fachliche Urteil fällen, bekommen ein anderes Label — weil die Organisation bereits entschieden hat, dass ihre Domäne eine Support-Funktion ist und Support-Funktionen nicht Nein sagen dürfen.

Die tiefere Ironie ist, dass erfahrene Entwickler oft mehr über die Fachdomäne des Business wissen, als die Entscheider sich eingestehen wollen. Sie sehen, wie die Regeln tatsächlich ausgeführt werden. Sie sehen, wo die Daten der Erzählung widersprechen. Sie sehen, welche Kunden-Workflows tatsächlich passieren versus welche sich der Produktmanager ausgedacht hat. Sie sehen, wo die eigenen Prozesse der Organisation jeden einzelnen Tag zusammenbrechen, weil sie diejenigen sind, deren Code die Ausnahmen behandeln muss.

Dieses Wissen wandert selten nach oben. Nicht, weil Entwickler es nicht kommunizieren könnten. Weil niemand in einer Machtposition fragt. Die politische Struktur sagt: Ihr seid IT. Ihr implementiert. Ihr analysiert, beratet oder hinterfragt nicht.

Fremde können Ihren Durchbruch nicht erschaffen

Es gibt eine wiederkehrende Fantasie in Organisationen, die mit der Auslieferung von Software kämpfen. Sie geht so: Wir stellen ein neues Team aus externen Spezialisten zusammen, geben ihnen die Anforderungen, und sie werden etwas Außergewöhnliches bauen.

So funktioniert es fast nie.

Ein Produkt zu bauen, das von Bedeutung ist, erfordert akkumulierten Kontext. Es erfordert das Verständnis dessen, was zuvor versucht wurde. Es erfordert zu wissen, wo die politischen Landminen liegen, welche Kundensegmente tatsächlich zahlen, welche technischen Entscheidungen unter Druck getroffen wurden und überdacht werden sollten, und welche sorgfältig getroffen wurden und erhalten bleiben sollten.

Eine Gruppe von Fremden hat diesen Kontext nicht. Sie können ihn nicht in einem zweiwöchigen Onboarding entwickeln. Und die Organisation weiß meistens gar nicht, wie sie diesen Kontext übertragen soll, weil er in den Köpfen der Leute lebt, die schon da waren — denselben Leuten, deren Meinungen nie in Strategiegespräche einbezogen wurden.

Das ist es, was die Fantasie besonders teuer macht. Die Leute, die bereits im Unternehmen sind — die als IT abgetanen Entwickler, diejenigen, die die bestehenden Systeme gewartet haben — verfügen oft über mehr operatives Domänenwissen als jeder andere im Gebäude. Sie wissen, welche Geschäftsregeln echt sind und welche nur Folklore. Sie wissen, welche Integrationen tatsächlich funktionieren und welche stillschweigend scheitern. Sie wissen, welche Kundensegmente Randfälle erzeugen, die keine Spezifikation jemals erfasst hat. Aber die Organisation hat sie als Implementierer behandelt, also kam niemand auf die Idee, sie in die Produktstrategie einzubeziehen. Stattdessen stellt die Führung Fremde ein und wundert sich, warum der Durchbruch ausbleibt.

Was man tatsächlich braucht, ist ein Umfeld, in dem fähige Leute, die die Domäne verstehen, nachhaltige, fokussierte Arbeit mit echter Autorität über technische Entscheidungen leisten können. Das hat nichts mit einem Framework zu tun. Es hat alles damit zu tun, Entwickler mit Respekt zu behandeln und ihnen Raum zu geben, um ihr Urteilsvermögen auszuüben.

Die Diplom-Illusion

Es gibt eine hartnäckige Verwechslung zwischen Ausbildung und Fähigkeit in der Softwareentwicklung. Jemand schließt ein Informatikstudium ab und die Organisation geht davon aus, dass er Produkte bauen kann. Das können sie nicht. Noch nicht. Nicht ohne jahrelange betreute Praxis, schmerzhafte Fehlschläge, Produktionsvorfälle, Deployment-Alpträume und das langsame Ansammeln eines Systemverständnisses.

Ein Studium lehrt Theorie. Ein Teil dieser Theorie ist wirklich nützlich. Vieles davon hat wenig mit der täglichen Arbeit zu tun, Produktionssysteme zu bauen, zu betreiben und weiterzuentwickeln, auf die sich tatsächliche Menschen verlassen.

Die Lücke zwischen Abschluss und Kompetenz ist enorm. Und dennoch strukturieren viele Organisationen ihre Einstellungsprozesse so, als wäre der Abschluss das qualifizierende Zeugnis statt der Startlinie. Sie stellen frische Absolventen ein, geben ihnen kein nennenswertes Mentoring, umgeben sie mit anderen Leuten, die ebenfalls keine Produktionserfahrung haben, und tun dann überrascht, wenn die resultierende Software fragil, teuer und chronisch verspätet ist.

Die Leute, die sie betreuen könnten — Entwickler mit fünfzehn, zwanzig, dreißig Jahren Erfahrung im Bau echter Systeme — sind oft nirgends in der Nähe. Nicht, weil sie nicht existieren. Weil der Einstellungsfilter sie aussortiert hat, bevor auch nur ein menschliches Gespräch stattfand.

Der Einstellungsfilter sortiert Meisterschaft aus

Das ist der Teil, der Führungskräfte am meisten alarmieren sollte. Unternehmen beschweren sich über einen Fachkräftemangel, während sie aktiv die stärksten verfügbaren Kandidaten herausfiltern.

Ein Entwickler mit fünfundzwanzig Jahren Erfahrung im Bau von Produktionssystemen über mehrere Branchen, mehrere Technologie-Stacks und mehrere organisatorische Kontexte hinweg sieht nicht wie die saubere Schlagwortübereinstimmung aus, die Ihr Applicant Tracking System (ATS) haben will. Sie haben nicht fünf aufeinanderfolgende Jahre in Ihrem genauen Framework verbracht, weil sie damit beschäftigt waren, härtere Probleme in unterschiedlichen Umgebungen zu lösen. Ihr Lebenslauf zeigt Bewegung, weil Experten gerufen werden, wenn etwas kaputt ist, nicht, wenn alles bequem ist.

Ihr Filter liest das als Instabilität. Der Markt liest es als Erfolgsbilanz.

Personalaufstockung verfehlt dieselben Leute aus demselben strukturellen Grund. Das Beschaffungsmodell belohnt Gleichheit, Schlagwortüberschneidungen und reibungsloses Einfügen. Es bestraft Tiefe, Bandbreite und die Art von Urteilsvermögen, die sich nur durch vielfältige Praxis entwickelt.

Währenddessen stellt die Organisation jemanden ein, der den ATS-Filter passiert, jedes Framework-Häkchen setzt und nicht ein einziges Mal ein System reparieren musste, das er nicht selbst gebaut hat, sich nicht von einem misslungenen Deployment erholen musste oder einem Product Owner sagen musste, dass die Anforderung der Realität widerspricht. Diese Person besteht den Einkauf. Sie besteht nicht in der Produktion.

KI ist nicht das Problem. Sie ist der Verstärker.

Der aktuelle Reflex besteht darin, der KI die Schuld dafür zu geben, dass sie Entwickler überflüssig mache. Diese Erzählung ist bequem für Führungskräfte, die ohnehin wollten, dass die Entwicklung billiger wird. Sie ist auch falsch.

KI macht großartige Entwickler gefährlich — im besten Sinne. Ein Entwickler mit tiefem Systemverständnis, jahrzehntelanger Mustererkennung und echter handwerklicher Meisterschaft kann sich jetzt mit einer Geschwindigkeit bewegen, die früher ein kleines Team erforderte. Die KI übernimmt den Standardcode, das Nachschlagen von Syntax, das Gerüst, das erste Refactoring. Was bleibt, ist die Arbeit des Urteilsvermögens. Und genau da glänzen erfahrene Entwickler.

Für jemanden ohne diese Tiefe ist KI gleichermaßen beschleunigend — direkt auf ein anspruchsvolleres Chaos zu. Das Werkzeug unterscheidet nicht zwischen einer guten Architektur-Entscheidung und einer schrecklichen. Es wird freudig Tausende Zeilen selbstbewusst falschen Codes generieren, wenn niemand mit echtem Verständnis lenkt.

Das bedeutet, dass die Lücke zwischen einem starken Entwickler mit KI und einem schwachen Entwickler mit KI nicht schrumpft. Sie wächst. Explosionsartig. Der Meister seines Fachs, den Ihr Filter vor drei Monaten abgelehnt hat, würde jetzt mehr Wert liefern als das gesamte Team ATS-genehmigter Schlagwort-Treffer, das Sie stattdessen eingestellt haben.

Und die Tragödie ist von außen sichtbar. Unternehmen, die genau diese Art von erfahrenem Urteilsvermögen dringend benötigen, schauen weg, weil die Management-Konversation gleichzeitig von zwei falschen Narrativen vereinnahmt wurde: der Geschichte vom Fachkräftemangel, die den kaputten Filter entschuldigt, und der KI-ersetzt-Entwickler-Geschichte, die entschuldigt, überhaupt nicht in menschliche Expertise zu investieren.

Die wahre Frage für Führungskräfte

Wenn Ihre Organisation nur in Entwicklererfahrung investieren kann, wenn ein Framework es modisch macht, haben Sie die Frage bereits beantwortet, ob Sie Ihre Leute wertschätzen. Sie tun es nicht. Sie schätzen die Einhaltung dessen, was die aktuelle Branchenerzählung verlangt.

Echte Investition sieht anders aus. Sie sieht so aus:

• Lernzeit finanzieren, ohne dass ein gebrandetes Programm erforderlich ist, um sie zu rechtfertigen.
• Erfahrenen Entwicklern erlauben, Junioren zu betreuen, ohne so zu tun, als wäre das Verschwendung.
• Nach Urteilsvermögen und Bandbreite einzustellen anstatt nach Schlagwort-Symmetrie.
• Technischen Leuten Autorität über technische Entscheidungen geben, ohne dass eine Transformationsinitiative erforderlich ist, um sie zu gewähren.
• Teams stabil genug halten, um Kontext aufzubauen, anstatt alle sechs Monate durch externe Dienstleister zu rotieren.
• Erkennen, dass es in der KI-Debatte nicht darum geht, Entwickler zu ersetzen, sondern darum, Ihren stärksten Leuten mehr Hebelwirkung zu verleihen.
• Das Primadonna-Label fallenlassen und zuhören, wenn technische Leute erklären, warum etwas nicht funktionieren wird.
• Aufhören so zu tun, als sei Software eine Support-Funktion, wenn sie das Ding ist, was Ihr Unternehmen tatsächlich verkauft, worauf es läuft oder womit es konkurriert.

Nichts davon erfordert ein Framework. Nichts davon erfordert eine Zertifizierung. Nichts davon erfordert ein Reifegradmodell, ein Beratungsprojekt oder eine Konferenz-Keynote zur Legitimation.

Es erfordert eine Führung, die glaubt, dass ihre eigenen Leute Investitionen als Standardbedingung der Beschäftigung verdienen — nicht als Belohnung für das Überleben des neuesten organisatorischen Modezyklus. Es erfordert das Eingeständnis, dass die politische Einstufung von Software als IT-Support schon immer eine bequeme Fiktion war, die Entscheidern erlaubte, nicht zu lernen, worauf das Unternehmen eigentlich angewiesen ist.

Die Meister ihres Fachs sind da draußen. Einige von ihnen sind bereits in Ihrer Organisation, unterfordert, ungehört und leise als schwierig bezeichnet, weil sie Ihnen ständig Dinge sagen, die Sie nicht wissen wollen. Einige von ihnen haben sich letzten Monat beworben und Ihr ATS hat sie abgelehnt. Einige von ihnen haben aufgehört, sich bei Unternehmen wie Ihrem zu bewerben, weil der Filter klargemacht hat, dass sie nicht erwünscht sind.

KI hat dieses Problem nicht geschaffen. Sie hat es nur teurer gemacht, es zu ignorieren.