Directeur et programmation – Une détermination de la position professionnelle

Auteur : clarus.news Source : clarus.news

Résumé court

Trois professionnels expérimentés de la tech discutent de la question centrale : les développeurs en management devraient-ils continuer à programmer activement ? Jan Krieger de Programmierbar, Dennis Becker (Head of Development) et Mirko Seifert (Defluencer, fondateur Prio Null) partagent des approches différentes. Tandis que Seifert oscille entre programmation et management, Becker s'est volontairement éloigné du code – cependant, les deux soulignent que l'expérience fondamentale en développement reste essentielle pour la crédibilité et l'empathie dans les rôles de direction.

Personnes

• Jan Krieger – Modérateur, Programmierbar
• Dennis Becker – Head of Development (Blutum)
• Mirko Seifert – Fondateur & PDG (Prio Null GmbH), Defluencer
• Fabi – Team-Lead chez Blutum
• Tobi Lütge – PDG Shopify

Thèmes

• Management vs. Développement pratique
• Développement de carrière dans les entreprises technologiques
• Critique de code et dynamique de pouvoir
• Résolution de problèmes psychologiques (concept Alchemy)
• Outils IA pour le développement et la conception

Résumé détaillé

L'épisode traite un champ de tensions classique dans le développement logiciel : à partir de quand devrait-on arrêter de programmer quand on assume des responsabilités de management ?

Les trois perspectives :

Dennis Becker décrit son parcours de développeur mobile via responsable de produit jusqu'à son rôle actuel de Head of Development. Pour lui, la réduction du code a été graduelle et inconsciente. Avec la croissance des équipes (aujourd'hui ~50 personnes), il ne restait simplement pas de temps pour le développement actif. Il s'est consciemment décidé à confier la maîtrise technique aux équipes – il ne prend donc plus les décisions architecturales, mais crée de l'espace pour les autres. Becker souligne : on n'a pas besoin d'écrire du code pour rester pertinent. Son expérience en tant qu'ancien développeur l'aide à comprendre les problèmes que les développeurs résolvent quotidiennement.

Mirko Seifert en revanche oscille beaucoup. Chez Defbooster, il a eu des phases avec 95 % de programmation, puis d'autres avec zéro pour cent. Aujourd'hui chez Prio Null, cela fluctue selon la phase du marché. Il admet ouvertement : quand la part de programmation tombe en dessous d'un certain seuil (env. 3–4 semaines sans code), il devient insatisfait. Pour lui, la programmation n'est pas seulement du travail, mais un loisir – « huit heures de code se sentent comme des vacances, huit heures de marketing ont besoin de vraies vacances après ». Mais c'est aussi important pour lui : cette activité ne doit pas être faite parce qu'elle doit l'être, mais parce qu'elle lui plaît. L'équipe ne doit pas en souffrir.

Jan Krieger est dans une position hybride. Il a grandi avec des startups en phase initiale, a été responsable du développement et du produit temporairement, se concentre maintenant sur Programmierbar et les questions d'architecture interne. Écrire du code est moins attrayant pour lui que de comprendre les systèmes – une distinction importante. S'il passe trop longtemps sans regarder la technologie, il devient « nerveux ».

L'insight : Il n'y a pas de modèle idéal. Cela dépend de la préférence personnelle, de la taille de l'entreprise, de la dynamique de l'équipe et de la maturité personnelle.

Crédibilité et empathie :

Tous les trois soulignent : l'expérience en développement est précieuse pour les dirigeants – mais pas à cause de la dernière syntaxe. Il s'agit de comprendre les problèmes classiques :

• Pourquoi une fonctionnalité simple est-elle complexe ?
• Quelles dépendances cachées existent dans les anciennes bases de code ?
• À quoi ressemble l'insécurité et l'imprévisibilité ?

Ces insights sont intemporels et durables. Becker mentionne que les outils IA ont récemment augmenté sa part de travail pratique – parce qu'il veut expérimenter lui-même les décisions concernant l'intégration de l'IA.

Les pièges :

Un exemple avertisseur : un CTO qui pendant 5 ans a développé uniquement un logiciel spécialisé pour lui-même, ne s'est préoccupé de rien d'autre et a ainsi bloqué l'ensemble de l'entreprise. Ou le cas classique : un responsable lit les commits de code et appelle les développeurs au bureau pour critiquer les décisions de conception – du micromanagement qui réduit la productivité.

Mirko mentionne également la spirale du labyrinthe : plus on écrit soi-même du code, plus on aime son propre code, plus il est difficile de déléguer. Solution : auto-limitation consciente et bonnes équipes auxquelles on fait confiance.

Le rôle de l'expérience :

Seifert souligne l'importance de l'empathie et du changement de perspective – c'est la vraie compétence dans les rôles de direction, pas la connaissance des derniers frameworks. Mais : complètement sans expérience technique actuelle, il devient difficile de conserver le respect. Les développeurs remarquent rapidement quand quelqu'un « ne peut pas participer à la conversation ».

Un domaine d'apprentissage surprenant : Le recrutement et les entretiens. Becker partage que le fait de ne pas faire de programmation pratique n'était pas décisif dans la sélection du personnel. Plutôt : puis-je poser des questions authentiques et « bêtes » sur les technologies que je ne connais pas ? Comment la personne m'explique-t-elle son travail ? C'est un meilleur indicateur que la connaissance technique détaillée.

Le changement psychologique :

