Articles

Que font réellement les ingénieurs Staff ?

Le rôle d’un ingénieur Staff-plus dépend beaucoup des besoins de l’équipe et aussi des forces de l’ingénieur particulier. D’après mon expérience, les responsabilités d’un ingénieur Staff-plus peuvent changer au fil du temps, mais généralement leur objectif principal est de travailler sur des projets/efforts qui ont une valeur stratégique pour l’entreprise, tout en conduisant la conception technique et en élevant le niveau de leur équipe. – Diana Pojar

Toute personne qui a été coincée par des proches lors d’une fête et à qui on a demandé d’expliquer ce que font réellement les ingénieurs logiciels sait que l’explication du travail peut être un défi. Avec le temps, vous avez peut-être créé une réponse convaincante pour vos proches, mais l’esprit de beaucoup de gens reste vide lorsque leur collègue se penche vers eux et leur demande :  » Que fait un ingénieur Staff ? « 

La réponse la plus simple est que les ingénieurs Staff continuent à faire une grande partie de ce qui a fait leur succès en tant qu’ingénieurs Senior : établir des relations, écrire des logiciels, coordonner des projets. Cependant, c’est une réponse trompeuse. Ils effectuent les mêmes tâches, mais alors qu’auparavant elles constituaient l’essentiel du travail, elles sont devenues un travail auxiliaire, et ils ont de nouvelles priorités. Leur emploi du temps quotidien varie un peu selon l’archétype, mais il y a une base commune à tous les archétypes : définir et éditer la direction technique, fournir un parrainage et un mentorat, injecter un contexte d’ingénierie dans les décisions organisationnelles, l’exploration et ce que Tanya Reilly appelle être de la colle.

Définir la direction technique

Je me sens le plus impactant lorsque je peux faciliter la définition d’une vision technique pour un domaine et amener les gens à se diriger vers cette vision. Je pense que nous sommes tous d’accord pour dire que nous voulons que notre code soit mieux architecturé qu’il ne l’est ou amélioré d’une manière ou d’une autre. Cependant, j’ai constaté que les gens ont souvent un vague sentiment de vouloir mieux faire sans avoir une idée claire de ce qu’ils veulent. J’aime aider le groupe à se mettre d’accord sur une compréhension commune de l’objectif à atteindre (ce n’est pas grave si nous n’y arrivons jamais) et à établir un plan général pour y parvenir. – Joy Ebertz

De même que le Lorax parle au nom des arbres dans son livre populaire pour enfants, les ingénieurs du personnel parlent au nom de la technologie de leur entreprise. La technologie ne peut pas parler d’elle-même et a besoin de défenseurs efficaces en son nom. Les personnes qui réussissent à faire progresser la technologie sont pragmatiques, réfléchies et se concentrent davantage sur la tendance à long terme du progrès que sur chaque décision individuelle comme une crise décisive. Il peut être utile de considérer cette fonction comme celle d’un gestionnaire de produit à temps partiel pour la technologie.

Certains ingénieurs Staff-plus sont explicitement engagés pour diriger un domaine spécifique tel que la conception d’API, et dans d’autres cas, ils se retrouvent à éditer et à aligner les approches dans un large domaine. Une constante dans tous les rôles est que la réalité de la définition de l’orientation technique consiste beaucoup plus à comprendre et à résoudre les besoins réels de l’organisation autour de vous, et beaucoup moins à donner la priorité à la technologie et aux approches que vous êtes personnellement excité d’apprendre. Dans des rôles antérieurs, vous avez peut-être essayé d’influencer les décisions vers des choix technologiques qui vous motivent, mais dans les rôles supérieurs, vous devez rendre des comptes à l’entreprise et à l’organisation d’abord, et à vous-même ensuite.

Mentorat et parrainage

Dans mon rôle actuel, je me sens énergisé lorsqu’une personne que j’ai parrainée envoie une annonce indiquant qu’elle a expédié son travail, ou lorsque je vois que j’ai contribué à façonner ou à modifier le modèle d’une équipe d’ingénieurs sur un sujet important. Ce sont ces équipes, et non moi, qui font le dur travail quotidien de construction et de support de leur technologie. Je mesure mon impact en fonction de leurs progrès et, plus important encore, de la directionalité de ces progrès et de l’alignement de leur travail sur les objectifs de l’entreprise. – Michelle Bu

Il existe une vision populaire du leadership héroïque qui se centre sur des individus extraordinairement productifs dont les décisions changent l’avenir de leur entreprise. La plupart de ces récits sont intentionnellement conçus par des équipes de relations publiques pour créer une bonne histoire. Vous avez bien plus de chances de changer la trajectoire à long terme de votre entreprise en faisant progresser les ingénieurs qui vous entourent qu’en faisant preuve d’héroïsme personnel. La meilleure façon de faire grandir ceux qui vous entourent est de créer une pratique active du mentorat et du parrainage.

