Wenn Fähigkeiten im Trichter verschwinden

Beitrag von Mai 2025 aus dem Bereich Innovation von Arthur Weder

Ein Entwickler kann zehn Programmiersprachen beherrschen, komplexe Systeme bauen, Sicherheitslücken erkennen und Apps für Android wie iOS entwickeln, doch wenn sein Umfeld das nicht versteht, bleibt sein Können unsichtbar. In vielen Unternehmen existiert ein unsichtbarer Trichter, durch den jede Information über Fähigkeiten, Ideen oder technologische Vorschläge wandert - und dabei fast immer kleiner, flacher, ungefährlicher wird. Am Ende bleibt nur das übrig, was die Projektleitung oder das Management noch greifen kann. Doch was bedeutet das für Innovation, Motivation und Projekterfolg?

 Wenn Fähigkeiten im Trichter verschwinden

Der Trichter der Wahrnehmung

In der täglichen Praxis erleben viele Entwickler Folgendes: Ihre Fähigkeiten werden nur so weit wahrgenommen, wie ihr direkter Vorgesetzter - häufig ein Vorgesetzter oder ein Projektleiter ohne tiefgreifende technische Kenntnisse - sie verstehen und einordnen kann. Alles, was darüber hinausgeht, wird ignoriert oder im besten Fall abgenickt, ohne tatsächlich aufgenommen zu werden.

Ein Beispiel:

Ein Entwickler wird im Projekt als PHP-Programmierer eingesetzt. Was dabei übersehen wird: Er bringt umfassende Kenntnisse in Java, Python, Testing, Server-Administration unter Linux sowie IT-Security nach OWASP-Standards mit. Doch im Projekt geht es ausschließlich um PHP, JavaScript, HTML und CSS - und genau darauf wird er reduziert. Seine zusätzlichen Fähigkeiten könnten Prozesse absichern, automatisieren oder deutlich effizienter gestalten. Doch sie bleiben unsichtbar, weil niemand im Team oder Management sie versteht, richtig einordnen oder sinnvoll ins Projekt integrieren kann.

Das ist nicht nur frustrierend, es ist auch wirtschaftlich unklug.

Dabei geht es keineswegs darum, Projektleiter abzuwerten - viele von ihnen arbeiten unter enormem Druck, mit begrenztem technischen Einblick und straffen Budgets. Der Punkt ist: Ohne strukturelle Unterstützung und gemeinsame Sprache können auch sie das Potenzial ihrer Teams nicht vollständig erkennen oder nutzen.

Wenn Innovation am Projektleiter scheitert

Ein besonders tragischer Aspekt dieses Phänomens ist der Umgang mit Innovation: Viele Entwickler versuchen proaktiv, ihre Fähigkeiten einzubringen - nicht aus Eitelkeit, sondern weil sie überzeugt sind, damit Projekte besser, sicherer, zukunftsfähiger zu machen. Doch genau hier entsteht ein Dilemma: Der Projektleiter erkennt den Wert nicht, oder schlimmer - er erkennt ihn, kann ihn aber nicht weitervermitteln.

Warum?

Weil es ihm an technischem Verständnis, an sprachlicher Übersetzungskompetenz oder schlicht am Selbstvertrauen fehlt, um dem Kunden diese Vorschläge zu erklären, zu rechtfertigen – und vor allem, dafür ein Budget zu verlangen.

Das Ergebnis:

  • Der Kunde versteht den Vorschlag nicht oder bekommt ihn nie zu hören.
  • Die Projektleitung verkauft „das Falsche“ oder bleibt vage und verliert Vertrauen.
  • Die Neuerung wird entweder abgelehnt oder fehlerhaft umgesetzt.
  • Der Entwickler sieht, dass seine Mühe verpufft - und zieht sich zurück.

Dieser Rückzug ist keine Faulheit. Es ist eine bewusste Entscheidung:

„Warum sollte ich mich einbringen, wenn mein Beitrag nicht verstanden, nicht geteilt und nicht mitgetragen wird?“

Vom Einzelkämpfer zur tragfähigen Struktur

Ein weiterer Punkt: Gute Entwickler wollen keine Ein-Mann-Shows. Sie wissen, dass Projekte, die nur auf einer einzigen Person aufbauen, beim nächsten Weggang zusammenbrechen. Moderne Entwickler legen Wert auf Wissensaustausch, Dokumentation, gemeinsames Lernen. Die Zeiten, in denen Code „gehortet“ wurde wie ein Schatz, sind vorbei. Zumindest bei jenen, die an nachhaltiger Qualität interessiert sind.

