Recrutements et salaires : session de Q&A

Publié le par

J’étais présent en tant qu’intervenant il y a quelques jours à un meetup sur le thème « ce que veulent les devs à l’ère post covid » et j’aimerais revenir sur quelques questions qui ont été posées en session de Q&A.
Déjà pour présenter le contexte, j’ai été invité à participer avec 3 autres participants pour venir parler de ce sujet. Pour ma part c’était lié à l’article que j’avais sorti en début d’année sur « les salaires dans la tech » .

L’évènement étant hébergé dans un incubateur c’est finalement assez logique que l’on retrouve majoritairement des porteurs et porteuses de projets ainsi que des recruteurs et recruteuses dans l’audience.

A la fin de la session il y a eu quelques questions qui ont été posées et que j’aimerais partager sur ce blog.
D’autant que, avec le recul, j’aurais des compléments de réponse à apporter.

Lire la suite →

Se tenir à jour dans une équipe produit

Publié le par

English version : https://medium.com/nerds-malt/stay-up-to-date-in-a-product-team-c1ffa8eca1a0

Aujourd’hui je vais aborder le sujet de l’animation de la connaissance dans une équipe produit car cela fait partie, pour moi, des sujets très importants sur lesquels il faut s’investir.

Et quand je dis qu’il faut investir, je m’adresse autant aux contributeurs individuels qui que vous soyez, qu’aux entreprises. 

Quand je parle d’animation de la connaissance, je pense à différents sujets :

  • la formation des individus
  • le développement de la curiosité personnelle 
  • la diffusion de la connaissance

Je vous propose donc de voir quels sont les différents éléments mis en place dans l’équipe de Malt en 2021 si jamais ça peut vous donner des idées. Et puis peut-être, pourquoi faisons-nous cela si jamais vous vous posez la question.

Lire la suite →

Faut-il mesurer la performance d’une équipe engineering ?

Publié le par

Et si on parlait de mesure de la performance d’une équipe engineering ? 

Le sujet peut sembler épineux car il tire deux sujets majeurs :

  • les instruments de mesures, que faut-il mesurer, comment et pourquoi ?
  • la méthode de management qui se cache derrière

Et le moins que l’on puisse dire, c’est que sur ces deux thèmes, il y a de quoi écrire. 

Les métriques de suivi absurdes ont très longtemps été un running gag dans l’informatique. Et surtout elles auront eu des objectifs très divers parfois très nocifs pour la qualité des projets, de la collaboration ou la gestion des individus. 

Cependant, c’est une source d’infos précieuses et sur laquelle on peut construire les leviers d’amélioration continue de nos pratiques. 

Bref, je vous propose un petit panorama sur le sujet avec en pointillé la philosophie que nous essayons de mettre en place chez Malt autour de la Developer Experience.

Lire la suite →

Différences entre VP Engineering et CTO

Publié le par

Si le rôle de VP Engineering est relativement courant dans les entreprises anglo-saxonnes, cette dénomination est assez jeune en France et peut-être que vous n’en avez pas encore côtoyé. 

Je souhaitais faire un billet sur ce rôle parfois méconnu, incompris, ou juste confondu avec le poste de CTO. 

Et pour cela, je souhaitais décrire la façon dont ce rôle a été introduit dans l’équipe engineering de Malt. 

En faisant cela, cela permettra de répondre à quelques questions que je me suis moi-même posé lorsque nous avons cherché notre VP Engineering :

  • A partir de quelle taille d’équipe faudrait-il avoir un VP Eng ? 
  • Quel est le profil type d’un VP Eng ?
  • Dans quelle mesure son rôle et le mien se recoupe et comment cohabiter ?

En espérant que mon expérience dans une startup de 0 à 250 employés puisse servir à d’autres.

Lire la suite →

Les salaires dans la tech

Publié le par

Parlons d’un sujet qui fait couler beaucoup d’encre, les salaires.

Le sujet est passionnant car le marché a énormément changé en une dizaine d’années. 

S’il pouvait exister une sorte de plafond de verre autour de 50/55k il y a encore 10 ans, désormais on voit des salaires au-dessus des 100k en France.

Cependant cette réalité ne doit pas en cacher une autre, c’est que cela reste très rare et je lis pas mal d’idées reçues sur le sujet. 

Je vous propose donc de faire le tour de la question. On va aussi pouvoir discuter de l’influence du lieu, de l’équilibre entre pro et perso ou de l’évolution de l’écosystème tech en Europe. 

Vous trouverez plus bas un fichier excel avec quelques informations utiles sur les salaires par type d’entreprises.