De nombreuses échelles de carrière ont une case à cocher obligatoire autour du mentorat pour se qualifier pour une promotion dans un rôle de personnel, et le mentorat est une partie essentielle du rôle. Partager votre expérience et vos conseils, ainsi qu’une relation continue pour comprendre le contexte du bénéficiaire, est un travail à fort impact. Dans les rôles supérieurs, le mentorat n’est que la barre d’admission, et les ingénieurs du personnel les plus efficaces associent une quantité modérée de mentorat à un parrainage beaucoup plus important : vous mettez votre pouce directement sur l’échelle pour aider à faire progresser et à soutenir ceux qui vous entourent. Si vous ne l’avez pas encore lu, Lara Hogan a écrit l’article canonique sur la distinction entre le parrainage et le mentorat, What does sponsorship look like?

Providing engineering perspective

J’ai un siège à la table lors des discussions d’ingénierie de niveau supérieur qui se produisent à un niveau supérieur aux projets et aux équipes individuels. Nous avons des réunions récurrentes d’ingénierie du personnel où nous discutons des problèmes qui couvrent les équipes et qui sont de nature technique et non technique. – Dan Na

Les organisations efficaces rationalisent la prise de décision de routine. Un bon exemple de ceci est le processus d’examen des contrats pour les entreprises clientes potentielles. Au début, il y aura quelques contrats signés que les équipes de produits et d’ingénierie ne sont pas à l’aise de soutenir. Après que cela se soit produit quelques fois, le processus inclura davantage de parties prenantes dans les étapes de révision, et au fil du temps, les bonnes personnes seront aux bons endroits au bon moment.

Il existe une deuxième catégorie de décisions, celles qui sont à la fois sensibles au temps et importantes, et il est plus difficile de faire venir les bonnes personnes dans la pièce avant que ces décisions ne soient finalisées. Il est fréquent qu’une restructuration organisationnelle se produise sans qu’une contribution précieuse ait été apportée, qui aurait pu changer le résultat. De même, il est fréquent que les boucles d’entretien pour les rôles peu fréquents – ceux pour lesquels vous pouvez embaucher une personne par an, comme les cadres ou les ingénieurs du personnel dans une entreprise en phase de démarrage – n’évaluent pas le candidat sur une dimension importante. Pour certaines entreprises, même des choses comme la planification de la feuille de route entrent dans cette catégorie.

Les ingénieurs Staff-plus sont les personnes qui seront souvent attirées de manière inattendue dans la pièce où ce type de décision se produit. Cela leur donne l’occasion d’injecter un contexte et une perspective d’ingénierie dans une décision alors qu’il est encore possible de changer le résultat. Ces brefs moments de contribution à des décisions critiques ont un impact indéniable et vous permettront de faire entendre le point de vue de l’ingénieur. Ils sont aussi un moment où il est facile d’oublier que votre rôle dans ces moments est souvent de représenter les intérêts de toute l’ingénierie, et pas seulement les vôtres.

Exploration

Dans mon rôle actuel au sein de l’incubateur, je passe toute la journée à prototyper, mais dans mon rôle précédent de responsable technique, je faisais beaucoup de choses différentes. – Ritu Vincent

L’escalade ne peut pas résoudre tous les problèmes, mais elle est si efficace que de nombreuses entreprises luttent pour adopter d’autres approches. Il peut s’agir d’une entreprise axée sur le consommateur qui a du mal à soutenir les contrats d’entreprise, ou d’une entreprise mature qui a du mal à rivaliser avec la cadence de publication d’un concurrent plus petit. Il peut même s’agir d’une entreprise dont l’activité actuelle est si précieuse qu’il est difficile de donner la priorité à de nouvelles activités, même si le taux de croissance de l’activité précieuse est à la traîne.

À long terme, soit les entreprises apprennent à explorer, soit elles disparaissent ; ce n’est pas un défi ignorable. Le simple fait d’affecter une équipe maîtrisant l’escalade de collines à des travaux d’exploration est loin d’être une valeur sûre, aussi de nombreuses entreprises adoptent-elles une approche différente. Elles trouvent quelques personnes de confiance aux compétences étendues, allouent des ressources et reviennent quelques mois plus tard pour voir ce qu’elles ont découvert. L’un de ces ingénieurs est souvent un ingénieur du personnel.

