Clever Geek Handbook

Dan Luu: Bagaimana (beberapa) blog teknik perusahaan yang baik ditulis?

gambar




Saya telah membandingkan catatan saya kepada orang-orang yang menjalankan blog teknik perusahaan, dan tampaknya bagi saya penasaran bahwa blog pribadi saya cukup sering mendapat lebih banyak lalu lintas dari blog perusahaan secara keseluruhan dari sebuah perusahaan yang diperkirakan sembilan / sepuluh angka dan blog saya sering mendapat sebuah urutan besarnya lebih banyak lalu lintas.



Menurut saya ini aneh, karena perusahaan teknologi sekelas ini seringkali mempekerjakan ratusan bahkan ribuan karyawan. Dalam sebagian besar kasus, mereka akan lebih siap untuk menulis blog yang menarik daripada saya, dan perusahaan mendapatkan nilai lebih dari memiliki blog yang menarik daripada saya.



Untuk pertama, karyawan perusahaan akan melakukan pekerjaan teknik yang lebih menarik, menceritakan lebih banyak kisah lucu, dan memiliki pengetahuan yang lebih dalam daripada siapa pun yang memiliki blog pribadi. Dalam kasus kedua, blog saya membantu saya dalam mencari pekerjaan dan membantu perusahaan mempekerjakan saya. Tetapi saya hanya membutuhkan satu pekerjaan, jadi dampak yang lebih besar dari blog adalah memberikan saya pekerjaan yang sedikit lebih baik, sedangkan semua orang kecuali satu perusahaan teknologi tempat saya bekerja sangat ingin mempekerjakan seseorang dan selalu kehilangan kandidat demi kandidat lain. perusahaan. Terlebih lagi, saya tidak benar-benar bersaing dengan kandidat lain dalam wawancara (bahkan jika kami mewawancarai pekerjaan yang sama, jika sebuah perusahaan menyukai lebih dari satu kandidat, biasanya hanya menciptakan lebih banyak pekerjaan). Poin penting dalam posting blog ini mengenai pencarian pekerjaan adalah apakah proses seleksi dapat menerima umpan balik non-wawancara yang signifikan atau jika saya gagal dalam wawancara karena mereka melakukan wawancara biasa dan nilai marjinal dari posting blog tambahan mungkin sangat rendah dibandingkan dengan itu. Di sisi lain, ketika merekrut, perusahaan bersaing secara relatif langsung, jadi menjadi lebih menarik daripada perusahaan lain sangat penting bagi mereka. Menduplikasi Playbook yang digunakan Cloudflare atau Segment untuk "merek" rekayasa mereka akan menjadi keuntungan perekrutan yang signifikan. Playbook bukan rahasia lagi: Perusahaan-perusahaan ini menyiarkan produk mereka ke seluruh dunia dan umumnya dengan senang hati membicarakan proses blogging mereka.



Terlepas dari manfaat yang tampak jelas dari blog korporat yang “baik” dalam bahasa Inggris, kebanyakan blog korporat penuh dengan materi yang tidak ingin dibaca oleh para insinyur. Tidak jelas, obrolan tingkat tinggi tentang betapa hebatnya segala sesuatu, pemasaran konten, posting membentang tentang hal-hal baru yang panas (hari ini bisa menggunakan pembelajaran mendalam untuk aplikasi yang tidak pantas; sepuluh tahun yang lalu bisa menggunakan data besar untuk aplikasi yang tidak pantas), dll. .d.



Untuk mencoba memahami kesamaan apa yang dimiliki perusahaan dengan blog teknik perusahaan yang bagus, saya mewawancarai orang-orang dari tiga perusahaan berbeda yang memiliki blog teknik perusahaan yang menarik (Cloudflare, Heap, dan Segment), serta orang-orang dari tiga perusahaan berbeda yang memiliki blog perusahaan biasa-biasa saja. blog teknik (yang tidak akan saya sebutkan).



Pada tingkat tinggi, di blog teknik yang menarik, terjadi proses yang memiliki sifat-sifat berikut:



  • Proses persetujuan sederhana, tidak perlu banyak persetujuan
  • Tidak ada atau tidak ada persetujuan non-teknik yang diperlukan
  • SLO Cepat Implisit atau Eksplisit untuk Persetujuan
  • Proses persetujuan / pengeditan pada dasarnya membuat posting lebih menarik bagi para insinyur
  • Dukungan langsung tingkat tinggi (co-founder, C-level atau VP-level) untuk memfasilitasi proses blogging


Di blog teknologi yang kurang menarik, ada proses yang memiliki sifat berikut:



  • Proses persetujuan lambat
  • Banyak persetujuan yang diperlukan
  • Diperlukan persetujuan non-teknis yang signifikan:

    • Dukungan non-rekayasa menyarankan perubahan mengecewakan menurut pendapat penulis
    • Bolak-balik bisa tahan berbulan-bulan
  • Proses persetujuan / revisi pada dasarnya mengurangi risiko posting, menghapus tautan ke informasi tertentu, membuat posting lebih kabur dan kurang menarik bagi para insinyur.
  • Hampir tidak ada dukungan tingkat tinggi untuk blogging



    • Manajemen mungkin setuju bahwa blogging itu bagus dalam arti abstrak, tetapi bukan prioritas yang cukup tinggi untuk mengambil tindakan nyata.
    • ;
    • , « » (14 )

    • , .
      • (, - )


