FAQ sur les ingénieurs habilités


Dans mon dernier article, j’ai parlé du concept d’un ingénieur autonome, que je considère comme le concept le plus important pour les entreprises qui souhaitent passer des équipes techniques aux équipes produits.

Dans l’ensemble, mon sentiment était que la plupart des gens comprenaient les points, et beaucoup m’ont dit qu’ils pouvaient personnellement s’identifier car ils avaient vu de première main la puissance d’un ingénieur habilité.

Cependant, j’ai eu plusieurs questions, et le sujet a suscité des conversations sur les réseaux sociaux, et certaines des questions et opinions sont franchement dérangeantes. Alors, j’ai pensé qu’il serait bon de mettre ces pensées sur la table et de les confronter de front.

La raison pour laquelle cela est important est que je pense que certaines de ces opinions sont au cœur des raisons pour lesquelles la gestion des produits a une si mauvaise réputation dans tant d’entreprises.

Plus généralement, de nombreuses personnes au fil des ans ont exprimé leur frustration et leur confusion quant aux raisons pour lesquelles tant de sociétés de produits solides ont besoin (ou du moins préfèrent très fortement) des candidats chefs de produit ayant une formation en technologie. Je pense que ce dialogue aide à expliquer pourquoi ces entreprises sont si attachées à un diplôme en technologie.

«Mes ingénieurs ne s’intéressent à rien d’autre qu’au codage.»

C’est de loin l’excuse la plus courante des personnes qui ne croient pas aux ingénieurs autonomes. Je l’ai entendu d’innombrables fois, surtout lorsque je demande à un chef de produit ou à un concepteur de produit pourquoi ses ingénieurs ne participent pas au travail de découverte de produit.

La première chose que je dois reconnaître, c’est que c’est parfois vrai, et je reviendrai sur cette situation plus tard. Mais d’après mon expérience, c’est l’exception.

Chaque fois que j’entends cela, j’insiste pour parler directement aux ingénieurs. Bien plus souvent qu’autrement, ce n’est pas du tout ce que disent les ingénieurs. En fait, la plainte la plus courante que j’entends des ingénieurs est qu’ils ne sont pas inclus avant qu’il ne soit trop tard, et qu’ils sont obligés de faire face aux conséquences.

Ce qui se passe généralement, c’est que le chef de produit ne veut pas que les ingénieurs soient inclus, car il préfère que les ingénieurs passent leur temps à coder. Donc, dans ce cas, le problème est un chef de produit trop zélé, soit entendant ce qu’il veut entendre, soit ne se souciant pas assez pour même demander.

Cependant, parfois, les ingénieurs me disent qu’ils ne se soucient pas vraiment de la découverte – ils préfèrent coder et construisent bien «peu importe». Dans ce cas, je demande la dernière fois que l’un des ingénieurs a pu rendre visite personnellement à un client? Et la réponse se situe généralement entre il y a très longtemps et jamais.

Mais comme je l’ai dit plus haut, parfois même pas un seul des ingénieurs n’a envie de faire autre chose que du code. Dans ce cas, ma discussion se déplace vers le CTO / VP Engineering, et j’explique qu’ils ont des mercenaires et non des missionnaires, et pourquoi ils ont besoin de relever la barre sur l’embauche d’ingénieurs. Au minimum, ils ont besoin d’au moins un véritable responsable technique dans chaque équipe produit, et la découverte est l’une des grandes responsabilités du responsable technique.

«Si je donne à mes ingénieurs ce type de pouvoir, tout ce qu’ils voudront, c’est sur-concevoir et jouer avec les nouvelles technologies.»

Si cela est vrai (et pas seulement une autre raison de garder les ingénieurs concentrés sur le codage), alors cela décrit un ingénieur habilité mais sans motivation ni concentration.

Un ingénieur habilité dépend de sa compréhension viscérale de la douleur du client. Les ingénieurs forts n’aiment pas voir des clients en difficulté ou mécontents. Ils le prennent personnellement.

C’est pourquoi il est si puissant d’amener les ingénieurs à voir directement les clients. On devrait leur montrer le bon, le mauvais et le laid.