Lire la suite →

Senior avec 6 ans d’expérience, et après ?

Publié le par

Le sujet récurrent dans l’IT : si on est senior après 6 ans d’expérience, quel est l’avenir du développeur(euse) passé 10 ans ? 

Les vieux et vieilles développeurs(euses) sont-ils voué(e)s à partir élever des chèvres dans l’Ardèche ou pire, deviennent-ils tous manager ? 

S’il est vrai que la voie vers le management reste dans beaucoup d’entreprises la voie privilégiée, il y a d’autres modèles aujourd’hui. 

Ce billet sera fait en deux parties assez distinctes. 

Dans un premier temps je vous propose de parler des rôles de Staff Engineer, Principal Engineer, Fellow, Distinguished, de la notion d’impact et de fameuse question, faut-il devenir manager pour progresser ? 

Ensuite j’aimerais aller au-delà de ça. Je souhaite aborder comment un(e) Software Engineer peut apporter beaucoup d’impact. Ce sera directement illustré via ce que nous faisons chez Malt.

Lire la suite →

Pourquoi le sujet n’est plus d’adopter l’agilité mais de changer de culture produit

Publié le par

tldr;

J’ai récemment eu à remplir un questionnaire sur nos méthodes de gestion de projet chez Malt. 

Je me suis retrouvé à être agacé bêtement par les questions, questions dont la philosophie me semblait dater d’un autre âge. 

Le but était de savoir si nous étions bien agiles, et pour le savoir, chaque question portait sur une pratique spécifique des méthodes Scrum et Kanban.

La question aujourd’hui n’est plus de savoir si on est agile ou non, terme très largement dévoyé partout.

L’agilité est clamé partout mais se cantonne pourtant bien souvent au cycle de dev (le delivery) laissant le reste de l’entreprise dans un fonctionnement plus archaïque. 

Il faut aller plus loin désormais, l’Agile est censé avoir été compris (et surexploité). Il est temps de véritablement parler de comment on réalise le produit depuis les phases de discovery (l’idéation) jusqu’au delivery. Et il faut sortir de la logique des roadmaps inflexibles anti agiles pour aller vers des stratégies par objectifs et résultats clés (OKR), le tout avec un alignement complet de la société.

Lire la suite →

CTO de startup à scaleup

Publié le par

Il y a un moment que je pensais faire un billet sur le rôle d’un CTO dans une startup. Cependant je me disais toujours que ce n’était pas intéressant, qu’il faudrait en parler quand la boîte serait bien plus grande, quand nous serions une licorne etc…

.

Et c’est ainsi que j’ai fait patienter ce billet pendant des mois, puis des années… 

Lire la suite →

Les parallèles entre le dessin et le développement

Publié le par

J’ai pas mal tourné autour du pot pour faire ce billet qui s’éloigne, un peu, de ce que je fais habituellement.
Il se trouve que j’ai un hobby en plus de mon métier, heureusement me direz-vous, il s’agit du dessin.
J’entends souvent que le dessin c’est réservé aux personnes qui ont du talent, que c’est inné etc… J’ai la conviction que, comme les capacités à concevoir et implémenter des systèmes, tout est lié à la pratique et à l’acquisition de certains fondamentaux.
Le dessin ça s’apprend. Il y a des techniques à assimiler et il faut exercer son œil et sa main pour se les approprier.
Je vous propose ici de faire quelques parallèles entre le dessin et le développement informatique. C’est parti 🙂

Lire la suite →

les métiers de l’ingénierie informatique vont-ils disparaitre ?

Publié le par

Ok le titre est un peu putaclick 🙂
Mais je ne lance pas ce sujet par hasard.
J’ai lu récemment plusieurs très bons articles sur ce thème
Je fais partie d’une espèce en voie d’extinction
Au secours le métier d’ops va disparaitre
et celui que j’ai sans doute préféré : l’alignement de l’esprit importe plus que celui du code

Or c’est un sujet qui me parle car je suis arrivé sur le marché au même moment que l’approche MDA (2001)
Cette approche faisait le buzz à ce moment là, enfin pour autant que ce soit possible sans réseaux sociaux, blogs etc…
Pour simplifier, cette méthode avait pour objectif de modéliser entièrement des applications à base de schémas UML, schémas qui permettent ensuite de générer le code de l’application.
Sur le papier, c’était convaincant pour un jeune diplômé et j’avais été tenté de regarder en détail à l’époque.
Mais les outils donnés et leurs limitations n’ont jamais permis à cette approche de décoller.

Lire la suite →