Satu orang di perusahaan dengan blog yang menarik memperhatikan bahwa kelemahan dari hanya memiliki satu pemberi persetujuan dan/atau satu pemberi persetujuan utama adalah jika orang tersebut sibuk, diperlukan waktu berminggu-minggu untuk persetujuan. Ini benar, ini adalah sisi lain dari persetujuan terpusat. Namun, ketika kami membandingkan dengan proses alternatif, orang-orang di satu perusahaan mencatat bahwa proses persetujuan biasa memakan waktu tiga sampai enam bulan, dan kasus-kasus berikutnya memakan waktu satu tahun.



Sementara beberapa minggu mungkin tampak seperti waktu yang lama bagi seseorang yang terbiasa dengan perusahaan yang tumbuh cepat, orang-orang di perusahaan yang tumbuh lebih lambat akan menyukai proses persetujuan, yang memakan waktu dua kali lebih lama.



Berikut adalah proses yang saya jelaskan untuk tiga perusahaan yang saya wawancarai (disajikan dalam urutan sha512sum, yang dipesan secara acak dengan meningkatkan ukuran perusahaan dari beberapa ratus karyawan menjadi hampir seribu karyawan):



Tumpukan



  • Ada yang punya ide untuk menulis postingan
  • Penulis (insinyur) dipasangkan dengan seorang teman yang mengedit dan kemudian menyetujui posting

    • Sobat adalah seorang insinyur dengan pengalaman dalam menulis teks yang masuk akal
    • Ini mungkin memerlukan beberapa putaran atau fokus posting dapat berubah.
  • CTO membaca dan menyetujui

    • Biasanya hanya memberikan sedikit umpan balik
    • Dapat membuat saran seperti "perancang dapat meningkatkan jadwal ini."
  • Memublikasikan postingan


Tahap pertama penyuntingan melibatkan pengeposan draf ke saluran Slack, di mana “semua orang” mengomentari kiriman tersebut. Itu adalah pengalaman yang membuat frustrasi karena "semua orang" akan menulis komentar dan itu akan membutuhkan banyak pekerjaan. Proses ini dirancang untuk menghindari umpan balik yang “terlalu banyak”.



Segmen



  • Ada yang punya ide untuk menulis postingan

    • Seringkali berasal dari: dokumentasi internal, diskusi eksternal, proyek yang disetujui, alat sumber terbuka (dibuat oleh Segmen).
  • Penulis (insinyur) menulis draft

    • Mungkin seorang insinyur senior akan bekerja dengan mereka untuk menulis draf
  • Sampai saat ini, proses umpan balik tidak dimiliki oleh siapa pun.

    • Calvin French-Owen (co-founder) dan Rick (manajer teknis) biasanya memberikan feedback paling banyak <
    • Dimungkinkan juga untuk mendapatkan umpan balik dari manajer dan manajemen
    • Biasanya draft ke-3 dianggap selesai
    • Anda sekarang memiliki editor internal yang bertanggung jawab untuk mengedit posting.
  • Juga diskusi dengan tim engineering untuk mendapatkan feedback dari 15-20 orang.
  • PR dan pengacara lihat saja, proses persetujuan sederhana


Beberapa perubahan yang kami lakukan antara lain



  • Pada titik tertentu ketika ada upaya untuk menciptakan "merek teknik", posting teknis terperinci diberi prioritas tinggi.
  • ada "retret blogging", butuh satu minggu untuk menulis posting
  • menambahkan menulis dan berbicara sebagai kriteria eksplisit yang akan dihargai ketika mempertimbangkan kinerja dan mempromosikan kemajuan karir


Meskipun ada endorsement dan persetujuan resmi dari PR, Calvin berkomentar, “Secara keseluruhan, kami mencoba membuat proses endorsement cukup mudah. Saya pikir masalah yang lebih besar dengan blogging adalah kurangnya posting atau konten tingkat tinggi yang tidak menarik dan tidak mengungkapkan terlalu banyak."



Cloudflare



  • Ada yang punya ide untuk menulis postingan

    • Blogging internal adalah bagian dari budaya, beberapa posting diterbitkan dari blog internal
  • John Graham-Cumming (CTO) membaca setiap posting, yang lain akan membaca dan berkomentar

    • John menyetujui postingan tersebut
  • Matthew Prince (CEO) juga umumnya mendukung blogging.
  • Proses persetujuan hukum "sangat cepat", SLO dalam satu jam

    • , , ( )


Perlu dicatat bahwa ini hanya berlaku untuk posting blog teknis. Pengumuman produk lebih rumit karena terkait dengan iklan, siaran pers, dll.