Il ne s’agit pas non plus toujours d’un problème d’entreprise, il peut s’agir de n’importe quel type de problème ambigu et important que les systèmes de l’entreprise sont mal conçus pour résoudre. Il peut s’agir de réduire vos coûts d’infrastructure d’un ordre de grandeur. Il peut s’agir d’identifier une stratégie multirégionale qui prend six mois au lieu de trois ans. Cela pourrait être d’aborder la réalisation soudaine que votre base de données primaire n’a que trois mois d’espace disque restant et que vous ne pouvez pas passer à une taille supérieure (selon mon expérience, un problème étonnamment fréquent chez les startups à croissance rapide).

C’est l’un des travaux les plus gratifiants, et les plus risqués, que font les entreprises, et il faut beaucoup de confiance organisationnelle pour qu’on vous confie ce travail, y compris avoir le respect de l’entreprise que si vous échouez, c’est une réflexion sur le problème et non sur vous.

Being Glue

Tanya Reilly a écrit un merveilleux post, Being Glue, qui capture un autre élément central des ingénieurs du personnel qui réussissent : faire le nécessaire pour identifier le bon travail et le faire expédier. Ce n’est pas glamour, mais les organisations à fort impact ont souvent un ou plusieurs ingénieurs du personnel qui travaillent dans les coulisses pour accélérer le travail le plus important et s’assurer qu’il est terminé.

Mais écrirez-vous toujours des logiciels ?

Il est impoli de terminer toute discussion sur le rôle d’ingénieur du personnel sans opiner sur la première question que les ingénieurs du personnel posent lorsqu’ils se rassemblent dans une pièce : « Trouvez-vous encore le temps d’écrire des logiciels ? » La réponse est, bien sûr, cela dépend !

Ras Kasa Williams a déclaré :  » Je contribuais encore régulièrement au code – certainement moins que le reste des ingénieurs de mon équipe ; mais il était important que je maintienne un travail  » main au clavier  » pour m’assurer que ma stratégie technique (et d’autres décisions de macro-niveau) était informée par les expériences sur le terrain du reste de mon équipe. »

Katie Sylor-Miller a déclaré : « Je suis une architecte frontale, mais la principale chose que j’ai écrite ces derniers temps est de loin SQL, car je fais beaucoup d’analyses de données. J’ai examiné nos mesures de performance pour déterminer où se trouvent les domaines à améliorer et quels seraient les problèmes les plus importants à résoudre pour améliorer les performances et les mesures commerciales. J’écrirai de petits bouts de JS ou de PHP ici et là, mais c’est surtout pour aider à débloquer des équipes ou pour mener de petites expériences liées aux performances. »

Silvia Botros a déclaré : « Je ne fais plus de codage pour l’entreprise. Je crois que la dernière fois que j’ai dû sortir mon terminal, c’était pour refactoriser mes fichiers point. C’est une décision intentionnelle de mon patron, l’architecte en chef. Il va vérifier avec nous tous les trimestres pour s’assurer que nous n’avons pas contribué à un code qui va en production. »

Joy Ebertz a dit : « Plus vous êtes senior, moins votre travail concerne le code. Bien sûr, contrairement à un gestionnaire de personnes, vous avez toujours une inclinaison très technique et même à travers le principal, vous ferez probablement au moins un peu de codage. Cependant, plus vous montez en grade, plus votre travail consiste à encadrer et à faire grandir les personnes qui vous entourent (et plus largement), à renforcer votre équipe en construisant la marque technologique publique de votre entreprise, à remarquer les grandes tendances techniques qui peuvent être améliorées ou corrigées, à aider à définir la vision technologique de votre équipe ou de l’entreprise et à plaider pour le ressourcement des projets de dette technologique. »

La plupart écrivent un peu, certains n’écrivent pas, mais aucun n’écrit autant qu’il le faisait plus tôt dans sa carrière. Il y aura une semaine occasionnelle qui sera purement du codage, mais ce ne sera pas la norme, et si elles se produisent trop souvent, c’est généralement un signe de travailler sur quelque chose de confortable plutôt que d’important.

Lent mais gratifiant

Un thème unifié à travers le travail de Staff-plus est que les délais sont simplement plus longs. Au début de votre carrière, il est facile de s’attacher au cycle de rétroaction rapide du développement de logiciels – écrire, tester, expédier, répéter – et la plupart du travail que vous ferez à ce niveau remplace cette boucle de rétroaction par une boucle qui prend des semaines, des mois et des années.

L’impact et la croissance personnelle vivent dans ces délais plus longs, et bien que tous ceux avec qui j’ai parlé aient souhaité avoir de temps en temps plus de temps pour coder, aucun d’entre eux n’a regretté sa transition vers son rôle actuel.