Führungskräfteentwicklung im KMU — Wie du aus Fachkräften echte Führungskräfte machst

Das Dilemma: Dein bester Entwickler wird Teamlead — und scheitert

Hier die klassische Szene im KMU: Dein bester Entwickler. Schreibt sauberen Code. Kennt das System komplett. Löst komplexe Probleme. Alle mögen ihn arbeiten.

Dann brauchst du einen Teamlead. Also beforderst du ihn. "Du bist die beste Person, um das Team zu führen."

Sechs Monate später: Er ist frustriert. Das Team ist fragmentiert. Der beste Entwickler ist weg. Und der neue Teamlead ist auch nicht glücklich.

Das passiert weil du einen konzeptionellen Fehler gemacht hast: Du hast angenommen, dass technische Exzellenz automatisch zum Führungserfolg führt.

Tut sie nicht. Sie sind orthogonal.

Ein Entwickler der gerne Code schreibt wird ein Teamlead der ungerne führt. Das ist nicht böse. Es ist nicht faul. Es ist ein Missmatch. Er ist brillant bei einer Sache und schlecht bei der anderen.

Das größte KMU-Problem: Dein einziges Reward-System ist Beförderung. Also beförderst du gute Entwickler zu Teamleads. Damit zerstörst du zwei Dinge: Einen guten Entwickler und eine Position die anders besetzt sein sollte. Das ist auch genau die Art von Engpass, die Unternehmen skalieren unmöglich macht.

Warum Fachkompetenz ≠ Führungskompetenz

Das sollte offensichtlich sein. Aber ich sehe ständig Senior-Developer als Team-Leads die scheitern.

Code schreiben hat eine klare Struktur: Du kontrollierst das Ergebnis. Es ist technisch logisch. Es ist evaluierbar — der Code läuft oder läuft nicht. Es ist ein Craft. Je besser du bist, desto schneller geht es.

Führung funktioniert fundamental anders. Erstens: Du erreichst Ziele nicht durch Kontrolle, sondern durch Delegation. Dein Senior-Developer ist nicht daran gewöhnt, Macht abzugeben. Zweite: Während ein Entwickler davon ausgeht "Wenn ich das Problem erklär, versteht die Person das", funktionieren Menschen nicht so rational. Sie haben Ego. Sie haben Angst. Empathie ist nicht optional. Dritte: Der Code ist präzise. Eine Führungsentscheidung ist selten "richtig" oder "falsch". Sie ist "gut unter diesen Umständen" oder "in drei Monaten bedauerlich". Vierte: Ein brillanter Developer möchte auf seinem Gebiet brillanter werden. Ein Teamlead muss Menschen sehen für das, was sie werden könnten, nicht für das, was sie heute sind.

Die Kompetenzmodelle sind komplett orthogonal. Gute Entwickler brauchen tiefes technisches Wissen, schnelle Problemlösung, Code-Qualität, Selbstständigkeit. Sie haben oft ein niedriges Interesse an Dynamiken zwischen Menschen. Gute Teamleads brauchen emotionale Intelligenz, Delegationsfähigkeit, Konfliktbereitschaft und Geduld mit Lernprozessen. Sie müssen Menschen verstehen wollen.

Das ist nicht kausal verknüpft. Die besten Developer sind nicht automatisch die beste Führungskräfte.

Die 3 Phasen der Führungskräfteentwicklung im KMU

Wenn du erkannt hast: "Dieser Entwickler könnte eine gute Führungskraft sein" — wie machst du das systematisch?

Phase 1: Mindset-Shift (Monat 1-2)

Das ist das Fundament. Wenn der Mindset falsch ist, ist alles danach auch falsch.

Der Shift ist dieser: Vom "Ich bin verantwortlich für den Code" zu "Ich bin verantwortlich für mein Team". Das klingt einfach. Es ist es nicht. Deine Zufriedenheit kommt nicht mehr aus eigenem brillanten Code. Sie kommt aus "mein Team hat ein großes Problem gelöst". Du wirst weniger Code schreiben — das ist nicht Degradation, das ist Spezialisierung. Und du wirst Fehler anderer sehen und damit umgehen müssen, statt selbst reinzuspringen und zu fixen. Das ist psychologisch ein anderes Spiel.

