Très bonne analyse de ce qu'il faut pour un véritable leadership.

Vous ne pouvez pas être responsable de quelque chose que vous ne contrôlez pas. Il faut le mandat.

Vous ne pouvez pas utiliser ce mandat efficacement pour quelque chose que vous ne comprenez pas. Vous avez besoin de connaissances.

Vous n’acquérez des connaissances que si vous êtes entièrement responsable des conséquences de votre mandat.

Une excellente étude sur la productivité des développeurs.

• les employés qui se déconnectent à la fin de la journée sont 20% plus productifs
• faire des pauses améliore la productivité
• en moyenne, le temps idéal de concentration par jour est 4h
• au delà de 2h de réunion par jour, les développeurs se sente surchargés
• seulement 1 développeur sur 4 se considère comme productif entre 15 et 18h

Un outil de gestion de projet mais rien à voir avec Jira car c'est moderne, rapide et bien fait

Une alternative à l'organisation avec une Todo list

Excellent article sur l'évolution des rôles dans une scaleup.

ça revient sur les définitions des rôles CTO vs VP Engineering et aussi sur le rôle de Fellow Engineer.

Dans une scaleup, le CTO historique doit parfois laisser la place pour se concentrer sur des missions de contributeur individuel à fort impact.

Le mouvement no-estimate prend de plus en plus d'ampleur dans le monde du Produit.

D'un côté les équipes de développements fonctionnement mal avec des estimations:

• imprévisibilité inhérente au développement
• stress de ne pas avoir respecter une estimation
• pas ou peu de temps consacrer aux tâches annexes d'amélioration continue

De l'autre côté, les équipes Sales, Marketing et Customer Success ont besoin de fournir des dates à leurs clients.

L'estimation peut éventuellement se faire mais à un niveau plus haut comme l'Epic si tout le monde accepte que cette estimation pourra quand même changer en cours de route.

Au fur et à mesure du développement, l'estimation devient de plus en plus précise jusqu'à la livraison de la feature.

Je garde ces deux citations:

Les estimations sont le “doudou” des managers avec leur côté rassurant. Elles donnent une sensation de contrôle.

Je ne compte pas le nombre d’heures passées dans ma carrière à discuter d’estimations

Comment mesurer la répartition des connaissances au sein d'une équipe à l'aide de Skills Matrices.

Très utile pour identifier les bus factors sur lesquels une ou très peu de personnes seraient capable d'intervenir.

L'article donne une méthode pour créer cette liste de connaissances.

Retour d'expérience sur l'organisation Data chez Blablacar.

Ils ont créé une équipe Data transverse avec uniquement des Data Enginers.

Quelques take aways:

• investir dans des solutions génériques et réutilisables paye sur le moyen/long term

• il y a un intérêt à ce que l'équipe Data devienne le point central entre tous les stackholders

• rechercher l'adoption plutôt que l'obligation

• toujours considérer le "build vs buy"

Un article qui remet en cause la pertinence des User Stories dans un process produit.

Les résultats d'un programme de recherche basé sur les DORA métriques pour évaluer les méthodes de travail ayant le plus d'impact.

• les équipes qui se concentrent sur l'utilisateur ont de meilleures performances organisationnelles

• une documentation de qualité amplifie l'impact des autres méthodes (~x2 en moyenne!)

Pour les pratique de développement pures:

• intégration continue
• vitesse des revues de code
• architecture découplée
• trunk based development

Récapitulatif sur les métriques possibles dans une équipe de développeurs.

DORA, un framework axé sur la qualité des processus de développement et du code:

• Lead Time for Change: combien de temps entre une idée de feature et son déploiement
• Deployment Frequency
• Change Failure Rate: % de code déployé qui cause des bugs dans le système
• Mean Time to Recovery: combien de temps pour fixer un bug

SPACE, un framework plus global sur la performance au sein d'une équipe:

• Satisfaction & Well Being: état mentale au sein de l'équipe pendant le travail
• Performance: observation de la vélocité de l'équipe
• Activity: observation de la quantité de travail réalisé
• Communication & Collaboration: qualité des interactions au sein de l'équipe
• Efficiency & Flow: qualité de l'organisation du temps de l'équipe

DevEx, un framework qui se concentre sur l'expérience des développeurs:

• Feedback Loops: processus et temps nécessaire à prendre en compte les retours
• Cognitive Load: qualité et taille de la codebase
• Flow State: organisation du temps de développement

Un article qui parle du chemin de carrière technique (vs le chemin managérial de l'engineering manager par exemple)

Les rôles de staff engineer sont des rôles de spécialistes technique avec une forte composante de leadership et de mentoring.

Ils doivent se concentrer sur les résultats des projets qu'ils prennent en main et sont plus pro-actifs que les développeurs senior.

Une liste de conseils pour CTO

Une étude sur les salaires développeurs mais aussi des autres postes comme manager, director, co-founder etc

Une excellente pratique qui oblige à baser toute réunion sur un document.

La réunion commence par une revue du document afin d'être sur que tout le monde l'ait compris.

Les commentaires sont traités pendant la réunion mais aussi ensuite en async.

Un article sur la loi de Conway qui théorise un lien fort entre la structure d'un système (software par exemple) et la structure des moyen de communication de ceux qui le conçoive.

Un article sur la nécessité de dire l'inconfortable vérité lors des one-to-one afin de permettre à chacun de s'améliorer

Une liste des niveaux d'ingénieurs dans plusieurs boites.

Un article sur les bonnes pratiques autour de la code review.

C'est souvent une part importante dans le Time To Deploy d'une équipe et l'auteur donne des conseils pour accèlérer ce processus:

• garder les PRs petites: <200 lignes de code
• faire les reviews rapidement: mettre un place un outil de notification aide beaucoup sur ce point
• automatiser le maximum: tests, lint
• utiliser des stacked diffs pour découper plus facilement une PR (pas dispo sur Github malheureusement)
• utiliser la méthode Ship/Show/Ask qui permet d'éviter la nécessité de reviews dans certaines situations

Plus j'entends parler du Stacked Diff/Trunk Based développement et plus ça donne envie d'essayer. Graphite semble proposer ce genre de fonctionnement et intègre Github

Un autre article qui parle de rejoindre une startup en early stage mais du point de vu concret d'un développeur et de ce qu'on peut apporter.

C'est aussi un bon résumé de comment arriver à un MVP