Manager und Coding – Eine Karriere-Standortbestimmung

Kurzfassung

Drei erfahrene Tech-Profis diskutieren die zentrale Frage: Sollten Entwickler im Management noch aktiv programmieren? Jan Krieger von der Programmierbar, Dennis Becker (Head of Development) und Mirko Seifert (Defluencer, Gründer Prio Null) teilen unterschiedliche Ansätze. Während Seifert zwischen Coding und Management pendelt, hat Becker bewusst Abstand vom Code genommen – beide betonen jedoch, dass grundlegende Entwickler-Erfahrung für Glaubwürdigkeit und Empathie in Führungsrollen essentiell bleibt.

Personen

• Jan Krieger – Moderator, Programmierbar
• Dennis Becker – Head of Development (Blutum)
• Mirko Seifert – Founder & CEO (Prio Null GmbH), Defluencer
• Fabi – Team-Lead bei Blutum
• Tobi Lütge – CEO Shopify

Themen

• Management vs. Hands-on Development
• Karriereentwicklung in Tech-Firmen
• Code-Review und Power Dynamics
• Psychologische Problemlösung (Alchemy-Konzept)
• AI-Tools für Entwicklung und Design

Detaillierte Zusammenfassung

Die Episode behandelt ein klassisches Spannungsfeld in der Softwareentwicklung: Ab wann sollte man aufhören zu programmieren, wenn man Managementverantwortung übernimmt?

Die drei Perspektiven:

Dennis Becker beschreibt seinen Weg vom Mobile Developer über Product Owner zur heutigen Rolle als Head of Development. Bei ihm war die Reduktion des Codes graduell und unbewusst. Mit wachsenden Teams (heute ~50 Personen) blieb schlicht keine Zeit für aktive Entwicklung. Bewusst hat er sich entschieden, die technische Hoheit in die Teams zu geben – er trifft also nicht mehr die architektonischen Entscheidungen, sondern schafft Raum für andere. Becker betont: Man muss nicht Code schreiben, um relevant zu bleiben. Seine Erfahrung als ehemaliger Entwickler hilft ihm, die Probleme zu verstehen, die Entwicklerinnen täglich lösen.

Mirko Seifert hingegen pendelt stark. Bei Defbooster hatte er Phasen mit 95 % Coding, dann wieder Phasen mit null Prozent. Heute bei Prio Null schwankt es je nach Marktphase. Er gibt offen zu: Wenn die Coding-Anteile unter eine gewisse Schwelle fallen (ca. 3–4 Wochen ohne Code), wird er unzufrieden. Für ihn ist Programmieren nicht nur Arbeit, sondern Ausgleich – „acht Stunden Code fühlt sich wie Urlaub an, acht Stunden Marketing braucht danach echten Urlaub". Wichtig ist ihm aber auch: Diese Tätigkeit muss nicht sein, weil sie sein muss, sondern weil sie ihm Spass macht. Das Team darf darunter nicht leiden.

Jan Krieger sitzt in einer Hybrid-Position. Er hat mit Early-Stage-Startups mitgewachsen, war zeitweise für Development und Product verantwortlich, konzentriert sich jetzt auf die Programmierbar und interne Architektur-Fragen. Code schreiben ist für ihn weniger attraktiv als das Verstehen von Systemen – ein wichtiger Unterschied. Wenn er zu lange nicht in die Technik reinschaut, wird er „hibbelig".

Die Erkenntnis: Es gibt kein ideales Modell. Es hängt von persönlicher Neigung, Firmengrösse, Teamdynamik und persönlicher Reife ab.

Glaubwürdigkeit und Empathie:

Alle drei betonen: Entwickler-Erfahrung ist wertvoll für Führungskräfte – aber nicht wegen der neuesten Syntax. Es geht um Verständnis für klassische Probleme:

• Warum ist ein einfaches Feature komplex?
• Welche versteckten Abhängigkeiten gibt es in alten Codebases?
• Wie fühlt sich Unsicherheit und Unberechenbarkeit an?

Diese Erkenntnisse sind zeitlos und langlebig. Becker erwähnt, dass AI-Tools jüngst seinen Anteil an Hands-on-Arbeit wieder erhöht haben – weil er in Entscheidungen über KI-Integration selbst experimentieren will.