Doch auch hier wirkt der Trichter:

Wenn das Umfeld nicht bereit (oder fähig) ist mitzudenken, mitzuwachsen, mitzutauschen, bleibt Innovation erneut stecken. Der Entwickler bleibt alleine mit seinem Wissen oder wird zum Bottleneck, den er nie sein wollte. Ein Team, das nicht gemeinsam lernen kann, wird nie innovativ sein.

Ein „Bottleneck“ ist eine Person oder Komponente, ohne die nichts weitergeht – weil nur sie ein bestimmtes Wissen oder eine Fähigkeit hat.

Die unsichtbaren Kosten

Was viele Unternehmen nicht sehen: Dieser Umgang mit technischer Kompetenz hat einen hohen Preis.

  • Talentverlust: Gute Entwickler verlassen das Unternehmen, weil sie sich nicht entfalten können.
  • Fehleinsätze: Fähigkeiten bleiben ungenutzt, obwohl sie intern verfügbar wären.
  • Fehlentscheidungen: Ohne technisches Verständnis werden wichtige Entscheidungen falsch getroffen.
  • Verlorene Innovation: Vorschläge, die Wettbewerbsvorteile bringen könnten, versanden im Kommunikationssumpf.
  • Scheiternde Projekte: Weil das Management nicht versteht, was es eigentlich verkaufen müsste, wird falsch kalkuliert, unterverkauft - und Projekte laufen ins Leere.

Was Unternehmen tun können

1. Technologisches Grundverständnis fördern

Projektleiter und Entscheider müssen keine Entwickler werden – aber sie sollten verstehen, worum es geht, wenn technische Vorschläge gemacht werden. Nicht im Detail, aber konzeptionell. Nur so können sie fundierte Entscheidungen treffen.

2. Kommunikationsbrücken bauen

Zwischen Entwicklerteams und Management braucht es Menschen, die beide Welten verstehen – „Tech Advocates“, „Bridge Engineers“ oder ähnliche Rollen können hier Wunder wirken.

3. Raum für Sichtbarkeit schaffen

Entwickler sollten regelmäßig die Gelegenheit bekommen, ihre Fähigkeiten zu zeigen: In internen Tech-Talks, Lightning Talks, Brown-Bag-Sessions oder Innovations-Demos.

4. Feedback- und Ideenräume etablieren

Innovative Vorschläge dürfen nicht zur Störung erklärt werden. Sie brauchen feste Formate und eine respektvolle, ehrliche Evaluierung.

5. Kultur des Teilens fördern

Innovation ist kein Soloakt. Teams sollten lernen, Wissen zu teilen, voneinander zu lernen und gemeinsam besser zu werden. Wenn der Trichter verhindert, dass sich alle weiterentwickeln, hat das Team keine Zukunft.

Fazit

Ein Entwickler ist nicht nur ein Umsetzer von Anforderungen. Er ist ein potenzieller Mitgestalter, Vordenker, Innovator. Doch all das kann nur entstehen, wenn sein Umfeld die Fähigkeit hat, ihn zu verstehen. Wenn Projektleiter nicht erklären können, was verkauft werden soll – oder sich nicht trauen, für Leistung einen angemessenen Preis zu verlangen – dann scheitert nicht der Entwickler. Dann scheitert das System.

Der Trichter der Wahrnehmung ist kein Naturgesetz. Er ist ein strukturelles, kulturelles Problem. Und er kann verändert werden – wenn wir anfangen zuzuhören, zu verstehen und gemeinsam zu lernen.


Trichterproblem

Das Trichterproblem (Metapher) beschreibt die strukturelle Reduktion von Entwicklerkompetenz auf das, was durch die Hierarchieebenen hindurch noch verstanden, weitergegeben oder verkauft werden kann.

Das Trichterproblem entsteht, wenn technische Fähigkeiten, innovative Ideen oder Lösungsvorschläge eines Entwicklers auf dem Weg zum Projektleiter oder Kunden so weit vereinfacht oder gefiltert werden, dass ihr Wert nicht mehr erkennbar ist – und deshalb ungenutzt bleibt.