Saya merasa menarik bahwa Marek mewawancarai Cloudflare karena blog mereka ( perhatiannya tertuju pada posting blog 2013 ini di server generasi ke-4 mereka ), dan dia sekarang seorang insinyur kunci untuk mereka, serta salah satu sumber utama posting blog Cloudflare yang menarik. Sejauh ini, blog Cloudflare telah melahirkan setidaknya beberapa generasi lagi orang yang diwawancarai karena mereka melihat posting blog dan sekarang menulis posting blog yang menarik.



Komentar umum



Saya menemukan keadaan alami blog perusahaan di mana orang bisa mendapatkan sedikit umpan balik adalah blog yang cukup menarik. Ada kelangkaan tulisan teknis yang nyata, mendalam, yang membuat teks publik yang setengah-layak, jujur, tentang pekerjaan teknis menjadi menarik.



Agar blog menjadi membosankan, perusahaan harus secara aktif mencegah para insinyur memposting konten menarik di sana. Sayangnya, tampaknya keadaan alami perusahaan besar cenderung menghindari risiko dan mencegah orang menulis untuk berjaga-jaga jika itu menyebabkan masalah hukum, PR, atau masalah lainnya. Kontributor individu mungkin berpendapat bahwa adalah konyol untuk melarang insinyur menulis posting teknis berisiko rendah, sementara eksekutif senior dan VP secara teratur membuat komentar publik yang berubah menjadi bencana PR, tetapi IC di perusahaan besar tidak memiliki mandat atau tidak merasa memiliki wewenang untuk melakukan sesuatu hanya karena itu masuk akal. Dan tidak satu pun dari empat belas pemangku kepentingan yang harus mendaftar untuk mendukung proses yang disederhanakantidak akan repot-repot untuk mengoptimalkan proses, karena akan baik untuk perusahaan dengan cara yang sebenarnya tidak bisa tidak mempengaruhi mereka, tidak ketika itu tampaknya berarti mengambil tanggung jawab atas risiko yang terkait dengan proses yang dioptimalkan, bahkan dengan sedikit. Seorang pemimpin atau wakil presiden senior yang bersedia mengambil risiko dapat mengambil tanggung jawab atas konsekuensinya, dan jika mereka tertarik untuk mempekerjakan insinyur atau moral, mereka dapat melihat alasannya.bersedia mengambil risiko dapat mengambil tanggung jawab atas konsekuensinya, dan jika mereka tertarik untuk mempekerjakan insinyur atau moral, mereka dapat melihat alasannya.bersedia mengambil risiko dapat mengambil tanggung jawab atas konsekuensinya, dan jika mereka tertarik untuk mempekerjakan insinyur atau moral, mereka dapat melihat alasannya.



Satu komentar yang sering saya dengar dari orang-orang di perusahaan yang lebih birokratis adalah "setiap perusahaan ukuran kami sama," tapi itu tidak benar. Cloudflare, perusahaan senilai $6 miliar dengan 1.000 karyawan, berada di kelas yang sama dengan banyak perusahaan lain dengan proses blogging yang jauh lebih rumit. Situasi blog perusahaan tampaknya seperti respons wawancara kehidupan nyata. interviewing.io mengklaim ada aspek positif yang signifikan dan aspek negatif yang sangat kecil.... Beberapa perusahaan memang memberikan umpan balik yang nyata, dan mereka yang cenderung berpikir itu memberi mereka keuntungan perekrutan yang mudah dengan sedikit kerugian, tetapi sebagian besar perusahaan tidak, dan orang-orang di perusahaan tersebut akan mengklaim memberikan umpan balik. digugat atau perusahaan akan "dibatalkan", meskipun hal ini biasanya tidak terjadi pada perusahaan yang memberikan umpan balik, dan bahkan ada seluruh industri yang biasa memberikan umpan balik dalam wawancara. Sangat mudah untuk memahami bahwa ada risiko tertentu, dan sangat sedikit orang yang memiliki hak untuk menolak pesan yang tidak jelas tentang risiko yang berasal dari banyak organisasi.



Meskipun ini adalah contoh kecil dan berbahaya untuk menggeneralisasi terlalu banyak dari contoh kecil, gagasan bahwa Anda memerlukan dukungan tingkat tinggi untuk menerobos birokrasi konsisten dengan apa yang saya lihat di area lain di mana sebagian besar perusahaan besar mengalami kesulitan. menciptakan sesuatu yang ringan yang memiliki nilai yang jelas tetapi tidak jelas. Meskipun posting ini adalah tentang blogging, saya telah mendengar cerita serupa tentang berbagai topik.



Lampiran: Contoh Postingan Blog Keren



Berikut adalah beberapa posting dari blog yang disebutkan dengan komentar singkat tentang mengapa saya menemukan posting ini layak. Kali ini dalam urutan hashing sha512 terbalik.



Cloudflare





Segment





Heap





Perlu dicatat bahwa semua blog ini memiliki gaya yang berbeda. Secara pribadi, saya lebih suka gaya blog Cloudflare, yang memiliki proporsi posting teknis "dalam" yang lebih tinggi, tetapi orang yang berbeda akan memilih gaya yang berbeda. Ada banyak gaya yang bisa bekerja.


More articles:


All Articles