Praktisch für diese Phase:

• Zunächst solltest du mit der Geschäftsführung klären: Was sind deine Erwartungen an den neuen Lead? Was sind Success-Metriken? Das sollte nicht sein "er schreibt guten Code". Das sollte sein "sein Team ist produktiv, happy und liefert".

Daneben ist Shadowing einer erfolgreichen Führungskraft entscheidend. Wenn du andere Teamleads hast die gut funktionieren, dann sollte der neue Lead zwei Wochen miterleben wie sie arbeiten. Wie führt sie 1-on-1s? Wie delegiert sie? Wie gibt sie Feedback? Das ist Training durch Beobachtung und funktioniert besser als jedes Seminar.

Wichtig ist auch, in einem ehrlichen Gespräch über Risiken zu sprechen. Sag dem potenziellen Lead: "Das wird schwer. Es wird Momente geben wo du dich frustriert fühlst, weil du nicht selbst coden kannst." Das vorbereitet die Person psychologisch auf die Realität.

Phase 2: Werkzeuge und Formate (Monat 2-6)

Jetzt kommt die Praxis. Die konkrete Handwerk der Führung.

Ein Teamlead braucht genau drei Werkzeuge:

• Das 1-on-1-Gespräch (um auf Augenhöhe Probleme zu sehen)
• Ein Entscheidungsrahmen (um nicht bei jeder Entscheidung zu Geschäftsführung zu laufen)
• Ein Feedbackformat (um zu entwickeln statt nur zu kritisieren)

1. Das 1-on-1:

Das ist 30 Minuten pro Woche mit jedem Mitarbeiter. Das Format ist einfach: Die ersten 10 Minuten gehören dem Mitarbeiter. "Wie geht es dir? Was brauchst du?" Nicht Status-Update, nicht deine Agenda. Die nächsten 10 Minuten sind für das, was diese Woche ansteht — ein Problem, eine Blockade, etwas bei dem du als Lead hilfreich sein kannst. Die letzten 10 Minuten sind für Entwicklung. "Woran möchtest du diese Woche arbeiten um besser zu werden?"

Das ist nicht ein Status-Report. Das ist ein Vertrauens-Gespräch. Wenn der Mitarbeiter sagt "mir geht's nicht gut", dann ignorierst du die Projekt-Liste für diese Woche und redest über das.

Bei eins+null haben wir erst falsch gemacht: 15-Minuten-Meetings die nur Projekt-Status waren. Das ist nicht ein 1-on-1. Das ist ein Status-Update. Richtige 1-on-1s finden immer zur gleichen Zeit statt (Mittwoch 10:00 Uhr), sind nur zwischen zwei Personen, sind vertraulich, und sind für den Mitarbeiter, nicht für dich. Das kostet eine Stunde pro Person pro Woche als Teamlead. Mit einem 4er-Team sind das 4 Stunden. Das ist der Job.

2. Ein Entscheidungsrahmen:

Dein Team wird dich ständig fragen: "Können wir X machen?" Wenn du bei jeder Entscheidung zu Geschäftsführung laufen musst, wirst du zum Flaschenhals und dein Team ist blockiert. Eine klare Entscheidungsrahmen gibt dem Team Autonomie in klaren Grenzen.

Beispiel für Budgetentscheidungen in einer Tech-Company: Budget bis 500 Euro entscheidet der Teamlead allein. Bei 500 bis 2.000 Euro entscheidet er, informiert aber die Geschäftsführung. Bei über 2.000 Euro schlägt er vor, die Geschäftsführung entscheidet.

Für technische Entscheidungen könnte das so aussehen: Neue Dependencies unter 100 MB entscheidet das Team. Über 100 MB oder mit kritischen Berechtigungen entscheidet der Teamlead mit dem Tech-Lead. Ein Wechsel von Framework oder Architektur geht zum CTO.

