Avertissement : ceci n'est PAS un article sur la complexité. Bien qu'il soit facile de se moquer de la complexité folle de votre application (vous construisez un « mystère » - har har har), ce n'est pas cet article. (Mais qu'en est-il de ceux microservices , n'est-ce pas ?)

Grâce à Malcolm Gladwell , J'ai beaucoup réfléchi ces derniers temps aux mystères et à la façon dont ils modifient notre façon de travailler dans le monde des opérations numériques. Si vous n'avez pas entendu son exposé « L'avenir de l'humanité » - qui est basé sur une papier fantastique par Gregory Treverton, ancien responsable des services de renseignement américains. Je vous recommande vivement de l’écouter.

Même si vous n'avez pas passé les 30 dernières minutes à vous renseigner sur les examens rectaux (vous devriez vraiment revenir en arrière et regarder cette conférence !), voici quelques éléments qui me semblent marquants dans notre contexte d'opérations numériques :

1. Être un résolveur de problèmes efficace signifie comprendre si vous résolvez un problème. puzzle ou un mystère .   Les énigmes nous obligent à rassembler davantage d’informations pour résoudre le problème, tandis que les mystères nous obligent à donner un sens aux vastes informations dont nous disposons déjà.
2. Compte tenu de la quantité d'informations disponibles, pour faire un travail de qualité, nous devons nous comporter davantage comme des analystes que comme des solutionneurs de problèmes. La « bonne » solution n'est pas une question de noir ou de blanc ; elle repose sur l'évaluation des risques relatifs de chaque côté.
3. En tant qu'analystes, les « experts » (ou médecins, dans l'exemple de Gladwell) jouent un rôle beaucoup plus social, en vous écoutant activement et en vous aidant à trouver la meilleure marche à suivre, sans dicter « comment cela doit être » du haut de la montagne.

Prenons un exemple plus concret : vous êtes un développeur qui crée un nouveau service en utilisant la plateforme conçue par votre équipe cloud/SRE. Bien que vous puissiez choisir de recueillir davantage d'informations sur les API, les environnements, l'opérabilité, etc., ce n'est pas un casse-tête. Que vous choisissiez Rails, Scala ou Élixir car votre langage requiert une approche d'analyste pour évaluer les compromis et les risques. Vous pouvez même décider de consulter votre équipe SRE pour obtenir son avis sur les « meilleures pratiques » pour développer et exploiter de nouveaux services, mais permettez-moi d'être clair : Quel que soit votre choix, c'est votre décision et votre responsabilité. Ils peuvent certainement vous aider à comprendre les risques de manière plus viscérale, mais en fin de compte, c'est votre décision (ou votre « appel », har har har).

Le mystère de la conférence

Au cours de mes 4+ années chez PagerDuty, j'ai assisté à de très nombreuses conférences (mais peut-être pas autant que celles-ci). avocats développeurs J’entends sans cesse parler de… Je garde tous mes cordons, presque comme un insigne d’honneur. Il y a plusieurs raisons pour lesquelles j’aime aller à des conférences, mais la principale raison tourne autour de la possibilité de parler directement avec les clients dans un environnement non menaçant.

Lorsque vous recevez des clients après une conférence téléphonique et hors du « confort » de leur bureau, vous obtenez plus souvent la vérité sur leur réalité, sur leurs difficultés, sur ce qui ne fonctionne pas et sur ce qui doit changer. En revanche, de nombreux stands de fournisseurs et sessions auxquels vous pouvez assister sont remplis de fournisseurs et d'intervenants qui « ont tout compris ». Si vous cherchez à résoudre votre casse-tête, voici l'information qui vous manque : ils sont en quelque sorte présents à la conférence pour brosser un tableau idyllique de leur organisation, de leur degré de « DevOps » et de la façon dont ils ont tout compris.

J'ai pu le constater de mes propres yeux il y a quelques années lors d'une conférence DevOps tournée vers l'avenir avec un client intervenant d'un grand détaillant. Après la conférence, j'ai été tellement intrigué par leur succès dans l'adoption de DevOps dans une organisation à grande échelle que j'ai sauté sur l'occasion de leur rendre visite sur place. C'était pour le moins décevant de voir la quantité de discours qui a été donné à cette conférence. Et curieusement, c'est exactement ce que Sarah McLachlan (une légende de la musique canadienne) voulait dire par « Construire un mystère « Nous avons tous des insécurités à cacher, et nous le faisons souvent en mettant une façade… si nous sommes simplement qui nous sommes, c'est généralement la chose la plus attrayante et la plus belle. »

Si je vous rencontre à une conférence, c'est ce que j'attends de vous : de l'authenticité. C'est aussi ce que j'exige de mes dirigeants :

Cette année Sommet PagerDuty est rempli d'apprenants humbles avec lesquels je suis ravi d'interagir :

• Discours liminaires de Patrick Lencioni (membre principal de l'équipe dysfonctionnelle), John Allspaw (facteur humain), Jenn Tejada (la $#!t-perturbatrice de PagerDuty) et plus .
• Et des séances de intervenants clients incroyables qui n'aura pas le droit de faire semblant !

Si vous êtes déjà inscrit au Sommet, je vous mets au défi de participer, d'être social et de profiter au maximum de l'opportunité de vous connecter avec ces experts.

Et si vous hésitez encore à venir ou non, je vous assure que ce n'est pas un casse-tête : je suis heureuse de vous aider à évaluer les risques ! Mais si vous avez besoin d'un peu plus de réconfort, voici quelques chiots :

Embrasse le mystère, et je te verrai à Sommet PagerDuty !