Seifert partage une expérience marquante : en 13 ans, il a vu de grandes équipes construire pendant des mois des choses qui ont été complètement abandonnées par la suite. Cette frustration l'a éloigné des solutions purement technologiques vers la découverte de produits, les conversations clients et les approches minimalistes. C'est un regard mûr sur la résolution de problèmes – pas toujours de la technique, parfois juste de la psychologie et du design.

Déclarations clés

• La programmation pratique est facultative, mais l'empathie envers les développeurs ne l'est pas – Les responsables devraient comprendre ce que signifie le développement, même s'ils ne programment plus eux-mêmes.

• Motivation intrinsèque plutôt que pression de carrière – Celui qui ne passe au management que parce que « on gagne plus en haut » perd rapidement son authenticité. La meilleure variante : voies de carrière parallèles coexistantes (Senior Engineer vs. Manager).

• La bonne question n'est pas « combien de code », mais « pour qui je travaille ? » – Si l'équipe souffre de vos projets annexes, l'équilibre est mauvais.

• Rester à jour via des canaux variés – Pas seulement la programmation pratique, mais aussi lire les pull requests, les conférences, parler avec les équipes, les articles. Mais : chacun apprend différemment ; certains ont besoin de pratique, d'autres peuvent comprendre par la lecture.

• Les grands changements (comme l'IA dans le développement) nécessitent une expérimentation personnelle – Pas seulement la connaissance théorique, mais l'expérience pratique dans un vrai projet.

• Contrôler la dynamique de pouvoir – Les critiques de code du chef peuvent être toxiques. La confiance et les équipes bien établies aident à l'éviter.

• La psychologie avant la technologie – Parfois, un meilleur nom (Selax au lieu de Pazifikforelle) résout un problème qui n'a pas besoin de logiciel.

Parties prenantes & Personnes affectées

• Développeurs dans les équipes : Bénéficient des responsables ayant une compréhension technique, souffrent du micromanagement des responsables qui sont encore trop près du code.
• Responsables/Tech Leads : Doivent trouver un équilibre entre l'expérience pertinente et le travail de direction ciblé.
• Entreprises : Perdent en productivité quand trop de talents occupent des postes de management avec des distractions liées au code, mais aussi quand le management n'a aucune connaissance en technologie.
• Nouveaux venus dans l'équipe : Sentent rapidement si les anciennes bases de code sont toujours « aimées » par les fondateurs, ce qui rend la modernisation difficile.

Opportunités et risques

Pertinence pour l'action

Pour les responsables technologiques :

1. Réfléchissez consciemment : pourquoi je programme encore ? Est-ce une passion ou une habitude ?
2. Demandez à votre équipe honnêtement (peut-être de manière anonyme) si vos contributions de code aident ou gênent.
3. Établissez des limites claires : quand « basculez »-vous vers le rôle de programmeur, quand ne le faites-vous pas ?
4. Lisez activement les pull requests et les documents d'architecture plutôt que de programmer vous-même – économise du temps et montre du respect.
5. Expérimentez vous-même les nouvelles technologies (p. ex. les outils IA) pour prendre des décisions éclairées.

Pour les organisations :

1. Créez des voies de carrière parallèles (Senior Engineer ≠ moins qu'un Manager).
2. Ne promouvez pas automatiquement chaque bon développeur au management – certains sont meilleurs en tant que spécialistes.
3. Assurez-vous que les responsables ne maintiennent pas trop longtemps leurs « fonctionnalités préférées ».

Pour les nouveaux responsables :

1. Reconnaissez : le changement de focus vers les personnes et les processus n'est pas « moins important » que le code.
2. Développez l'empathie pour l'ambiguïté, les estimations et la complexité cachée dans les bases de code.
3. Trouvez-vous des mécanismes de rétroaction pour ne pas tomber dans votre propre labyrinthe.

Assurance qualité et vérification des faits

• [x] Déclarations et citations centrales vérifiées (transcription du podcast)
• [x] Personnes correctement attribuées et contextes exacts
• [x] Pas d'hallucinations – tous les exemples de la conversation
• [x] Utilisation des outils IA (Notebook LM, Stitch) et recommandation de livre (Alchemy de Rory Sutherland) vérifiées
• [ ] ⚠️ Les métriques spécifiques de réduction de code (p. ex. Dennis : « très peu ») sont subjectives et non mesurées
• [x] Aucun parti pris politique ou biais détecté

Recherche supplémentaire

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

   • Résolution de problèmes psychologiques vs. approches technologiques
   • https://www.youtube.com/watch?v=qzwWX5Jc9sU (TED Talk)

2. Google Notebook LM & Stitch

   • Alternative open source : Ollama pour l'IA locale
   • Comp. GitHub Copilot, ChatGPT pour les workflows dev

3. Modèles de carrière dans les entreprises technologiques

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

Référence des sources

Source primaire :
Deep Dive Podcast – Épisode 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
Publié : 08.01.2026

Sources supplémentaires :

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) – Voies de carrière parallèles en tech
3. Spotify Labs : « Spotify Engineering Culture » (Série vidéo) – Modèles Matrix pour le leadership en technologie

Note de bas de page (Avis de transparence)

Ce texte a été créé avec l'aide de Claude.
Responsabilité éditoriale : clarus.news | Vérification des faits : 08.01.2026
ID de transcription : 86 | Longueur de la transcription d'origine : 79 445 caractères

Remarque : Ce document résume une conversation en anglais et allemand. Il se concentre sur les thèses centrales et les implications pratiques pour les responsables technologiques et les développeurs en transition de carrière.