Aller au contenu
Le journal

Notes & retours d’expérience

Why Some CTOs Quit Coding (And Why You Might Want to as Well)

5 min de lecture

Why Some CTOs Quit Coding (And Why You Might Want to as Well) This statement, often heard in the tech industry, sparks a passionate debate. On one side, some believe that the CTO should step away from… Why Some CTOs Quit Coding (And Why You Might Want to as Well) This statement, often heard in the t...

Why Some CTOs Quit Coding (And Why You Might Want to as Well)


This statement, often heard in the tech industry, sparks a passionate debate. On one side, some believe that the CTO should step away from coding to focus on strategy and management. On the other, many defend the idea that staying “hands-on” offers numerous advantages.

So, where does the truth lie? Is it a utopia, a repositioning of the role, or simply a matter of scale?


The Advantages of Staying “Hands-On”


Deep Understanding of the Team’s Needs

By remaining involved in coding, the CTO is better equipped to understand the technical challenges faced by the team. This deep understanding facilitates communication, strengthens trust, and allows for more informed decision-making.


Sharp Knowledge of the Technical Stack

Regular coding enables the CTO to keep their knowledge of the company’s technological stack up to date. They become more aware of pain points, necessary trade-offs, and opportunities for improvement.


Leadership by Example

A CTO who rolls up their sleeves inspires their team. They demonstrate commitment and passion for technology, which can be extremely motivating for developers.


Better Talent Selection

Being up to date with the latest technologies and development practices positions the CTO better to identify talent during the recruitment process. They know precisely which skills are needed to advance the team.


Adoption of New Tools

Technology evolves rapidly. A “hands-on” CTO is more likely to discover and experiment with new tools or frameworks, which can provide a competitive advantage to the company.


The Challenges of the CTO Role


Of course, the role of a CTO isn’t limited to coding. It also involves skills in management, strategy, and communication with other departments in the company. Stepping back is essential to define the long-term technological vision and align technical objectives with business goals.


Finding the Balance

It’s not about choosing between coding and managing but finding the right balance based on the company’s needs. In a startup or small business, the CTO will probably need to be more involved in development. As the company grows, they may need to delegate more to focus on strategy.


Adapting Their Involvement

A good CTO knows how to be flexible. They will step into the code when necessary but won’t hesitate to take a step back to handle broader challenges. The important thing is to stay connected to technical realities while assuming managerial responsibilities.


A Matter of Scale and Business Needs

It’s undeniable that a CTO leading a massive technical team will have less time to code. However, this doesn’t mean they should completely abandon this activity. Even with a large team, maintaining a link with coding can be beneficial.


Maintaining a Small Team

It’s possible to take a company far with a small technical team. This allows for maintaining agility and cohesion that’s hard to achieve in large structures. In this context, the CTO has every reason to stay close to development.


In Conclusion


It’s crucial to separate personal desires, career plans, and business needs when discussing the CTO’s role.

A good CTO will be “hands-on” if the need arises, without neglecting the necessary perspective required by their role. The key is to adapt their involvement according to circumstances while continuing to evolve professionally.

So, the debate isn’t about whether a CTO should stop coding but rather how they can balance their responsibilities to bring the maximum value to their team and the company. After all, effective leadership often lies in the ability to navigate between strategic vision and understanding of technical details.

Tout le journal
12 min de lecture

Harness engineering : ce qui entoure le modèle compte autant que le modèle

Un agent IA, c'est un modèle plus tout ce qui l'entoure : consignes, outils, mémoire, boucles de vérification, revue. Google Research publie un framework qui améliore ce harness sans toucher au modèle, l'équipe Claude Code d'Anthropic y a déplacé l'essentiel de sa revue de code, et les études commencent à chiffrer l'écart. Pour un CTO de PME, la question utile n'est plus « quel modèle choisir ? » mais « qu'est-ce qui entoure le modèle, et comment je le mesure ? ».

Lire l’article
10 min de lecture

Avant de donner des accès à un agent IA : la frontière de confiance

Un agent IA ne demande pas la permission : il émet un appel d'outil, et l'orchestrateur l'exécute. Une étude contourne six frameworks d'agents en demandant au modèle de répéter un texte, Anthropic décrit un agent qui récupère des jetons d'accès dans un fichier de réglages, et Satya Nadella demande de traiter les modèles comme un risque interne. Pour une PME, la question n'est plus de savoir si le modèle est fiable, mais où passe la frontière de confiance et quels contrôles s'y tiennent, hors du modèle.

Lire l’article
10 min de lecture

Souveraineté et réversibilité : combien coûte votre sortie ?

En quelques jours, la souveraineté numérique a fait l'actualité sous trois formes : un moteur de recherche quitte son fournisseur de modèles d'IA, des clouds « de confiance » attendent leur qualification, un éditeur promet de rendre son runtime auto-hébergeable. Pour un CTO de PME, une seule question reste utile : si je dois changer de fournisseur de modèle ou de cloud, combien cela me coûte-t-il, et en combien de temps ? C'est la réversibilité. Elle se prépare, se chiffre et se teste, et un premier passage tient en quatre semaines.

Lire l’article