Der Punkt ist: Das Team weiß genau wo die Grenzen sind. Und innerhalb dieser Grenzen haben sie echte Autonomie. Ohne klare Grenzen passiert das: Entweder macht das Team nichts und wartet auf dir (Bottleneck), oder es macht alles und die Geschäftsführung wird überrascht (Chaos).

3. Ein Feedbackformat:

Das ist das schwierigste für neue Leads aus technischen Backgrounds. Weil Entwickler sind es gewohnt, Feedback zu geben wie "dieser Code ist schlecht".

Für Menschen-Führung brauchst du ein anderes Modell. Die SBI-Model funktioniert gut:

Situation - Behavior - Impact

Statt: "Du bist zu kritisch gegenüber dem Junior"

Besser: "In der Standup heute (Situation) hast du seine Lösung sofort kritisiert ohne ihn erklären zu lassen (Behavior). Er hat sich dann shutdown gefühlt und hat nicht mehr mitgemacht (Impact)."

Das ist spezifisch. Das ist fair. Und es ist actionable. Der Junior weiß genau was er anders machen soll.

Diese drei Werkzeuge — 1-on-1, Entscheidungsrahmen, SBI-Feedback — sind 80% dessen was ein Teamlead braucht. Die anderen 20% sind Erfahrung.

Phase 3: Routinen und Selbst-Reflexion (Monat 6+)

Nach sechs Monaten sollte diese Workflows zur Routine sein. Das 1-on-1 ist normal. Der Entscheidungsrahmen ist verinnerlicht. Feedback ist beiläufig.

Was jetzt fehlt ist Selbst-Reflexion. Regelmäßige Check-Ins mit der Geschäftsführung gehören dazu: Wie funktioniert das Team? (nicht nur Metriken, sondern Energie und Zusammenhalt). Wo brauche ich Support oder Coaching? Was habe ich gelernt? Was geht mir schwer? Das sollte monatlich sein mit einem erfahrenen Mentor — nicht unbedingt die Geschäftsführung, aber jemand mit Führungserfahrung.

Bei eins+null haben wir das falsch gemacht: Wir haben Teamleads eingestellt und dann angenommen sie funktionieren. Das ist gefährlich. Manche brauchen einen Monat um zu klicken. Manche brauchen sechs Monate. Manche finden, dass es nicht für sie ist. Das sollte offen sein.

Konkreter Implementierungs-Plan für morgen

Du hast jetzt erkannt: "Wir haben keinen strukturierten Weg um Führungskräfte zu entwickeln. Das sollte sich ändern."

Hier was du diese Woche anfangen kannst.

Zunächst: Identifiziere wer ein guter Teamlead sein könnte. Nicht die technisch Besten. Sondern die mit Interesse an anderen Menschen, Geduld (sie rasten nicht aus wenn jemand langsam lernt), klarer Kommunikation und Selbst-Awareness.

Dann führe ein ehrliches Gespräch. Nicht: "Ich möchte dich zum Teamlead machen." Sondern: "Ich glaube du könntest ein guter Teamlead sein. Das ist aber kein automatischer Career-Path. Das ist eine andere Rolle mit anderen Herausforderungen. Interessiert dich das? Und wenn ja, können wir dich systematisch vorbereiten." Wenn die Antwort "nein" ist — auch ok. Dann weißt du dass dieser Entwickler lieber ein Senior-Entwickler bleibt. Das ist auch ein vollwertiger Career-Path.

Wenn ja: Setz den Trainingsprozess auf. Wöchentliches Coaching mit dir oder einem externen Coach. Shadowing mit einem anderen erfolgreichen Teamlead. Training der Werkzeuge (1-on-1 Template, Entscheidungsrahmen, Feedbackformat).

Das wichtigste danach ist aber: Monatlicher Check-In. "Wie geht's dir?" Der Punkt wo neue Teamleads scheitern ist nicht die Theorie. Es ist die Einsamkeit. Plötzlich trägt man allein die Verantwortung für Menschen. Das ist psychologisch komplett anders als Code zu schreiben.

Lessons Learned: Was bei eins+null funktioniert hat — und was nicht

Ich bin keine Trainer. Ich bin ein Geschäftsführer der über viele Jahre Teamleads eingestellt, befördet, und ja, auch zu Rücktritt veranlasst hat.

