Dans de précédents billets j’évoquais que nous utilisions Mongodb chez Malt mais j’ai évoqué dans certains meetups que nous n’en étions pas totalement satisfaits et que nous entamions une (lente) migration vers postgresql.
Je vous propose de faire un petit retour d’expérience sur ce sujet après désormais 7 ans d’utilisation de mongodb chez nous.
Parlons télétravail pour ce billet !
Si le télétravail (ou remote) s’est bien développé récemment, il est loin d’être encore très fréquent en France, seulement 17% de la population active.
Et pourtant il semble fortement demandé et je dirais même, idéalisé.
Dans ce billet je vous propose de vous décrire la façon dont nous faisons du télétravail chez Malt, les pratiques qui fonctionnent et celles qui n’ont pas fonctionné.
Dans ce billet j’aimerais partager nos réflexions chez Malt autour de l’évolution de carrière.
Et c’est un sujet épineux car pour beaucoup de boîtes un évolution de carrière se traduit par faire du management.
En 2009 Nicolas Martignole avait sorti un bon billet sur l’évolution de carrière dans le monde tech et la quasi inéluctabilité de basculer vers le management passé 30 ans. Rien que le titre posait la question, peut on être « Développeur après 31 ans ? »
source : http://www.mirchu.net/photos/evolution-of-software-engineer/
Mais la situation a un peu changé, le marché a gagné en maturité. On trouve de plus en plus de « seniors » en entreprise.
En 2013, la question est devenu « Peut-on toujours être développeur après 40 ans ?«
Et en 2017 Eric Siber enfonçait encore le clou en revendiquant au contraire tout l’intérêt d’être développeur à cet âge.
On prend le pari qu’on va commencer à voir fleurir des billets : être dev après 50 ans ?
Ok, sans doute que le sujet en SSII/ESN est un peu différent car il repose aussi sur la capacité à vendre des seniors dans une grille qui place tous les « seniors » au même niveau et t’es senior passé 7 ans d’exp donc…
Pour la faire courte, va vendre Jean-Michel 45 ans, payé 70k au même tarif que Billy, 30 ans, payé 55.
Jean-Michel si tu m’entends, tu as deux choix, pars chez un éditeur/client final ou devient indep si jamais t’as envie de poursuivre dans la tech et pas te transformer en monsieur poc/pompier/avant vente/ et manager.
C’est bien beau tout ça mais je veux en venir où ?
Je ne vais pas vous faire l’affront de vous réexpliquer le principe de Peter, j’ai l’impression que désormais il connu de tous. En très résumé :
“dans une hiérarchie, tout employé a tendance à s’élever à son niveau d’incompétence” (Wikipedia).
Et c’est exactement ce qui se passe lorsqu’un bon dev devient manager, c’est un métier différent et il y a une forte probabilité qu’il ne soit pas aussi bon.
Pour autant, l’expérience et l’expertise amènent les individus à être davantage écouté. Ils servent d’exemple, emmagasinent la connaissance du produit (métier et technique). Est ce qu’ils ne devraient donc pas logiquement devenir des managers ? On parle aussi de lead, est-ce la même chose ? Spoiler alert : non.
Retour en 2017, nous étions 9 dans l’équipe produit. Ma vision d’une équipe produit c’est une équipe où chacun participe à la conception, où chaque voix est entendu.
Les leads sont apparu naturellement sans besoin de les expliciter. Un lead étant la personne qui est sollicité davantage pour ces conseils, qui est reconnu par le groupe sur ces capacités à faire avancer/débloquer une situation, apporter de l’aide quand c’est nécessaire. C’est aussi son représentant.
Et cette notion on la retrouve dans un vieux sujet dont j’ai déjà parlé sur ce blog, la sociocratie.
Pour ceux qui ne connaissent pas la sociocratie, un des principes de bases repose sur la notion de cercle. Un cercle a un but commun. Une entreprise peut être constituée de multitudes de cercles qui peuvent être imbriqués. Les cercles discutent entre eux via des représentants qui sont désignés au sein du groupe.
Dans un autre registre ça rappelle aussi la notion de lead dans ce que Kniberg décrit comme Scrum de Scrum.
Bref, en 2017 chez Malt nous avions des “leads”, non explicites et qui n’étaient pas des managers de personnes.
A partir de 2018 nous allons doubler de taille, comme chaque année en fait, et des questions vont commencer à se poser au sein de l’équipe.
Certains se demandent s’ils sont légitimes à donner des conseils par rapport à d’autres qui leur semblent meilleurs ou avec qui ils ne travaillent pas tous les jours. Il est difficile au delà d’une certaine taille d’équipe de trouver sa place et on se retrouve très souvent confronté au syndrome de l’imposteur.
Les nouveaux arrivants ont besoin de comprendre plus rapidement qui peut les guider. Ils doivent découvrir d’eux-mêmes qui sont les leads qui jusqu’à alors ne sont pas explicites.
Et cela ne se résume pas à l’équipe produit, cette équipe vit au milieu de plein d’autres équipes qui ont également besoin de savoir qui sont les « représentants » qui peuvent les aider sur tel ou tel sujet.
Également, émerge un besoin de comprendre comment progresser dans le groupe, comment s’améliorer individuellement. Et plus un groupe grandit, plus émerge aussi le besoin d’être reconnu dans sa progression.
(On est presque dans le domaine de la gamification vous remarquerez)
Enfin, dernier sujet, dans une période de nombreux recrutements, nous avions besoin, au delà du simple instinct, de définir ce que nous attendions d’un(e) candidat(e). Qu’est ce qu’un(e) senior ? un(e) intermédiaire ? un(e) lead ? quelles sont les compétences et valeurs que nous devons trouver chez lui/elle ?
Début 2018, avec de nombreuses questions en tête en plus de celles-ci, je vais avoir la chance de rencontrer plusieurs personnes à San Francisco dans de nombreuses boîtes : Square, Dropbox, Box, Amazon, Facebook mais aussi en France chez Dashlane. Complété avec des lectures sur les modèles de Spotify ou Criteo nous ferons ressortir quelques notions pour mieux définir notre structure de groupe.
Pourquoi s’inspirer de ces sociétés ? Parce qu’elles sont bien plus grandes, qu’elles sont passées par les mêmes étapes et qu’il en est ressorti quelques consensus qu’il serait bête d’ignorer.
Je vous propose de vous présenter ces grands principes que nous avons adopté.
Au sein de Malt nous avons défini différents niveaux de séniorité qui dépend de votre impact et votre expertise, et pas de votre expérience ou âge.
Les niveaux sont :
Attention ici je ne parle pas de structure d’équipe, de tribus, de guilde, de feature team ou de rôle. Il s’agit d’une grille de lecture individuelle.
En terme de progression il est attendu que chacun grandisse de Junior à Senior. La progression allant moins vite avec les années. Il est plus rapide de passer de Junior à Confirmé que de Confirmé à Senior.
A partir de Senior il est totalement acceptable de rester Senior. Etre Senior et avoir un impact très fort au sein de l’équipe produit est une grande réussite en soi.
Pour chaque niveau de séniorité il est attendu de chacun un niveau d’impact différent au sein de la société :
– au début (junior), le premier impact recherché est individuel, vous cherchez à vous améliorer
– une fois votre expertise confirmé (intermediate), votre impact grandit au sein de votre équipe (feature team)
– avec l’expérience (senior), vous avez un impact sur votre tribu (R&D, Product, Ops etc…)
– quelques personnes (leads) sont capable d’avoir un impact sur la société toute entière de par leurs initiatives et actions
Point très important, chez Malt vos réalisations sont toutes aussi importantes que votre façon d’être.
Comme je l’indiquais plus haut, en progressant en terme de séniorité les attentes changent.
Ces attentes tournent autant autour de l’expertise technique que du savoir être (les fameuses softs skills).
Nous avons défini 5 valeurs importantes au sein de Malt.
(Elles sont exprimées en anglais car la communication au sein de Malt se fait en Anglais avec des équipes sur 3 pays)
– Les Core Skills : elles dépendent du métier, c’est votre expertise
– Autonomy : la capacité à s’approprier ces sujets et faire les choses, se sentir responsable de son travail, du succès de la société. Elle n’est possible qu’avec la plus grande transparence possible car on ne peut être autonome qu’en ayant toutes les informations nécessaires pour prendre des décisions
– Joy and Care : La capacité à travailler ensemble, la bienveillance vis à vis des autres membres pour les aider à progresser. C’est pour tout le monde le devoir de créer un environnement agréable pour tous.
– Ambition : Avoir toujours en tête de s’améliorer, de viser plus haut. C’est s’adapter constamment pour faire mieux.
Bon et maintenant c’est le moment de faire le lien avec le principe de Peter que j’évoquais plus haut.
Ce qui nous a paru important c’est de matérialiser le fait que la progression chez Malt devait aussi être possible via l’expertise technique/métier.
Nous avons repris le concept de “Double ladder” pour illustrer les deux montants d’une échelle.
Chaque individu peut choisir de progresser sur son expertise, sa contribution individuelle (Individual Contributor) ou en choisissant le chemin du management.
Le management est un choix, pas une obligation d’évolution.
Un contributeur individuel se concentre sur son expertise. Un manager se concentre sur sa capacité à aider la structure et les individus à grandir ensemble.
Attention à ne pas tomber dans la caricature, les deux chemins ne sont pas antagonistes et plus on gagne d’expertise plus la communication aussi devient importante. On attend d’un senior qu’il soit un mentor, qu’il communique son expertise, qu’il contribue au succès collectif, même s’il a choisi la voie de la contribution individuelle.
Vous pouvez consulter ce que cela donne dans un fichier excel reprenant les niveaux de séniorité et les attentes :
https://docs.google.com/spreadsheets/d/1P5eflLuY6_KEYXA14TZvCrGCK9E04qSp8Vrv8Ai7a6g/edit?usp=sharing
Si vous souhaitez creuser le sujet, je vous propose ces articles en référence.
https://labs.spotify.com/2016/02/15/spotify-technology-career-steps/
http://labs.criteo.com/2015/06/criteo-engineering-career-tracks-and-leveling/
https://blog.alan.eu/how-we-are-building-a-first-class-engineering-team-at-alan-4163e578fe43
http://dresscode.renttherunway.com/blog/ladder
https://blog.alan.eu/manager-nest-pas-le-futur-de-l-ing%C3%A9nieur-ff66e06f487c
https://www.linkedin.com/pulse/et-si-se-penchait-sur-les-carri%C3%A8res-produit-fabrice-des-mazery/
Petit flashback, on est début 2017, c’est la soirée MiXiT à l’hôtel de ville. Ambiance relax entre petits fours et discussions sur les confs de la journée.
Au détour d’une conversation j’en viens à détailler notre équipe produit et j’ai une petite question un peu provoc en retour. “Vous êtes tout ça pour faire un site web ?”
A l’époque, 9 personnes dans l’équipe produit dont 3 devs backs, 1 dev front.
Et forcément ça va me trotter dans la tête. Certes, on peut faire un site web avec un seul dev, voire même aucun dev en utilisant certains CMS très bien foutus mais est-ce vraiment équivalent ? Est-ce qu’au delà d’une équipe de 1 les autres viennent juste pour pouvoir faire des plus grandes LAN et des tournois d’e-sport ?
Partant de cette question je vais y réfléchir et soumettre le sujet à deux CFP de belles confs françaises pour y apporter une réponse un peu plus détaillée mais le sujet ne retiendra pas l’attention. Bref ce n’est que partie remise, bloguons dans ce cas 🙂
Bon mais qu’est ce que vous allez en tirer dans votre travail de tous les jours ?
Ce ne sera pas un billet de blog tech, donc rien de ce point de vue là.
Vous allez peut-être gagner un autre point de vue sur certains lieux communs de l’informatique comme la loi de Pareto, le mythe du fullstack developer, l’expression consacrée « le mieux est l’ennemi du bien ». Si, pour vous, réinventer la roue c’est toujours inutile, que le pragmatisme ça veut juste dire de faire vite et sale, là encore, vous trouverez peut-être un autre éclairage ici.
Très très prochainement va avoir lieu BlendWebMix 2018 à Lyon. Si vous ne connaissez pas c’est une conférence « mixte » entre tech, marketing, design qui se déroule dans un lieu superbe, la cité des congrès entre le parc de la tête d’or et les bords de Saône.
Mais vous allez me dire, « non mais c’est quoi ce titre de billet ! Pourquoi t’écris ca ? C’est pas ton genre ! »
Bon, alors déjà je fais ce que je veux et oui cette fois j’ai envie de parler un peu de Paul et Mickey (*)
Et bon sang oui, en ce moment j’en ai marre du « startup bashing » et j’assume, c’est biaisé comme avis car je bosse dans une « startup ».
Bon alors entendons-nous bien, déjà la grande majorité des personnes ne posent pas la même définition d’une startup. Mais ça, c’est pas nouveau. Ca fait des années que personne n’est capable de se mettre d’accord pour savoir si Uber, Google, Slack, Spotify, BlaBlaCar sont encore des startups.
Chez Malt nous sommes constamment en recrutement et je fais passer des entretiens très très régulièrement. Il y a une chose que je répète à chaque candidat car cela reflète une qualité essentielle que nous recherchons et j’aimerais le partager ici et l’étoffer.
Dans les 2 premières minutes de l’entretien, je rappelle rapidement ce que nous sommes et j’insiste sur un point.
Chaque année Malt a doublé de taille. Chaque année notre environnement de travail, les personnes avec qui nous travaillons, nos rôles ont changé.
Alors évidemment je ne raconte pas toute l’histoire aux candidats. Mais j’aime leur décrire à quel point nous avons beaucoup d’idées, que la boite telle qu’ils ou elles la voient aujourd’hui va encore beaucoup changer. Malt pour une personne qui vient chez nous ce n’est pas une certitude de confort, un train train. C’est être dans une organisation qui évolue constamment. Et pour cela, il y a une qualité importante, être capable de se réinventer, de s’adapter, de se remettre en cause. Oh oui, savoir se remettre en cause.
Et à force d’en parler j’ai eu envie de le partager ici dans ce billet.
Mode dépoussiérage activé, aujourd’hui j’ai envie de réactiver une série de billets que je n’avais jamais publié autour de l’internationalisation.
Ces billets ont été écrits en grande partie il y a 8 ans en 2010 lorsque je démarrais localizeyourapps.com un side project qui visait à simplifier le workflow de traduction en l’intégrant au sein de l’usine logicielle. Trève de bavardage, démarrons.
Vous travaillez sur une application et vous souhaitez la rendre disponible partout dans le monde ? Dans ce cas votre logiciel doit s’adapter aux différentes cultures des personnes qui vont l’utiliser à travers le globe.
Cette adaptation va consister à traduire le logiciel, afficher correctement les chiffres, les dates, parfois les images (si elles contiennent du texte par exemple), la mise en page quand la langue s’affiche de droite à gauche ou de gauche à droite et plein d’autre choses encore…
Tout d’abord avant d’aller plus loin, un petit rappel des termes :
Je ne sais pas vous mais de mon côté, dans chaque job que j’ai pu faire j’ai toujours retrouvé certains éternels débats. Vous avez des sujets qui semblent donner des sueurs froides à quasiment tout le monde dans toutes les sociétés. Je pourrais citer : la documentation (interne ou externe), la stratégie de branches, la façon d’estimer des tâches, les conventions de codages etc… etc… etc…
En tout début de carrière ces sujets sont passionnants (ou pas), en tout cas vous vous y intéressez puisque la majorité relèvent de l’organisation, la méthode de travail et bon, ça parait plutôt une bonne chose d’être bien organisé.
Je vous dévoile un peu la fin du film, au fil du temps, refaire les mêmes débats dans chaque nouvelle équipe vous lasse(ra) un peu. C’est pour cela que bosser sur un produit, qui plus est le sien, pendant plusieurs années est vraiment agréable. Ces sujets ont été taclés et désormais que la tuyauterie est faite on s’occupe de construire des fonctionnalités, chose finalement bien plus agréable. Cela ne veut pas dire qu’on y retouche plus mais le degré de maturité est assez fort pour que chaque changement ne soit pas une révolution mais une amélioration. Toutes les personnes qui enchaînent des projets de durée variant entre 6 mois et 2 ans avec des équipes dont le turnover implique un renouvellement complet tous les 18 mois savent de quoi je parle.
Bref, je tenais donc à partager l’expérience Hopwork sur notre stratégie de branches et où nous en sommes aujourd’hui.
Peut être que vous l’avez déjà lu sur Twitter, Hopwork vient de passer un nouveau cap.
En effet je suis plutôt heureux d’annoncer que nous venons de finir une levée de fonds de 5M d’€ pour financer nos futurs investissements. (*)