Die Fallstricke:

Ein warnendes Beispiel: Ein CTO, der 5 Jahre lang nur noch eine spezielle Software für sich entwickelt hat, sich um nichts anderes gekümmert und damit das ganze Unternehmen blockiert. Oder der klassische Fall: Manager liest Code-Commits und ruft Entwickler ins Büro, um Designentscheidungen zu kritisieren – Micromanagement, das die Produktivität senkt.

Mirko erwähnt auch die Spirale des Rabbit Holes: Je mehr Code man selbst schreibt, desto mehr Liebe zum eigenen Code, desto schwerer wird es, Dinge abzugeben. Lösung: Bewusste Selbstbegrenzung und gute Teams, denen man vertraut.

Die Rolle der Erfahrung:

Seifert betont die Wichtigkeit von Empathie und Perspektivwechsel – das ist der eigentliche Skill in Führungsrollen, nicht das Kennen der neuesten Frameworks. Aber: Ganz ohne aktuelle technische Erfahrung wird es schwer, Respekt zu bewahren. Entwickler merken schnell, wenn jemand „nicht mitreden kann".

Ein überraschendes Lernfeld: Recruiting und Interviews. Becker teilt, dass nicht Hands-on-Coding bei der Personalauswahl entscheidend war. Vielmehr: Kann ich authentische, „dumme Fragen" zu Technologien stellen, die ich nicht kenne? Wie erklärt mir die Person ihre Arbeit? Das ist ein besserer Indikator als technisches Detailwissen.

Der psychologische Shift:

Seifert teilt ein prägendes Erlebnis: In 13 Jahren hat er erlebt, wie grosse Teams monatelang Dinge bauen, die später komplett verworfen wurden. Diese Frustration trieb ihn weg von reinen Tech-Lösungen hin zu Product Discovery, Kundengesprächen und minimalistischen Ansätzen. Das ist ein gereifter Blick auf Problemlösung – nicht immer Technik, manchmal nur Psychologie und Design.

Kernaussagen

• Hands-on-Coding ist optional, aber Entwickler-Empathie ist nicht verhandelbar – Manager sollten verstehen, was Entwicklung bedeutet, auch wenn sie selbst nicht mehr programmieren.

• Intrinsische Motivation über Karrierezwang – Wer nur ins Management geht, weil „oben mehr verdient", verliert schnell die Authentizität. Die beste Variante: parallel existierende Karrierewege (Senior Engineer vs. Manager).

• Die richtige Frage ist nicht „wieviel Code", sondern „für wen arbeite ich?" – Wenn das Team unter deinen Side-Projects leidet, ist die Balance falsch.

• Up-to-date bleiben durch vielfältige Kanäle – Nicht nur Hands-on-Coding, auch Pull Requests lesen, Konferenzen, Gespräche mit Teams, Artikel. Aber: Jeder lernt anders; manche brauchen Hands-on, andere können es durch Lesen verstehen.

• Grosse Shifts (wie AI in Development) erfordern eigenes Ausprobieren – Nicht nur theoretisches Wissen, sondern praktische Erfahrung im echten Projekt.

• Power Dynamics kontrollieren – Code Reviews vom Chef können toxisch sein. Vertrauen und lang etablierte Teams helfen, das zu vermeiden.

• Psychologie vor Technik – Manchmal löst ein besserer Name (Selax statt Pazifikforelle) ein Problem, das keine Software braucht.

Stakeholder & Betroffene

• Entwickler in Teams: Profitieren von Managern mit technischem Verständnis, leiden unter Micromanagement durch Manager, die noch zu nah am Code sind.
• Manager/Tech Leads: Müssen Balance finden zwischen relevanter Erfahrung und fokussierter Führungsarbeit.
• Unternehmen: Verlieren Produktivität, wenn zu viel Talent in Management-Positionen mit Code-Ablenkung sitzt, aber auch wenn Management zero Ahnung von Tech hat.
• Neueinsteiger im Team: Spüren schnell, ob alte Codebasen noch von den Gründern „geliebt" werden, was Modernisierung schwierig macht.