Was funktioniert hat: Frühe Sortierung. Wir haben schnell gelernt — nicht alle guten Entwickler sind gute Leads. Statt ihnen ein Jahr Leiden zuzumuten, haben wir klar gesagt: "Das ist nicht die richtige Rolle für dich. Lass uns gemeinsam schauen, wie wir deine Stärken anders nutzen." Das war befreiend für beide Seiten.

Regelmäßige 1-on-1s mit der Geschäftsführung waren kritisch. Unsere besten Teamleads hatten monatliche Coaching-Sessions mit dem CEO. Sie waren nicht allein. Sie hatten jemand der ihnen rationale Fragen stellte ("Was ist eigentlich deine Hypothese hier?"). Das half extrem.

Kleine Teams zum Anfangen. Statt einen neuen Lead direkt mit einem 8er-Team loszuschicken, fingen wir mit 3-4 Personen an. Das macht Fehler weniger dramatisch und gibt Raum zum Lernen.

Transparenz über Schwierigkeiten. Wir haben nicht so getan als ob Führung einfach ist. Wir haben deutlich gesagt: "Das wird frustrierend. Du wirst Entscheidungen treffen die nicht alle mögen. Das ist normal." Das ist psychologisch wichtiger als alles andere.

Was nicht funktioniert hat: Off-Site-Training ohne Follow-Up. Wir haben Teamleads zu einem Führungs-Seminar geschickt. Alle waren begeistert. Eine Woche später war alles vergessen. Training ohne Reinforcement ist Zeitverschwendung.

Zu viel Autonomie zu früh funktioniert nicht. "Hier ist die Rolle. Viel Erfolg." Das zerstört neue Leads. Sie brauchen vier Wochen intensive Unterstützung bevor sie auf eigene Beine stehen können.

Keine klaren Metriken für "gute Führung" ist auch ein Problem. Wir haben lange nicht definiert: Was bedeutet "ein erfolgreicher Teamlead"? Das führte zu Unsicherheit. Sind meine Zahlen gut? Ist mein Team glücklich? Die Antwort sollte sein: "Hohe Produktivität UND hohe Zufriedenheit. Beide." Aber wir haben das nicht am Anfang gesagt.

Der größte Fehler: Das Drama-Zyklus

Es gibt ein Pattern das ich bei vielen KMUs sehe: Bester Entwickler wird zum Teamlead promoviert. Nach sechs Monaten ist klar: Das funktioniert nicht. Aber statt transparent zu sein, wird es ein langsames Drama. Der Lead weiß nicht wo er steht. Die Geschäftsführung ist unglücklich. Das Team ist verwirrt. Nach einem Jahr: Der Lead geht. Oft frustriert.

Das ist ein Management-Fehler, nicht ein Menschen-Fehler.

Das solltest du stattdessen tun: Nach drei Monaten: Ein ehrliches Gespräch.

"Wie ist es für dich? Funktioniert diese Rolle für dich? Oder merken wir dass das nicht der richtige Weg ist?" Wenn es nicht funktioniert — das ist ok. Ihr könnt gemeinsam einen anderen Weg finden.

Das Kind ist nicht verloren. Der Entwickler ist nicht kaputtgemacht. Du suchst einfach eine bessere Rolle für diese Person. Vielleicht ein Senior-Tech-Lead (Technologie-Entscheidungen ohne Führung). Vielleicht ein Trainer (Knowledge Transfer ohne Personalverantwortung). Es gibt viele Optionen außer "full Teamlead" und "zurück ins Team".

Das Fazit: Führung ist ein Craft

Gute Führung ist nicht Genetik. Es ist nicht Magie. Es ist ein Handwerk. Und wie bei jedem Handwerk braucht es Übung, Feedback und Geduld.

Dein nächster Schritt: Schau dir dein Team an. Wer hat das Potenzial für Führung? Nicht die Besten technisch. Sondern die mit Interesse an Menschen und Geduld.

Und wenn du erkannt hast wen — fang das Gespräch an. "Interessiert dich Leadership?" Alles danach ist Struktur.