La gaffe classique du technologue | DSI

Les types d’ingénieurs comme les développeurs de logiciels sont inspirés par le sens des possibilités inhérentes à la construction de choses. Cette inspiration les conduit pour toujours dans une bévue classique qui offre des difficultés et des regrets – et une opportunité d’apprendre une leçon puissante.

Fait intéressant, ce problème n’est pas technique, mais plutôt un état d’esprit.

La bévue

Cette erreur peut être la plus grande source d’échec et de déception dans le travail des ingénieurs en logiciel et d’autres types techniques. Il n’y a pas longtemps, j’ai revu le film classique, Le pont sur la rivière Kwaï et a été étonné de voir l’erreur mentale commise par nul autre que l’acteur d’Obi Wan Kenobi, Alec Guinness. En l’honneur de cela, j’ai commencé à le considérer comme le problème du pont sur la rivière Kwai.

L’erreur en question est la tendance à entreprendre des efforts technologiques sans leur propre contexte, leur permettant de devenir des fins en soi.

Cette propension apparemment anodine est affreusement pernicieuse. Comme vous le verrez dans un instant, il est répété sans relâche par des fondateurs à succès, qui ont appris la leçon à travers une expérience douloureuse.

Si vous pouvez apprendre à repérer ce qui se passe en vous-même ou chez les autres, vous pouvez l’éviter et vous épargner beaucoup de souffrance. Peut-être. Peut-être que si vous êtes un type de codage pur et dur, c’est une chose que vous devez vraiment traverser pour apprendre.

Si vous vous retrouvez à la fin de cette expérience, déplorant le temps et les efforts perdus, soyez réconforté : vous êtes en très bonne compagnie. Vous avez acquis beaucoup de compétences. Vous avez maîtrisé la leçon principale : faites toujours attention à l’utilisateur final.

Même si vous connaissez déjà le problème, il est toujours utile de s’en souvenir.

Steve Jobs est tombé dans le panneau

Juste au cas où vous pensez que j’exagère le genre de personnes qui sont la proie de cette bévue, voici Steve Jobs parler de le faire lui-même. Il dit : « il faut commencer par l’expérience client et remonter jusqu’à la technologie…. Vous ne pouvez pas commencer par la technologie et essayer de déterminer où vous allez essayer de la vendre. Et j’ai fait cette erreur probablement plus que n’importe qui d’autre dans cette salle. Et j’ai le tissu cicatriciel pour le prouver.

Tissu cicatriciel. C’est assez graphique.

Je peux facilement comprendre les blessures. J’ai été la proie de la bévue de la rivière Kwai de manière petite et grande. Je suis parti en tant que codeur trop loin des besoins de l’entreprise sur certains projets, atteignant une excellence technologique qui n’a pas fait grand-chose pour valider son coût.

J’ai erré loin dans le désert en tant qu’entrepreneur avec une idée, pour finalement m’arrêter, regarder autour de moi et me demander : où suis-je ? Comment faire tant de bon travail technique peut-il conduire à des résultats aussi décevants ?

Une fois que vous êtes captivé par les possibilités inhérentes à une idée et que vous commencez à sentir l’écart se resserrer sur la capacité de la réaliser, il est facile de s’asseoir et de commencer à la concrétiser.

Il n’y a rien d’intrinsèquement mauvais là-bas… pour le moment. Il est bon et juste d’agir immédiatement sur l’inspiration. L’un des plus grands penseurs du succès de tous les temps, Colline Napoléon, souligne l’importance d’agir : avoir une idée, passer à l’action, continuer d’essayer en fonction de ce qui se passe. C’est la formule de base.

Mais en tant que constructeur de logiciels, vous devez trouver un moyen d’intégrer les commentaires des utilisateurs, des clients humains vivants, dans la troisième phase du cycle. Vous devriez le garder dans votre tête et vous avez probablement besoin d’un partenaire qui peut le faire mieux que vous. Vous devez valider que vous construisez quelque chose dont les gens ont vraiment besoin.

Si vous ne le faites pas, vous commencerez à construire des élaborations qui ne sont pas justifiées. Vous corrigerez les bogues sans importance. Vous ne saurez pas vraiment si votre idée originale était bonne. Peut-être que c’était le cas. C’était probablement le cas, si vous pouviez l’affiner avec quelques commentaires.

Un voyage archétypal

Steve Sewell, fondateur de Builder.io, en une conversation récente que nous avons eue a souligné ce point en offrant des conseils aux dirigeants de startups : « Le principal de mes apprentissages est : être religieusement obsédé par les clients. »

Il a poursuivi en mentionnant le classique de l’entrepreneuriat Démarrage Leandont le principe de base consiste à formaliser la boucle de rétroaction client dans l’essence de l’entreprise.

Cela vaut la peine d’approfondir l’histoire de Steve. C’est illustratif, archétypal vraiment.

