Dernièrement, j'ai continué à réfléchir sur deux sujets qui partagent un thème similaire. Le premier sujet concerne l'infrastructure publique de l'État de Californie et son inefficacité au fil des ans. Le second est l'incapacité des grandes entreprises technologiques à innover et à exécuter plus rapidement que les startups en place. Permettez-moi de vous expliquer pourquoi ces sujets sont liés en vous donnant d'abord deux exemples auxquels réfléchir :

• Infrastructure : Le Golden Gate Bridge a mis environ quatre ans à être construit (1933-1937) et il nous a coûté environ 500 millions de dollars en dollars d'aujourd'hui. En revanche, le SDS ( Suicide Deterrent System ), qui ajoute essentiellement un filet autour du pont, nous prendra cinq ans (2017-2023) et devrait nous coûter environ 217 millions de dollars. Si vous faites un examen des grands projets d'infrastructure en Californie, vous constaterez que pour les projets achevés avant les années 1950, le travail a été effectué plus rapidement, moins cher et avec une qualité supérieure à celle d'aujourd'hui d'au moins 5 fois l'ampleur, même si aujourd'hui nous avons plus de capital, une meilleure technologie, de meilleures matières premières et un nombre absolu plus élevé d'ingénieurs civils et d'architectes.
• Entreprises technologiques : Adobe, malgré toutes ses ressources financières et humaines, se retrouve à devoir racheter un concurrent pour 20 milliards de dollars. Reste à savoir si Adobe a trop payé pour Figma, mais la question la plus intéressante est de savoir pourquoi une entreprise avec 100 fois plus de personnel, 100 fois plus d'expérience dans les outils de conception et 100 fois plus de capital financier n'a pas réussi à gagner ?

De même, si vous jetez un coup d'œil au sein des entreprises, vous constaterez peut-être qu'à mesure qu'elles grandissent, les processus et les ballonnements se glissent dans n'importe quoi et étouffent le vrai travail et l'innovation. Dans cet environnement, les employés les plus désireux de créer des choses, les makers, trouvent qu'il est simplement plus attrayant de quitter le navire pour un endroit plus petit où leur travail a un débouché pour se matérialiser. Les défaillances d'infrastructure et les échecs d'innovation de l'entreprise sont au moins en partie dus au gonflement et à la dérive des processus.

Pourquoi le fluage des processus se produit-il ?

Chaque processus commence par de bonnes intentions.

• "Nous voulons nous assurer que toutes les parties prenantes ont leur mot à dire dans le travail final, de sorte que toutes les propositions de projet soumises doivent être examinées par les équipes juridiques, de conception, de produit et d'ingénierie."
• "Nous voulons nous assurer que les grands projets d'infrastructure ne causent pas de dommages, nous devons donc effectuer des études environnementales approfondies avant de commencer tout travail."
• "Nous voulons minimiser les violations de données, donc toute demande de données doit être effectuée par l'intermédiaire des équipes informatiques et de sécurité."

La voie du perfectionnisme

Je me souviens d'avoir entendu un responsable bien intentionné dire à ses subordonnés directs d'écrire un logiciel comme s'il durerait 100 ans. Bien que la remarque soit hyperbolique, le conseil fait écho à quelque chose que j'ai souvent entendu dans l'industrie de la technologie à travers des adages comme "mesurez deux fois et écrivez une fois" ou "si vous n'avez pas le temps de le faire correctement, avez-vous le temps de faire ça deux fois ? » Ce n'est pas un mauvais conseil. Dans certaines situations, vous devez écrire du code comme s'il durerait 100 ans, et se lancer tête première dans l'exécution sans planification est un gaspillage. Néanmoins, l'accent mis sur la planification peut conduire à la paralysie et à la non-reconnaissance des avantages de l'apprentissage par itération. Je préférerais vivre dans un monde où le logiciel est réécrit chaque année parce qu'il est fortement reconnu que la perfection n'existe pas et que la condition préalable à l'évolution est le changement, au lieu d'un monde où les choses fonctionnent sur des " bases de code vieilles de 50 ans ".

Trop de colle