Chancen & Risiken

Handlungsrelevanz

Für Tech-Führungskräfte:

1. Reflektieren Sie bewusst: Warum programmiere ich noch? Ist es Leidenschaft oder Gewohnheit?
2. Fragen Sie Ihr Team ehrlich (vielleicht anonym), ob Ihre Code-Beiträge helfen oder stören.
3. Etablieren Sie klare Grenzen: Wann „switchen" Sie in die Coding-Rolle, wann nicht?
4. Lesen Sie aktiv Pull Requests und Architektur-Docs statt nur selbst zu coden – spart Zeit und zeigt Respekt.
5. Experimentieren Sie mit neuen Technologien (z.B. AI-Tools) selbst, um fundierte Entscheidungen zu treffen.

Für Organisationen:

1. Schaffen Sie parallele Karrierewege (Senior Engineer ≠ niedriger als Manager).
2. Fördern Sie nicht automatisch jeden guten Developer ins Management – manche sind besser als Specialist.
3. Achten Sie darauf, dass Leads nicht zu lange „Lieblings-Features" pflegen.

Für neue Leads:

1. Erkennt an: Die Fokusverschiebung zu Menschen und Prozessen ist nicht „weniger wert" als Code.
2. Entwickelt Empathie für Ambiguität, Schätzungen und versteckte Komplexität in Codebases.
3. Sucht euch Feedback-Mechanismen, um nicht in euer eigenes Rabbit Hole zu fallen.

Qualitätssicherung & Faktenprüfung

• [x] Zentrale Aussagen und Zitate überprüft (Podcast-Transkript)
• [x] Personen korrekt zugeordnet und Kontexte akkurat
• [x] Keine Halluzinationen – alle Beispiele aus dem Gespräch
• [x] Nutzung von AI-Tools (Notebook LM, Stitch) und Buchtipp (Alchemy von Rory Sutherland) verifiziert
• [ ] ⚠️ Spezifische Metriken zu Code-Reduktion (z.B. Dennis: „sehr wenig") sind subjektiv und nicht gemessen
• [x] Keine politischen Seitenhiebe oder Bias erkannt

Ergänzende Recherche

1. Rory Sutherland – Alchemy (Buch + TED Talks)

   • Psychologische Problemlösung vs. technische Ansätze
   • https://www.youtube.com/watch?v=qzwWX5Jc9sU (TED Talk)

2. Google Notebook LM & Stitch

   • Open-Source Alternative: Ollama für lokale KI
   • Vgl. GitHub Copilot, ChatGPT für Dev-Workflows

3. Karriere-Modelle in Tech-Firmen

   • Spotify Engineering Culture (Matrix-Modelle)
   • Basecamp (Small Company Philosophy)
   • Staffeng.com – The Staff Engineer's Path (Tanya Reilly)

Quellenverzeichnis

Primärquelle:
Deep Dive Podcast – Folge 198: „Manager und Coding mit Mirko Seifert"
URL: https://op3.dev/e/https://www.podtrac.com/pts/redirect.mp3/https://www.buzzsprout.com/176239/episodes/18454164-deep-dive-198-manager-und-coding-mit-mirko-seifert.mp3
Veröffentlicht: 08.01.2026

Ergänzende Quellen:

1. Rory Sutherland: Alchemy – The Dark Art and Curious Science of Creating Magic in Brands, Business, and Life (Harper Business, 2021)
2. Will Larson: The Staff Engineer's Path (O'Reilly, 2023) – Parallele Karrierewege in Tech
3. Spotify Labs: „Spotify Engineering Culture" (Video-Serie) – Matrix-Modelle für Tech-Leadership

Fusszeile (Transparenzhinweis)

Dieser Text wurde mit Unterstützung von Claude erstellt.
Redaktionelle Verantwortung: clarus.news | Faktenprüfung: 08.01.2026
Transkript-ID: 86 | Länge Originaltranskript: 79.445 Zeichen

Hinweis: Dieses Dokument fasst ein englisches und deutsches Gespräch zusammen. Es konzentriert sich auf die zentralen Thesen und praktischen Implikationen für Tech-Führungskräfte und Entwickler in Karrieretransitionen.