« J’ai quitté mon emploi et j’ai commencé à travailler sur [the project]…. J’y ai mis une année entière et j’avais construit différentes versions…. J’ai pris ma tête en décembre et j’ai commencé à la montrer à des clients potentiels… J’ai réalisé en 10 minutes environ que j’avais raté la cible de plusieurs manières énormes… les décisions fondamentales que j’avais prises si tôt n’allaient pas fonctionner… cela allait être un non-starter… ils n’allaient pas adopter le produit. Ce n’est pas ce dont ils ont besoin.

J’ai entendu ce que Steve disait et j’ai pensé : ouais. Un tamisé, sachant ouais.

« J’étais tellement déçu et je n’avais qu’une autre année de piste… une seule chance de plus de ne pas faire cette erreur… J’ai décidé que je faisais cela fondamentalement différemment. Je vais faire la moindre chose pour le mettre entre les mains de quelqu’un, et je ne ferai rien jusqu’à ce qu’il me dise qu’il en a besoin.

Et j’ai pensé « OUI ! » Il y a la renaissance et la rédemption du fondateur.

Vous pouvez voir les grandes lignes de l’ensemble du processus se dérouler ici : j’ai eu une idée, je me suis excité, je me suis mis au travail, j’ai oublié de valider, j’ai été brûlé.

Pourquoi les ingénieurs font-ils cela ?

La réalité est que si vous êtes un codeur, vous aimez probablement tout simplement coder. Vous associez le plaisir à affronter d’imposants défis techniques et à les surmonter. C’est un peu une dépendance, vraiment. (Cette addiction est à l’origine d’autres problèmes : je te regarde, équilibre travail/vie privée).

Cela ne veut pas dire que la capacité de se concentrer, et de se concentrer intensément, avec une sorte d’attention d’exclusion n’est parfois pas utile. Il est. Surtout en travaillant à travers des ronces techniques épineuses, nous avons parfois besoin de cette superpuissance, c’est vraiment le seul moyen de s’en sortir. Mais nous devons garder ce travail attelé au contexte et à l’objectif plus larges. Nous devons nous assurer à plusieurs reprises que nous nous dirigeons vers le sommet, pas vers le précipice.

Faire du hors-piste peut apporter des compétences et une expérience précieuses, y compris, notamment, comment l’éviter à l’avenir.

Reconstruire à partir de l’expérience

Guillermo Rauch, fondateur de Vercel, fait écho à l’importance de rester sur la cible quand il dit « nous avons toujours été très concentrés sur l’expérience client. Nous avons construit à rebours à partir de l’expérience idéale que nous savions que les développeurs voulaient.

En tant que fondateur en série, nous pouvons imaginer que Guillermo a fait travailler cette leçon profondément dans son ADN entrepreneurial. Il met en évidence la expérience client en tant qu’élément clé, et je vais dire avec confiance que cette orientation est l’un des principaux moteurs du succès rapide de Vercel.

En tant qu’ingénieur, écoutez maintenant ceci : il peut être tout aussi amusant de construire quelque chose que les gens utilisent vraiment qu’un projet purement technique. Et cela gardera les VM en ligne pendant que vous le faites !

Vraiment, vous voulez que les gens utilisent ce que vous construisez. Les utilisateurs ne sont pas seulement une distraction frustrante. Vous devez trouver un moyen de les intégrer dans votre bulle de fascination technique. Ne soyez pas Hendrix dans un sous-sol qui ne joue jamais. Mettez le feu à votre guitare à Monterey.

Retour au pont

Alerte spoil: Dans le film Le Pont sur la rivière Kwai, un groupe de soldats britanniques est capturé par les Japonais pendant l’occupation de la Chine pendant la Seconde Guerre mondiale. Les prisonniers sont chargés de construire un pont pour aider à ravitailler les envahisseurs. L’un de ces prisonniers est un officier nommé Nicholson, joué par Alec Guinness.

Naturellement, l’objectif principal du soldat britannique est de survivre et de résister aux occupants. Ils sont prisonniers de guerre dans un conflit horrible; la construction du pont est un projet qui va à l’encontre de ces efforts.

Malgré cela, le but et la signification conférés par le pont exercent un pouvoir sur Nicholson. Il arrive au point où certains de ses codétenus sont en mesure de saboter le pont, et il agit pour les en empêcher.

Bien sûr, notre fondateur ou ingénieur logiciel typique n’est pas confronté à des circonstances aussi dures et périlleuses. Dans le cas du film, le pont idéal est peut-être celui qui est construit juste assez lentement pour éviter les représailles, jusqu’à l’arrivée des secours. Le pont n’est pas le point; ses exigences sont. C’est un moyen pour une fin, comme toute technologie.

Au dernier moment du film, Nicholson tue son collègue officier britannique et revient soudainement à la raison. Il prononce avec incrédulité: « Qu’ai-je fait? »

Il a été la proie de l’erreur d’ingénierie la plus classique de tous les temps : faire passer l’ingénierie avant tout.