«Nos meilleurs ingénieurs veulent uniquement travailler sur ce qu’ils considèrent comme des problèmes techniques difficiles.»

C’est peut-être le même problème que ci-dessus, ou il se peut que ces ingénieurs forts fassent exactement ce qu’il faut parce qu’ils sont des ingénieurs habilités et qu’ils comprennent le métier. Par exemple, la tolérance aux pannes et la disponibilité du site sont des problèmes techniques très difficiles, mais ce sont principalement des problèmes commerciaux et clients. Idem avec les initiatives sans temps d’arrêt. Idem avec la livraison continue. Il en va de même pour la gestion de l’échelle pendant les périodes de croissance rapide.

«Mes ingénieurs n’ont aucune idée de nos clients.»

Comme je l’ai dit ci-dessus, cela peut être vrai, mais si c’est le cas, c’est carrément la faute du chef de produit et doit être corrigé immédiatement.

«J’ai suivi un cours de programmation à l’université. Je peux assumer ce rôle afin que mes ingénieurs puissent se concentrer sur la livraison. »

Vous pensez peut-être que personne ne serait vraiment arrogant ou assez ignorant pour penser ou dire cela, mais plusieurs personnes l’ont fait. Je ne sais pas trop quoi faire des gens qui pensent comme ça, à part faire de mon mieux pour ne pas les embaucher.

«Si c’est ce que mes ingénieurs sont censés faire, quel est mon rôle?»

C’est un sentiment remarquablement commun, en particulier de la part des PM des équipes techniques. Le concept d’ingénieur habilité est tellement loin de leur réalité actuelle qu’ils ont du mal à se concentrer sur ce concept. En effet, cela met en évidence la nécessité d’un type de chef de produit très différent. Je montre à ces gens la différence entre équipes techniques et équipes produit.

«Bien sûr, je suis d’accord avec les ingénieurs habilités. En tant que chef de produit, mon travail consiste à définir clairement le problème à résoudre, et la mesure du succès, puis à m’écarter. »

J’ai vu cette opinion flotter en marge pendant des années. Mais j’espère que tout le monde peut voir à quel point c’est ridicule. En fait, si vous avez un la stratégie de produit, alors cela a déjà été fait pour vous par votre responsable. Et combien de temps faudrait-il à votre responsable pour se rendre compte qu’elle peut déplacer vos effectifs pour trouver un autre ingénieur ou designer et ne rien perdre?

Bien sûr, quelqu’un qui pense vraiment que c’est très probable dans une entreprise qui n’a pas de véritable stratégie produit, et qui est presque certainement un chef de produit de l’équipe technique, ce qui, comme je l’ai dit et cela illustre clairement, est vraiment un chef de projet .

“Pensez-vous qu’il est possible d’être un ingénieur habilité si notre entreprise utilise SAFe?”

Seules quelques personnes m’ont posé cette question. Et je suis presque sûr qu’ils connaissaient déjà la réponse. Je suis désolé mais je ne vois pas comment, car les modèles sont des opposés polaires en termes de rôle des ingénieurs. Mais j’espère que ce concept vous permettra de mieux comprendre pourquoi des processus comme SAFe ne sont pas utilisés dans de véritables entreprises technologiques qui dépendent de l’innovation.

“Cela signifie-t-il que les concepteurs de produits et les chefs de produits ne sont pas importants?”

J’ai du mal à croire que quiconque a lu mes écrits ces dernières années puisse penser cela, mais certains l’ont fait. Comme je l’ai dit au début de The Most Important Thing: “Certainement, je ne dis pas [an empowered engineer is] tout ce qui est nécessaire, car les produits extraordinaires proviennent du produit équipes. »

Si vous n’êtes toujours pas convaincu par le concept d’un ingénieur habilité, j’espère qu’au moins un de ces autres articles trouvera un écho chez vous: Customer Inspired; Technologie activée, le rôle de la technologie et des équipes produit habilitées.



Source

  • Partager cet article

Laisser un commentaire