TL;DR: Wenn ein Geschäftsführer ohne IT-Hintergrund Entwickler führt, scheitert die Kommunikation an der Übersetzung — Anforderungen aus dem Business kommen als Rauschen an, Entwickler-Argumente bleiben undurchsichtig. Ein Software-Unternehmer mit rund 20 Mitarbeitern hat nach 20 Jahren Delegation die IT-Leitung selbst übernommen und durch gezielte Übersetzungsarbeit sein Team integriert — inklusive eines skeptischen Entwicklers, der heute voll mitzieht. Der Hebel war keine neue Methode, sondern die Fähigkeit, Anforderungen aus dem Fachbereich so in die IT zu übersetzen, dass beide Seiten handeln können.
„Manchmal war das wie Rauschen"
Montag, Sprint-Review. Der Geschäftsführer sitzt mit vier Entwicklern im Raum. Einer erklärt, warum ein Feature drei Wochen länger braucht. Er redet über Abhängigkeiten, technische Schulden, eine API, die sich anders verhält als dokumentiert. Der Geschäftsführer nickt. Er versteht jedes einzelne Wort. Trotzdem hat er keine Ahnung, ob der Termin jetzt realistisch ist oder ob er gerade eine höflich verpackte Ausrede hört.
20 Jahre Delegation — und kein Überblick
Genau so beschrieb es ein Software-Unternehmer mit rund 20 Mitarbeitern. Betriebswirt, der seine Firma aufgebaut, das Beratungsgeschäft entwickelt und die Softwareentwicklung strategisch vorangetrieben hatte. Die operative IT-Leitung hatte er delegiert — erst an einen internen Teamleiter, dann an einen Externen. Zwei Jahrzehnte lang. Sein Fazit: „Ich wusste 20 Jahre lang nicht, wo genau wir stehen."
Als Termine weiter verpasst wurden, Qualitätsprobleme sich wiederholten und das Team in endlosen Meetings versank, übernahm er selbst. Und stand vor einem konkreten Dilemma: aufräumen, ohne das Team zu verlieren. Er konnte Anforderungen aus dem Business formulieren — aber er konnte sie nicht so in die IT übersetzen, dass sein Team etwas damit anfangen konnte. In der Zusammenarbeit mit anne&thorsten. bekam er einen Sparring-Partner, der beide Welten kannte: Geschäftsführung und Entwicklung. Jede Methode — Sprintplanung, Umgang mit einem skeptischen Entwickler, Integration eines Backend-Entwicklers, der lieber allein arbeitete — wurde so übersetzt, dass er sie als Nicht-ITler im Arbeitsalltag einsetzen konnte.
Warum die Brücke fehlt — und was sie ersetzt
Die Kommunikation zwischen Betriebswirt und Entwicklern scheitert an einer Stelle, die selten benannt wird: Beide Seiten sprechen über dasselbe Projekt, meinen aber unterschiedliche Dinge. Der Geschäftsführer sagt „Termin". Er meint: Kundenzusage, Umsatz, Vertragspflicht. Der Entwickler sagt „Termin". Er meint: technische Machbarkeit unter den gegebenen Bedingungen.
Wenn der Geschäftsführer fragt „Schaffen wir das?", hört der Entwickler „Versprich mir was". Also antwortet er ausweichend — und der Geschäftsführer liest das als Ausrede oder fehlende Verbindlichkeit.
Das Ergebnis: Eskalation. Jede Seite fühlt sich vom anderen blockiert. Der Geschäftsführer greift härter durch — was Entwickler als Misstrauen lesen. Oder er zieht sich zurück — was Entwickler als Desinteresse lesen.
Der Hebel liegt dazwischen: Anforderungen aus dem Fachbereich in eine Sprache bringen, die für Entwickler handlungsrelevant ist. Und umgekehrt: technische Einwände so übersetzen, dass der Geschäftsführer eine Entscheidung treffen kann, ohne die technischen Details selbst bewerten zu müssen.
Bei dem Unternehmer aus der Geschichte funktionierte das schrittweise. Er führte Sprints ein, ohne kontrollierend zu wirken. Er lernte, technische Argumente einzuordnen — welche sind fundiert, welche sind Vermeidung. Der Entwickler, der anfangs skeptisch war, zog mit. Der Backend-Entwickler, der isoliert gearbeitet hatte, wurde Teil der gemeinsamen Sprints. Die Stimmung im Team verbesserte sich — trotz der Strukturveränderungen.
Heute hat der Geschäftsführer erstmals nach 20 Jahren einen klaren Überblick über den Stand seiner Softwareentwicklung, ohne eine externe IT-Leitung zu brauchen.
Der Mechanismus dahinter ist simpel, aber schwer umzusetzen: Übersetzung braucht jemanden, der in beiden Welten denken kann. Wenn der Geschäftsführer das selbst lernt — auch nur auf einem funktionalen Niveau —, fällt die teuerste Schwachstelle weg: die Abhängigkeit von einem Mittelsmann, der beide Seiten interpretiert, statt sie zu verbinden.
Wo stehst Du gerade?
Zähl die Meetings dieser Woche, in denen Du genickt hast, ohne sicher zu sein, ob Du wirklich verstanden hast, was Dein Entwicklerteam Dir gesagt hat. Wenn die Zahl über null liegt, fehlt Dir die Übersetzung zwischen Fachbereich und IT. Und solange die fehlt, bleibt Dir nur blindes Vertrauen oder Durchgreifen — beides funktioniert auf Dauer nicht.
Weiterlesen
- Entwicklungseffizienz verdoppeln: Wie ein 30-Minuten-Daily 20 Meeting-Stunden ersetzt — 20 Stunden Meetings pro Woche, kein Sprint-Commitment, Features seit einem Jahr offen.
- Schwieriger Entwickler im Team: Wie ein Inhaber sein Team am Bremser vorbeisteuerte — Wenn der erfahrenste Entwickler das Projekt bremst und das Team mitzieht — wie ein Inhaber die Abhängigkeit auflöste und sein Team am...
Wenn Du schauen willst, wo bei Dir gerade der größte Hebel liegt — wir machen das in 60 Minuten, kostenlos.
Lieber erstmal selbst durcharbeiten? Der 12-Wochen-Kurs hat die komplette Methode als Online-Modul. Einmalzahlung 199 €, dauerhaft verfügbar.
Häufige Fragen
Muss ich als Geschäftsführer programmieren lernen, um mein Entwicklerteam zu führen?
Programmieren lernen ist unnötig. Was Du brauchst, ist die Fähigkeit, technische Argumente einzuordnen — fundiert oder Vermeidung — und Deine Anforderungen so zu formulieren, dass Entwickler daraus Aufgaben ableiten können. Das ist eine Kommunikationsfähigkeit, keine technische.
Wie erkenne ich, ob mein Entwicklerteam mir eine fachlich fundierte Einschätzung gibt oder eine Ausrede?
Stell konkrete Rückfragen: „Was genau blockiert Dich?", „Was bräuchtest Du, damit der Termin hält?" Fundierte Einschätzungen werden konkreter, je mehr Du nachfragst. Ausreden werden vager. Wenn Du diesen Unterschied über mehrere Sprints beobachtest, kalibrierst Du Dein Urteil.
Was mache ich, wenn ein Entwickler die neuen Strukturen offen ablehnt?
Offene Ablehnung ist ein besseres Signal als stille Verweigerung — Du weißt, woran Du bist. Klär im Einzelgespräch, was genau die Ablehnung auslöst: Ist es Kontrollverlust, fehlende Einbeziehung, oder ein fachlicher Einwand? Dann entscheide, ob Du die Struktur anpasst oder ob der Widerstand auf ein tieferes Problem hinweist.
Funktioniert das auch, wenn ich schon eine IT-Leitung habe, die zwischen mir und dem Team steht?
Ja, aber dann liegt der Engpass woanders. Prüf, ob Deine IT-Leitung tatsächlich übersetzt — oder ob sie eine eigene Schicht zwischen Dir und dem Team bildet, die beide Seiten frustriert. Der Test: Kannst Du nach einem Gespräch mit Deiner IT-Leitung eine konkrete Entscheidung treffen? Wenn die Antwort regelmäßig „nein" ist, fehlt die Übersetzung trotz Mittelsmann.