J'ai comparé mes notes à des personnes qui dirigent des blogs d'ingénierie d'entreprise, et il me semble curieux que mon blog personnel reçoive assez souvent plus de trafic que l'ensemble du blog d'entreprise d'une entreprise qui est estimé à neuf / dix chiffres et mon blog obtient souvent un ordre de grandeur plus trafic.
Je pense que c'est étrange, car les entreprises technologiques de cette classe emploient souvent des centaines voire des milliers d'employés. Dans la grande majorité des cas, ils seront mieux équipés que moi pour écrire un blog engageant, et les entreprises tirent beaucoup plus de valeur d'un blog engageant que moi.
Pour le premier, les employés de l'entreprise feront un travail d'ingénierie plus intéressant, raconteront des histoires plus drôles et auront des connaissances plus approfondies que quiconque avec un blog personnel. Dans le second cas, mon blog m'aide dans ma recherche d'emploi et aide les entreprises à m'embaucher. Mais je n'ai besoin que d'un seul travail, donc le plus gros impact du blog est qu'il me donne au mieux un travail légèrement meilleur, alors que tout le monde sauf une entreprise de technologie pour laquelle j'ai travaillé cherche désespérément à embaucher quelqu'un et perd tout le temps des candidats au profit d'autres entreprises. De plus, je ne suis pas vraiment en concurrence avec les autres candidats lors des entretiens (même si nous passons un entretien pour le même poste, si une entreprise aime plus d'un candidat, cela crée généralement plus d'emplois). Le point crucial de cet article de blog concernant la recherche d'emploi est de savoir si le processus de sélection peut accepter des commentaires non liés à l'entretien ou si j'échoue à l'entretien parce qu'ils font un entretien régulier et que la valeur marginale d'un article de blog supplémentaire est probablement très faible par rapport à cela. D'autre part, lors de l'embauche, les entreprises sont en concurrence relativement directe, il est donc extrêmement important pour elles d'être plus attrayantes qu'une autre entreprise. Dupliquer le Playbook que Cloudflare ou Segment a utilisé pour leurs "marques" d'ingénierie serait un avantage significatif pour l'embauche. Les playbooks ne sont pas un secret : ces entreprises diffusent leurs produits dans le monde entier et sont généralement heureuses de parler de leurs processus de blogs.
Malgré les avantages apparemment évidents d'un « bon » blog d'entreprise en anglais, la plupart des blogs d'entreprise regorgent de documents que les ingénieurs ne veulent pas lire. Des discussions vagues et de haut niveau sur la qualité de tout, le marketing de contenu, des articles étendus sur de nouvelles choses à la mode (aujourd'hui, il pourrait utiliser l'apprentissage en profondeur pour des applications inappropriées ; il y a dix ans, il pourrait utiliser des données volumineuses pour une application inappropriée), etc. .ré.
Pour essayer de comprendre ce que les entreprises ayant un bon blog d'ingénierie d'entreprise ont en commun, j'ai interrogé des personnes de trois entreprises différentes qui ont des blogs d'ingénierie d'entreprise intéressants (Cloudflare, Heap et Segment), ainsi que des personnes de trois entreprises différentes qui ont des entreprises médiocres. blogs d'ingénierie (que je ne nommerai pas).
À un niveau élevé, dans des blogs d'ingénierie intéressants, des processus ont eu lieu qui avaient les propriétés suivantes :
- Processus d'approbation simple, peu d'approbations requises
- Aucune ou aucune approbation non technique requise
- SLO implicite ou explicite pour les approbations
- Le processus d'approbation / édition rend le poste plus attrayant pour les ingénieurs
- Support direct de haut niveau (co-fondateur, niveau C ou niveau VP) pour faciliter le processus de blogging
Dans les blogs technologiques moins attrayants, il y avait des processus qui avaient les propriétés suivantes :
- Processus d'approbation lent
- Beaucoup d'approbations requises
- Approbations non techniques importantes requises :
- Les approbations non techniques suggèrent que les changements sont décevants de l'avis des auteurs
- Les allers-retours peuvent durer des mois
- Le processus d'approbation / révision réduit fondamentalement les risques liés aux publications, supprime les liens vers des informations spécifiques, rend les publications plus vagues et moins engageantes pour les ingénieurs.
- Pratiquement pas de support de haut niveau pour les blogs
- La direction peut convenir que les blogs sont bons dans un sens abstrait, mais pas une priorité suffisamment élevée pour prendre des mesures concrètes.
- ;
- , « » (14 )
- , .
- (, - )
Une personne dans une entreprise avec un blog intéressant a remarqué que l'inconvénient d'avoir un seul approbateur et/ou un approbateur principal est que si cette personne est occupée, cela peut prendre des semaines pour les approbations. C'est vrai, c'est le revers de l'approbation centralisée. Cependant, lorsque nous comparons avec des processus alternatifs, les employés d'une entreprise ont noté que le processus d'approbation typique prend de trois à six mois et que les cas suivants prennent un an.
Alors que quelques semaines peuvent sembler longues pour une personne habituée à une entreprise à croissance rapide, les personnes travaillant dans des entreprises à croissance plus lente aimeraient le processus d'approbation, qui prend deux fois plus de temps.
Voici les processus que j'ai décrits pour les trois entreprises que j'ai interrogées (présentées dans la commande sha512sum, qui est ordonnée au hasard en augmentant la taille de l'entreprise de quelques centaines d'employés à près d'un millier d'employés) :
Tas
- Quelqu'un a une idée pour écrire un article
- L'écrivain (ingénieur) est jumelé à un ami qui édite puis approuve le message
- Buddy est un ingénieur expérimenté dans la rédaction de textes sensés
- Cela peut prendre plusieurs tours ou l'objet du message peut changer.
- CTO lit et approuve
- Ne donnant généralement que des commentaires mineurs
- Peut faire des suggestions telles que « le concepteur peut améliorer ce calendrier ».
- Publier un article
La première étape de l'édition consistait à publier le brouillon sur la chaîne Slack, où « tout le monde » a commenté la publication. C'était une expérience frustrante car « tout le monde » écrivait des commentaires et cela demanderait beaucoup de travail. Ce processus a été conçu pour éviter « trop » de rétroaction.
Segment
- Quelqu'un a une idée pour écrire un article
- Provient souvent de : documentation interne, discussion externe, projet approuvé, outils open source (créés par Segment).
- L'auteur (ingénieur) rédige un brouillon
- Peut-être qu'un ingénieur senior travaillera avec eux pour rédiger un brouillon
- Jusqu'à récemment, le processus de rétroaction n'appartenait à personne.
- Calvin French-Owen (co-fondateur) et Rick (directeur technique) donnent généralement le plus de commentaires <
- Il est également possible d'obtenir des commentaires du gestionnaire et de la direction
- Habituellement, le 3e brouillon est considéré comme terminé
- Vous avez maintenant un éditeur interne qui est responsable de l'édition des articles.
- Egalement discussion avec l'équipe d'ingénierie pour obtenir les retours de 15 à 20 personnes.
- Les relations publiques et les avocats jettent un coup d'œil, processus d'approbation simple
Certains des changements que nous avons apportés incluent
- À un moment donné, lorsqu'il y a eu des tentatives pour créer une "marque d'ingénierie", les postes techniques détaillés ont reçu une haute priorité.
- il y a eu une "retraite de blogs", il a fallu une semaine pour écrire un article
- ajouté l'écriture et la parole comme critères explicites qui seront récompensés lors de l'examen de la performance et de la promotion de l'avancement de carrière
Bien qu'il y ait une approbation et une approbation officielles de la part des relations publiques, Calvin a commenté : « Dans l'ensemble, nous essayons de rendre le processus d'approbation assez facile. Je pense que le plus gros problème avec les blogs est le manque de messages ou de contenu vague de haut niveau qui n'est pas intéressant et n'en révèle pas trop."
Cloudflare
- Quelqu'un a une idée pour écrire un article
- Le blog interne fait partie de la culture, certains articles sont publiés à partir du blog interne
- John Graham-Cumming (CTO) lit chaque message, les autres liront et commenteront
- John approuve les messages
- Matthew Prince (PDG) soutient également généralement les blogs.
- Processus d'approbation juridique "très rapide", SLO en moins d'une heure
- , , ( )
Il convient de noter que cela ne s'applique qu'aux articles de blog techniques. Les annonces de produits sont plus compliquées car elles sont liées à des publicités, des communiqués de presse, etc.
J'ai trouvé intéressant que Marek ait interviewé Cloudflare à cause de leur blog ( son attention a été attirée sur cet article de blog de 2013 sur leurs serveurs de 4ème génération ), et il est maintenant un ingénieur clé pour eux, ainsi que l'une des principales sources d'articles de blog Cloudflare attrayants. Jusqu'à présent, le blog Cloudflare a engendré au moins quelques générations supplémentaires de personnes qui ont interviewé parce qu'elles ont vu un article de blog et qu'elles écrivent maintenant des articles de blog convaincants.
Observations générales
Je trouve que l'état naturel d'un blog d'entreprise où les gens peuvent obtenir un petit retour est un blog assez intéressant. Il y a une pénurie d'écrits techniques réels et profonds qui rendent intéressant tout texte public à moitié décent et honnête sur le travail technique.
Pour qu'un blog soit ennuyeux, une entreprise doit activement empêcher les ingénieurs d'y publier du contenu intéressant. Malheureusement, il semble que l'état naturel des grandes entreprises a tendance à être averse au risque et à empêcher les gens d'écrire juste au cas où cela causerait des problèmes juridiques, de relations publiques ou autres. Les contributeurs individuels peuvent être d'avis qu'il est ridicule d'interdire aux ingénieurs d'écrire des postes techniques à faible risque, tandis que les cadres supérieurs et les vice-présidents font régulièrement des commentaires publics qui se transforment en un désastre pour les relations publiques, mais les IC dans les grandes entreprises n'ont pas de mandat ou ne le font pas. l'impression qu'ils ont le pouvoir de faire quelque chose simplement parce que cela a du sens. Et aucune des quatorze parties prenantes qui devraient s'inscrire pour approuver le processus rationalisén'aurait pas pris la peine d'optimiser le processus, car ce serait bon pour l'entreprise d'une manière qui en fait ne pourrait que les influencer, pas alors que cela semblerait signifier assumer la responsabilité du risque associé au processus optimisé, même avec un peu. Un leader ou un vice-président senior prêt à prendre des risques peut assumer la responsabilité des conséquences, et s'il est intéressé par l'embauche d'ingénieurs ou par le moral, il peut en voir une raison.prêts à prendre des risques peuvent assumer la responsabilité des conséquences, et s'ils sont intéressés par l'embauche d'ingénieurs ou par le moral, ils peuvent y voir une raison.prêts à prendre des risques peuvent assumer la responsabilité des conséquences, et s'ils sont intéressés par l'embauche d'ingénieurs ou par le moral, ils peuvent y voir une raison.
Un commentaire que j'ai souvent entendu de la part de personnes travaillant dans des entreprises plus bureaucratiques est « chaque entreprise de notre taille est la même », mais ce n'est pas vrai. Cloudflare, une entreprise de 6 milliards de dollars avec 1 000 employés, est dans la même catégorie que de nombreuses autres entreprises avec un processus de blogging beaucoup plus lourd. La situation du blog d'entreprise semble être comme une réponse à une interview de la vie réelle. interviewing.io affirme qu'il y a des aspects positifs importants et des aspects négatifs très mineurs à cela.... Certaines entreprises donnent de vrais commentaires, et celles qui ont tendance à penser que cela leur donne un avantage d'embauche facile avec peu d'inconvénients, mais la grande majorité des entreprises ne le font pas, et les gens de ces entreprises prétendront donner des commentaires. impossible, comme vous le ferez. être poursuivi ou l'entreprise sera « annulée », bien que cela ne se produise généralement pas avec les entreprises qui donnent des commentaires, et il existe même des industries entières dans lesquelles il est d'usage de donner des commentaires lors des entretiens. Il est facile de comprendre qu'il existe un certain risque, et très peu de personnes ont le droit de rejeter les messages vagues sur le risque lorsqu'il émane de plusieurs organisations.
Bien qu'il s'agisse d'un petit exemple et qu'il soit dangereux de trop généraliser à partir de petits exemples, l'idée que vous avez besoin d'un soutien de haut niveau pour percer la bureaucratie est cohérente avec ce que j'ai vu dans d'autres domaines où la plupart des grandes entreprises ont du mal créer quelque chose de lumière qui a une valeur évidente mais vague. Bien que cet article soit entièrement consacré aux blogs, j'ai entendu des histoires similaires sur une grande variété de sujets.
Annexe : Exemples d'articles de blog sympas
Voici quelques articles des blogs mentionnés avec un court commentaire expliquant pourquoi je trouve cet article digne. Cette fois dans l'ordre de hachage sha512 inverse.
Cloudflare
- blog.cloudflare.com/how-verizon-and-a-bgp-optimizer-knocked-large-parts-of-the-internet-offline-today
- , ,
- , , , ; , Cloudflare .
- blog.cloudflare.com/the-relative-cost-of-bandwidth-around-the-world
- blog.cloudflare.com/the-story-of-one-latency-spike
- blog.cloudflare.com/when-bloom-filters-dont-bloom
- ,
Segment
- segment.com/blog/when-aws-autoscale-doesn-t
- segment.com/blog/gotchas-from-two-years-of-node
- segment.com/blog/automating-our-infrastructure
- , ; ,
Heap
- heap.io/blog/engineering/basic-performance-analysis-saved-us-millions
- heap.io/blog/engineering/clocksource-aws-ec2-vdso
- HN (malisper, kalmar) , , .
- heap.io/blog/analysis/migrating-to-typescript
- ,
Il convient de noter que tous ces blogs ont des styles différents. Personnellement, je préfère le style de blog Cloudflare, qui a une proportion plus élevée de messages techniques "profonds", mais différentes personnes préféreront des styles différents. Il existe de nombreux styles qui peuvent fonctionner.