Manager and Coding – A Career Position Assessment

Summary

Three experienced tech professionals discuss the central question: Should developers in management still actively program? Jan Krieger from Programmierbar, Dennis Becker (Head of Development) and Mirko Seifert (Defluencer, Founder Prio Null) share different approaches. While Seifert alternates between coding and management, Becker has consciously distanced himself from code – yet both emphasize that fundamental developer experience remains essential for credibility and empathy in leadership roles.

People

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

Topics

• Management vs. Hands-on Development
• Career Development in Tech Companies
• Code Review and Power Dynamics
• Psychological Problem Solving (Alchemy Concept)
• AI Tools for Development and Design

Detailed Summary

The episode addresses a classic tension in software development: At what point should you stop programming when you take on management responsibility?

The three perspectives:

Dennis Becker describes his path from Mobile Developer via Product Owner to his current role as Head of Development. For him, the reduction of code was gradual and unintentional. With growing teams (now ~50 people), there simply was no time for active development. Consciously, he decided to hand over technical authority to the teams – he no longer makes architectural decisions, but instead creates space for others. Becker emphasizes: You don't need to write code to remain relevant. His experience as a former developer helps him understand the problems developers solve daily.

Mirko Seifert, on the other hand, alternates considerably. At Defbooster, he had phases with 95% coding, then phases with zero percent. Today at Prio Null, it fluctuates depending on the market phase. He openly admits: When coding drops below a certain threshold (approximately 3–4 weeks without code), he becomes dissatisfied. For him, programming isn't just work but balance – "eight hours of code feels like vacation, eight hours of marketing needs real vacation afterwards". But it's important to him: This activity must happen because he enjoys it, not because it has to. The team must not suffer from it.

Jan Krieger occupies a hybrid position. He has grown with early-stage startups, was sometimes responsible for development and product, now focuses on Programmierbar and internal architecture questions. Writing code is less attractive to him than understanding systems – an important distinction. When he hasn't looked at the technology for too long, he becomes "restless".

The insight: There is no ideal model. It depends on personal inclination, company size, team dynamics, and personal maturity.

Credibility and Empathy:

All three emphasize: Developer experience is valuable for leaders – but not because of the latest syntax. It's about understanding classic problems:

• Why is a simple feature complex?
• What hidden dependencies exist in old codebases?
• How does uncertainty and unpredictability feel?

These insights are timeless and enduring. Becker mentions that AI tools have recently increased his hands-on work share – because he wants to experiment himself in decisions about AI integration.

The Pitfalls:

A cautionary example: A CTO who for 5 years only developed one special software for himself, ignored everything else, and thus blocked the entire company. Or the classic case: A manager reads code commits and calls developers into the office to criticize design decisions – micromanagement that reduces productivity.

Mirko also mentions the spiral of rabbit holes: The more code you write yourself, the more love for your own code, the harder it becomes to let things go. Solution: Conscious self-limitation and good teams you trust.

The Role of Experience:

Seifert emphasizes the importance of empathy and perspective-taking – that's the actual skill in leadership roles, not knowing the latest frameworks. But: Entirely without current technical experience, it becomes difficult to maintain respect. Developers quickly notice when someone "can't contribute to the conversation".

A Surprising Learning Field: Recruiting and interviews. Becker shares that hands-on coding wasn't decisive in hiring. Rather: Can I ask authentic, "stupid questions" about technologies I don't know? How does the person explain their work to me? That's a better indicator than technical detail knowledge.

The Psychological Shift:

Seifert shares a formative experience: In 13 years, he witnessed large teams build things for months that were later completely discarded. This frustration drove him away from pure tech solutions toward product discovery, customer conversations, and minimalist approaches. That's a mature view of problem-solving – not always technology, sometimes just psychology and design.

Core Statements

• Hands-on coding is optional, but developer empathy is non-negotiable – Managers should understand what development means, even if they no longer program themselves.

• Intrinsic motivation over career pressure – Those who only move into management because "higher up pays more" quickly lose authenticity. The best option: parallel existing career paths (Senior Engineer vs. Manager).

• The right question isn't "how much code" but "who do I work for?" – If the team suffers from your side projects, the balance is wrong.

• Stay up-to-date through diverse channels – Not just hands-on coding, also reading pull requests, conferences, conversations with teams, articles. But: Everyone learns differently; some need hands-on, others can understand through reading.

• Major shifts (like AI in development) require trying it yourself – Not just theoretical knowledge, but practical experience in real projects.

• Control power dynamics – Code reviews from the boss can be toxic. Trust and long-established teams help avoid this.

• Psychology before technology – Sometimes a better name (Selax instead of Pacific salmon) solves a problem that doesn't need software.

Stakeholders & Affected Parties

• Developers in teams: Benefit from managers with technical understanding, suffer from micromanagement by managers still too close to code.
• Managers/Tech Leads: Must balance relevant experience with focused leadership work.
• Companies: Lose productivity when too much talent in management positions gets distracted by code, but also when management has zero tech understanding.
• New team members: Quickly sense whether old codebases are still "loved" by founders, making modernization difficult.

Opportunities & Risks

Action Relevance

For tech leaders:

1. Consciously reflect: Why do I still program? Is it passion or habit?
2. Ask your team honestly (perhaps anonymously) whether your code contributions help or hinder.
3. Establish clear boundaries: When do you "switch" into coding mode, when not?
4. Actively read pull requests and architecture docs instead of just coding yourself – saves time and shows respect.
5. Experiment with new technologies (e.g., AI tools) yourself to make informed decisions.

For organizations:

1. Create parallel career paths (Senior Engineer ≠ lower than Manager).
2. Don't automatically promote every good developer into management – some are better as specialists.
3. Ensure leads don't maintain "favorite features" for too long.

For new leads:

1. Recognize: The focus shift to people and processes isn't "less valuable" than code.
2. Develop empathy for ambiguity, estimation, and hidden complexity in codebases.
3. Establish feedback mechanisms so you don't fall into your own rabbit hole.

Quality Assurance & Fact-Checking

• [x] Central statements and quotes verified (podcast transcript)
• [x] People correctly assigned and contexts accurate
• [x] No hallucinations – all examples from the conversation
• [x] Use of AI tools (Notebook LM, Stitch) and book recommendation (Alchemy by Rory Sutherland) verified
• [ ] ⚠️ Specific metrics on code reduction (e.g., Dennis: "very little") are subjective and unmeasured
• [x] No political sidebars or bias detected

Additional Research

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

   • Psychological problem-solving vs. technical approaches
   • https://www.youtube.com/watch?v=qzwWX5Jc9sU (TED Talk)

2. Google Notebook LM & Stitch

   • Open-source alternative: Ollama for local AI
   • Compare GitHub Copilot, ChatGPT for dev workflows

3. Career Models in Tech Companies

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

Sources

Primary Source:
Deep Dive Podcast – Episode 198: "Manager and Coding with 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
Published: 08.01.2026

Additional Sources:

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) – Parallel career paths in tech
3. Spotify Labs: "Spotify Engineering Culture" (Video Series) – Matrix models for tech leadership

Footer (Transparency Notice)

This text was created with the assistance of Claude.
Editorial responsibility: clarus.news | Fact-checking: 08.01.2026
Transcript ID: 86 | Length of original transcript: 79,445 characters

Note: This document summarizes an English and German conversation. It focuses on the central theses and practical implications for tech leaders and developers in career transitions.