Excellent article sur les avantages et inconvénients de rejoindre une startup à ces débuts.
L'étude est sur 3 pays cette année: France, Allemagne et Pays-Bas
Quelques chiffres:
- seulement 16% de développeuses
- 58 000€ salaire médian en France (50 000€ hors Paris)
- jusqu'à 40% de différence entre le salaire Paris vs hors Paris
- le rôle CDI le mieux payé est développeur backend
- le rôle freelance le mieux payé est data engineer/product manager
Un retour d'expérience sur comment organiser son process de recrutement.
Les conseils en plus de Fabien Ducher:
En amont
- l'organisation de la tech est suffisamment claire
- on est à l'aise sur la salary grid (qu'elle soit affichée publiquement ou non)
- on est sur d'avoir les ressources pour accompagner l'onboarding et rampup
- Les personnes qui font passer des entretiens sont formées à le faire (posture, ce qui est ok ou pas ok de dire, comment on le mène, les entretiens eux même, etc.)
- Checklist d'onboarding avec toutes les composantes (RH, IT, manager, newcomer) déjà existante.
L'offre
- inclusive! exemple: pas un empilement de compétences (soft et hard), mais un message clair sur le fait que c'est un repère et qu'il ne faut pas cocher toutes les cases pour candidater
- La description du process : les entretiens, avec qui, la durée et à quoi ils servent
Le process de validation
- s'il y a des tests / questions techniques, ce sont les mêmes pour tout le monde et on assess les résultats
- On liste à l'avance les red flag qu'on ne veut pas voir
- Max 2 semaines entre la prise de contact et la décision
- J'aimerai beaucoup tester aussi l'idée que la personne qui candidate vient avec un cas technique qu'elle discute avec des personnes de l'art. (ca brise le test commun à tous, mais c'est au moins un contexte que le candidat maitrise et qui sera moins stressant)
- Feedback clair et factuel après chaque entretien, surtout en cas de nogo à une étape
- Lors du dernier entretien, on est en situation d'échange libre où on répond à toutes les questions de la personne qui candidate, on ré-explique l'onboarding, le carreer path, la période d'essai, les attentes, etc.
- un comité d'évaluation à la fin avec toutes les personnes ayant réalisé un entretien
La proposition
- Salaire en comparant avec la grille, les stats de salaire à poste équivalent en interne (incluant l'équité homme / femme) et des bench extérieur (à noter ici que Figures est canon comme outil)
l'onboarding
- Welcome 1-1 où on présente la checklist d'onboarding, on cale les 1-1 hebdo,
- On présente les obj de PE la première semaine
- On s'assure que l'équipe l'accueil bien dans le day to day
Période d'essai
- on fait des 360 pour avoir le max d'avis et pas uniquement l'avis du manager
- On refait a minima un point à mi PE, voir tous les mois avec le newcomer
- Ou on coupe ou on valide, le renouvellement ne sert que pour des doutes mineurs qui n'auraient pas pu être levé dans le délai. Avoir une boule noire nuira à terme plus à votre organisation que n'avoir personne.
Un outil qui permet de calculer la répartition des parts lors de la création d'une startup
Autre outils
https://www.embroker.com/blog/startup-equity-calculator/
https://capbase.com/startup-equity-calculator/
Product Owner ou Product Manager, au final ce sont des postes semblables dont le but est de conduire les développements produit à un apport de valeur.
Onboarder une personne avec une position "haute" dans la hiérarchie n'est jamais simple.
Il est crucial de passer les premières semaines à apprendre et à appliquer les méthodes actuelles avant d'essayer de lancer ses propres méthodes.
Aussi, il est préférable de commencer par résoudre un problème mineur plutôt que de se casser les dents sur le problème majeur.
Très bon conseil pour booster une carrière.
Il est important de rester curieux et de s'intéresser aux autres métiers de la tech (product, management, marketing, sales), c'est ce qui permet d'avoir une meilleure compréhension de l'ensemble d'une entreprise et d'améliorer la qualité de ses contributions.
Les personnes ayant été à des rôles de manager et d'individual contributor sont très souvent plus ouvertes car elles connaissent les deux côtés de la barrière.
Un très bon article de l'équipe tech de Malt sur l'observabilité code/équipe en utilisant Git.
Cela permet d'identifier:
- les dépendances entre services
- les "hot spots" fréquemment édités
- les personnes ayant la meilleur connaissance de portions du code
Comment être efficace à un poste de top management "Head of ..."
Globalement l'article se présente sous la forme d'une grande liste, pour moi les points les plus importants:
- créer un lien de confiance avec son équipe: discuter et déléguer pour faire émerger d'autres leaders
- évolution de carrière: définir clairement les potentielles évolutions de carrière avec les attentes et salaires pour chaque poste
- impliquation dans l'équipe dirigeante pour comprendre la stratégie de l'entreprise
- développer son réseau pour échanger avec d'autres tech leaders
- recrutement
- software delivery
- veille technologique
Un excellent article sur le management!
En tant que manager, on est responsable du management des processus tandis qu'on donne laisse libre les personnes dans leur travail (éviter le micro-management)
Pour lui les processus sont des attentes que l'ont rend explicites.
Par exemple, le processus de code review est une attente d'un code de qualité.
Il parle de beaucoup d'autres sujets intéressants:
- décision vs opinions: tout le monde à un opinion, le manager doit asseoir une décision
- ownership: essentiel de permettre aux gens de s'approprier leurs sujets
- confiance
- se séparer de quelqu'un
- et d'autres..
As a manager, everything is your fault.
You are in charge of processes and people.
You either created the processes where this outcome happened
or you hired (or did not fire) the wrong people.
Un article sur les métriques dans une équipe tech.
C'est quelque chose dont on peut se passer lorsque l'équipe est encore petite (<20 personnes) mais qui devient indispensable par la suite afin de comprendre le coût d'un effort et si il est réellement nécessaire.
Par exemple, ça permet de planifier (ou non) des chantier de refactoring de code ou de scaling infra.
Il y a plusieurs niveaux de maturité (Data Maturity Level):
- 0 Unaware: aucune collecte et utilisation de la donnée
- 1 Aware: certaines données sont collectées mais pas vraiment de responsable pour les surveiller
- 2 Reactive: présence de KPI produit, adoption légère
- 3 Proactive: présence de responsable sur les outils de collecte
- 4 Managed: la donnée est considérée comme critique pour l'entreprise et est communiquée au plus haut niveau
- 5 Effective: la donnée est publiée et utilisée à l'extérieur de l'entreprise
Excellent article sur le problème de la complexité qui est très souvent ce qui ralentit l'innovation autant au niveau technique que produit.
Un article très intéressant sur le processus de levée de fonds pour une startup.
L'auteur développe sur sa vision des VC ("Venture Capital", investisseurs) et donne quelques clés pour comprendre leur manière de fonctionner:
- ils sont souvent prêt à proposer de l'aide de diverses manière (contacts, brain storming, etc) car une facette de leur métier est aussi de conseiller les porteurs de projets et de créer une relation avec eux
- il ne faut pas interprêter l'enthousiasme comme une certitude d'investissement, pour eux être sceptique à propos de votre projet ne fait pas avancer les choses
- ils ne sont pas forcément des experts et ont besoin de vulgarisation pour comprendre le potentiel du projet
A propos du pitch, il faut bien sur être totalement en confiance car c'est cela qui va transparaitre. Il ne faut pas non plus hésiter à embellir la vérité et être très optimiste.
Finalement, le pitch deck (les slides souvent) va être partagé à de nombreux autres VCs donc il doit être autoporteur: contenir suffisament d'informations pour appâter le chaland et en même temps pas trop pour obtenir un rendez-vous pour expliquer la suite ;-)
Un article qui parle de ce qu'ils nomment les "Wildcard Persons".
Ces personnes ont toutes une gammes de compétences et sont capable de gérer quasiment n'importe quelle tâche dans une startup, du développement au marketing en passant par la relation client.
Bien sur ce n'est pas forcément du travail d'expert mais du travail néanmoins suffisament bon pour rester jusqu'à ce qu'il y ait l'argent et le temps pour qu'un véritable expert se penche sur la question.
L'histoire du CTO de Shift Technology (détection de fraudes) qui décide de revenir à un poste plus "hands-on".
Un très bon billet pour choisir une startup ayant un environnement de travail intéressant et un futur prometteur.
Par définition, une startup c'est une entreprise qui fait un pari sur un marché ou une techno et elle se doit d'avancer rapidement donc on est amené à faire plusieurs choses (couteau suisse) et l'environnement sera forcément plus stressant qu'un job "pépére" dans une ESN (qui a dit planqué ?)
Les points de vigilance:
- les fondateurs 👉 concrètement vous allez bosser avec eux très souvent donc est-ce que vous êtes convaincu par leur stratégie
- le business plan 👉 si vous n'y croyez pas, peu de chance que vous soyez motivé dans la durée
- la culture et les valeurs 👉 cherchez de préférence bienveillance, esprit d'équipe et reconnaissance
- le sérieux technologique 👉est-ce que les bases sont solides? est-ce que l'équipe technique originel est encore la? (ça se limite à une personne souvent)
- le salaire 👉 souvent un peu en dessous du marché, attention à ne pas se faire avoir par une promesse de beaucoup de BSPCE qui restent un pari
Les deadlines sont très souvent contre productive et particulièrement en programmation.
Elles rajoutent beaucoup de stress et contribuent souvent à dégrader la qualité de ce qui est produit ou à une augmentation des heures de travail.
J'aime beaucoup ce qui dit l'auteur à propos des choix qui s'offrent à nous quand on a raté une deadline:
- décider d'une autre deadline
- virer quelqu'un
- réduire le scope
Un article coup de gueule pour expliquer la différence entre un supplier et un volunteer.
Le supplier est payé pour son travail et fournit des garanties de service, le volunteer travaille bénévolement et il n'a aucune garantie à fournir
Sous le coude
SPACE est un framework pour mesurer l'efficacité d'une équipe d'ingénieurs.
Il est découpé en 5 catégories qui doivent chacunes être évaluées avec différentes métriques:
- Satisfaction: rétention, satisfaction des développeurs
- Performance: vélocité code review, story point livrés, uptime
- Activity: lignes de codes, commits, fréquence déploiements
- Communication & Collaboration: time to merge, qualité des réunions, partage de la connaissance
- Efficiency: timing code reviews, nombre d'interruptions
Bien sur il n'est pas nécessaire de récolter des métriques pour chaques catégories et certaines métriques peuvent avoir moins de sens dans certaines équipes mais ça donne déjà de solides bases pour évoluer la performance d'une équipe.