Il y a de nombreuses années, j'ai lu le billet de blog de Tanya Reilly sur le fait d' être Glue (lecture hautement recommandée, d'ailleurs). À ce stade de ma carrière, le contenu a vraiment résonné parce que j'avais affaire à quelques collègues qui, bien que techniquement compétents, ne travaillaient tout simplement pas sur les bonnes choses. Les collaborateurs de Glue s'engagent dans un processus de leadership technique et de mentorat qui conduit à rendre les autres membres de l'équipe plus productifs. Une certaine quantité de colle est nécessaire, néanmoins, j'ai trouvé que trop de colle crée un ensemble d'autres problèmes :

• Les gens qui travaillent avec de la colle empêchent les autres d'améliorer leurs compétences non techniques. Par exemple, un responsable technique qui ne laisse pas son équipe parler de son travail ou agit souvent comme un « tampon » enlève essentiellement aux IC des opportunités de lutter et éventuellement d'améliorer leurs compétences en communication.
• Des versions extrêmes et toxiques du comportement de la colle se manifestent parfois en s'attribuant le mérite du travail d'autres personnes ou en générant une attribution grossièrement exagérée ("par exemple, sans moi agissant comme intermédiaire, le projet ne réussirait pas"). Alors que Tanya parle des situations où les gens de Glue ne sont souvent pas reconnus, mon expérience est complètement à l'opposé. Parce que les gens de Glue sont de bons communicateurs, ils savent comment faire de la publicité pour leur travail et bien faire de la politique. En retour, ils se retrouvent avec une plus grande visibilité et plus d'opportunités de promotion, tandis que l'ingénieur qui travaille sur les détails de la mise en œuvre obtient souvent une reconnaissance symbolique ou aucun crédit du tout.
• Enfin, l'ajout d'un trop grand nombre de collaborateurs réduit l'appropriation et la responsabilité des ingénieurs individuels. Au lieu d'ajouter des personnes de colle pour gérer une équipe techniquement compétente, je laisserais simplement tomber les ingénieurs qui semblent n'avoir aucune intuition commerciale, manquer de compétences en communication ou ne pas pouvoir rédiger un paragraphe décrivant pourquoi le travail qu'ils font a un impact. Suggérer que vous avez besoin de plus de colle pour gérer les ingénieurs finit par rejeter le schéma général selon lequel les gens qui sont techniquement brillants ont également un haut niveau d'intelligence générale, lisent beaucoup, sont des apprenants tout au long de la vie et sont très bons en affaires et pas seulement en code.

Quand j'étais chez Novell, j'avais appris qu'il y avait des gens que j'appelle les « collants ». Les gens de la colle sont des gens incroyablement gentils qui s'assoient aux limites interstitielles entre les groupes et ils aident à l'activité. Et ils sont très, très loyaux, et les gens les aiment, et vous n'avez pas du tout besoin d'eux.

Chez Novell, j'ai continué à essayer de me débarrasser de ces gens de colle, parce qu'ils gênaient, parce qu'ils ralentissaient tout. Et chaque fois que je me débarrassais d'eux dans un groupe, ils se présentaient dans un autre groupe, et ils étaient transférés, et étaient réembauchés et tout ça.

Entropie

Au fur et à mesure que les organisations grandissent, les connaissances institutionnelles, le nombre de parties prenantes, les bases de code et l'entropie augmentent. Une entropie accrue conduit à un gaspillage élevé, à une charge cognitive élevée, à la désorganisation et au chaos.

En tant qu'ingénieurs en logiciel, je pense que nous avons fait un travail de merde dans la gestion de la complexité. Par exemple, pendant des années, nous avons entendu dire que les monolithes sont mauvais car ils génèrent des bases de code gonflées, rendent les déploiements difficiles ou créent des problèmes d'évolutivité. Pourtant, à l'autre extrême, où nous devons opérer dans un monde de microservices, je trouve que pour expédier des choses de base, je dois opérer sur plusieurs bases de code écrites dans différentes langues, chacune ayant ses particularités de déploiement et ses modèles d'architecture, avec l'ensemble paradigme se transformant en spaghetti lambda . S'arrêter et se recentrer sur ce qui est important a un impact important sur la réduction de l'entropie. À un niveau bas, orienté vers l'action, il peut se manifester comme suit :

• Suppression du code mort qui n'est pas exécuté en production. J'ai interagi avec tant de bases de code où> 50% du code était du code mort et créait une charge cognitive pour les collègues. J'aimerais qu'il y ait quelque chose dans l'espace de productivité des développeurs qui génère une couverture de code basée sur les lignes exécutées en production. Chaque trimestre, vous arrêtez et examinez ces rapports et supprimez simplement les fichiers qui n'ont eu aucune exécution.
• En tant que chefs de produit, nous ne réfléchissons pas suffisamment aux fonctionnalités que nous devrions supprimer ou rétablir. Pourtant, s'arrêter et réfléchir à ce qui doit être supprimé peut être très utile pour simplifier et améliorer l'expérience utilisateur. Je me considère comme un féru de technologie, mais je trouve que bon nombre des produits créés aujourd'hui ont été hyper-optimisés sur un ensemble d'utilisateurs existants, ce qui a conduit à une expérience UX encombrée et déroutante pour les nouveaux utilisateurs. Demander à la fin du trimestre "Quelle fonctionnalité pouvons-nous retirer ?" peut être utile pour réduire l'encombrement.

L'ego est l'ennemi

Ryan Holiday suggère dans son livre Ego is the Enemy qu'il y a une forte "tentation qui existe pour tout le monde - pour que la parole et le battage médiatique remplacent l'action". L'ego est une grande raison pour laquelle le progrès et l'innovation peuvent être ternes dans de nombreuses institutions. Voici comment l'ego se manifeste :

• Voir les mêmes personnes impatientes de présenter leurs pensées dans une conversation de groupe, même si leurs idées n'ajoutent aucune valeur marginale ou très peu.
• Avoir des gens qui ne s'engagent jamais à parrainer activement leurs collègues ou qui essaient d'accumuler de la visibilité. Si vous êtes un manager ou un manager de managers, vous pouvez le remarquer en voyant à quelle fréquence votre subalterne direct parle des succès ou des contributions d'autres personnes dans vos entretiens individuels. Le manque de reconnaissance ou le parrainage désintéressé d'autres personnes peut être le signe d'un ego malsain.
• Optimisation pour l'équipe plutôt que pour l'ensemble de l'entreprise ou de l'organisation. J'ai emprunté le schéma du Staff Engineer's Path de Tanya Reilly et il illustre parfaitement ce problème où les équipes optimisent pour le maximum local. Par exemple, accepteriez-vous de dissoudre votre équipe et de redistribuer les employés à d'autres équipes si, dans votre domaine, vous passez en mode maintenance ? La plupart des managers ne feraient jamais cela car cela signifierait perdre tout capital social et politique au sein de l'entreprise.

• Selon votre rôle, il existe une très forte dichotomie en termes de perception de la valeur des réunions. « Les personnes les plus puissantes sont sur l'agenda du manager ». Malheureusement, leur perception de la valeur des réunions crée un dépassement culturel qui affecte les personnes qui préfèrent avoir du temps ininterrompu pour réfléchir à un problème et à une solution. Même à des fins de remue-méninges, les preuves suggèrent que le remue-méninges de groupe est une perte de temps . Pourtant, pourquoi tant d'organisations surchargées finissent-elles par consacrer la moitié du temps des CI à des réunions ?

Conclusion

Le moteur de l'innovation repose sur le changement évolutif. En fin de compte, si une institution devient rigide et ne s'adapte pas au changement, elle mourra lentement. D'après mon expérience, l'introduction d'un processus entraîne souvent des coûts imprévus qui entraînent une vitesse réduite. Au lieu de cela, je me concentrerais sur les éléments suivants :

• Favoriser l'itération et apprendre de ses erreurs au lieu d'essayer d'atteindre le perfectionnisme.
• Les gens de colle sont nécessaires, mais il doit y avoir une limite à leur nombre, afin qu'ils puissent agir avec un fort effet de levier. Le simple fait d'embaucher des personnes qui sont à la fois techniquement compétentes et qui ont une bonne intuition commerciale peut résoudre le besoin de surembaucher pour des rôles de colle.
• Enfin, je me concentrerais sur la réduction de l'entropie en demandant constamment ce qui peut être jeté et en récompensant les gens pour un comportement qui augmente la simplicité.