Tech lead
Tech lead memegang arah teknis satu tim: bagaimana pekerjaan akan dibangun, dalam urutan apa, dengan standar seperti apa, dan kompromi mana yang untuk sementara masih bisa diterima. Ini pekerjaan yang tetap hands-on, bukan pekerjaan manajerial, dan ia berjalan di atas kredibilitas alih-alih garis pelaporan. Uraian berikut menjelaskan cakupannya, di mana cakupan itu berhenti, dan bagaimana ia bersinggungan dengan engineering management.
Apa yang dikerjakan seorang tech lead?
Tech lead adalah engineer yang bertanggung jawab atas arah teknis pekerjaan satu tim. Cakupannya meliputi menentukan bagaimana sebuah pekerjaan akan dibangun, meninjau desain sebelum ia berubah menjadi kode, menjaga standar kualitas tetap konsisten di antara semua orang yang berkontribusi, mengurutkan delivery terhadap technical debt yang menumpuk, serta menyingkirkan hambatan yang membuat engineer lain berhenti bergerak. Tech lead umumnya tetap menulis kode dan umumnya tidak memegang tugas line management: gaji, penilaian kinerja dan jenjang karier berada di tempat lain, sementara bentuk dan kelayakan teknis dari apa yang dibangun tim berada di tangannya.
Peran ini ditandai oleh tanggung jawab tanpa komando. Tech lead jarang punya wewenang untuk memerintah siapa pun, sehingga arah harus diperoleh lewat penalaran yang meyakinkan engineer lain dan lewat rekam jejak keputusan yang terbukti bertahan. Orang yang paling kesulitan di posisi ini biasanya adalah mereka yang mengira gelar tersebut akan menyelesaikan perdebatan, sementara yang paling berhasil memperlakukan setiap keputusan sebagai sesuatu yang harus tahan dipertanyakan.
Ketegangan yang selalu ada adalah antara mengerjakan sendiri dan memampukan orang lain mengerjakannya. Satu jam yang dipakai membangun bagian tersulit secara pribadi menghasilkan sesuatu yang pasti; satu jam yang dipakai membedah desain seorang rekan menghasilkan tim yang lebih baik dan tidak menghasilkan apa pun yang terlihat hari ini. Terlalu condong ke keluaran pribadi membuat sang lead menjadi satu-satunya orang yang memahami sistemnya. Terlalu condong ke arah sebaliknya membuat kredibilitas teknis terkikis sampai penalarannya berhenti punya bobot. Menentukan pembagian itu, minggu demi minggu, adalah sebagian besar dari keterampilannya.
Horizonnya pendek dan cakupannya sempit, dan justru itulah intinya. Tech lead bernalar dalam hitungan minggu dan bulan tentang codebase satu tim serta sistem yang dimilikinya, dan itulah yang membuat keputusannya bisa spesifik dan langsung berlaku. Pertanyaan yang melintasi beberapa tim, atau yang mengikat organisasi selama bertahun-tahun, adalah milik peran yang lebih luas â dan mencampuradukkan kedua horizon itu adalah cara paling umum posisi ini didefinisikan secara keliru.
Kapan tim membutuhkan kapabilitas ini
Sebagian besar tim berjalan tanpa pemimpin teknis yang ditunjuk sampai ketiadaannya mulai memunculkan gejala yang khas. Berikut gejala yang biasanya muncul lebih dulu.
Keputusan yang masuk akal secara lokal menghasilkan keseluruhan yang tidak koheren
Setiap engineer memilih dengan wajar, dan tidak ada yang menyambungkan pilihan-pilihan itu, sehingga codebase memperoleh tiga pendekatan untuk satu masalah yang sama. Tidak ada yang tampak keliru di satu review mana pun, dan karena itulah keadaan ini bisa bertahan lama sebelum ada yang menamainya.
Pekerjaan tertahan menunggu pertanyaan yang tidak dimiliki siapa pun
Sebuah tiket berhenti setengah jalan karena pendekatannya diperdebatkan dan tidak ada yang punya posisi untuk menutup perdebatan itu. Biayanya muncul sebagai delivery yang lambat, sementara penyebabnya adalah keputusan yang menggantung tanpa pemilik.
Standar kualitas bergantung pada siapa yang mereview
Dua engineer mengirimkan pekerjaan yang sebanding dan menerima tingkat kecermatan yang tidak sebanding. Standar yang hidup di kepala masing-masing orang, bukan dalam pemahaman bersama, menghasilkan codebase yang kualitasnya bervariasi menurut penulisnya, dan review yang terasa sewenang-wenang bagi yang menerimanya.
Technical debt terus dibicarakan dan tidak pernah dijadwalkan
Semua orang setuju migrasi itu penting dan ia kalah dari pekerjaan fitur di setiap sesi perencanaan. Menimbang remediasi terhadap delivery secara kredibel membutuhkan seseorang yang bisa menghargai kedua sisi dalam satu percakapan yang sama dan mempertahankan hasilnya.
Seorang manajer memegang arah teknis bersamaan dengan urusan orang
Satu orang yang mengerjakan keduanya cenderung mengerjakan separuh yang mendesak. Pertanyaan desain terjawab terlambat atau dengan konteks yang kurang, dan urusan orang terbengkalai di minggu-minggu ketika satu masalah teknis yang berat mengambil alih.
Tim melampaui kapasitas koordinasi informal
Cara yang berjalan ketika dua engineer berbagi satu codebase berhenti berjalan begitu beberapa orang mengubahnya bersamaan. Konflik merge berubah menjadi konflik arsitektural, dan seseorang harus memegang bentuk keseluruhan sistem itu atas nama semua orang.
Kapabilitas inti
Menutup keputusan teknis
Mengumpulkan konteks yang cukup, menimbang pilihan, memutuskan, dan membuat keputusan itu diketahui â termasuk penalarannya dan kondisi yang membuatnya layak ditinjau ulang. Keputusan yang dibiarkan menggantung lebih mahal daripada keputusan yang ternyata salah, karena tim membayar ambiguitasnya setiap hari.
Design review
Membaca sebuah usulan untuk menemukan apa yang tidak disebutkannya: jalur kegagalan, migrasinya, biaya operasionalnya, asumsi tentang volume data yang tidak akan bertahan. Menangkap semua itu sebelum implementasi adalah tempat peran ini memberikan nilai terbesarnya, karena masalah yang sama jauh lebih mahal begitu kodenya ada.
Menjaga standar yang konsisten
Membuat standar kualitas menjadi eksplisit dan menerapkannya secara merata, sehingga engineer bisa memperkirakan apa yang akan lolos. Ini sama banyaknya tentang mengetahui di mana standar itu semestinya berada untuk sebuah pekerjaan tertentu â eksperimen sekali pakai dan jalur pembayaran tidak layak mendapat kecermatan yang sama â seperti tentang menegakkannya.
Memecah pekerjaan dan mengurutkannya
Mengubah kebutuhan yang ambigu menjadi peningkatan yang bisa dibangun, ditinjau dan dirilis secara terpisah, diurutkan sehingga risiko muncul lebih awal dan langkah berikutnya tidak terhalang tebakan di langkah sebelumnya. Pemecahan yang buruk adalah penyebab utama pekerjaan yang mandek sedikit sebelum selesai.
Membuka hambatan
Menyadari bahwa seseorang sudah tersendat sejak Selasa dan tidak akan mengatakannya, lalu menyelesaikannya tanpa mengambil alih pekerjaannya. Ini bagian yang paling tidak terlihat dari peran ini dan sering kali merupakan penggunaan waktu seorang lead dengan hasil tertinggi.
Menyeimbangkan delivery dan technical debt
Menentukan jalan pintas mana yang layak diambil, mencatatnya agar tetap terlihat, dan mengetahui mana yang harus dilunasi sebelum ia berlipat. Pertimbangannya adalah tentang debt mana yang berbunga dan mana yang sekadar berantakan tanpa membahayakan.
Memilih apa yang dikerjakan sendiri
Tetap hands-on secara selektif: mengambil pekerjaan yang benar-benar membutuhkan konteks paling dalam, dan dengan sengaja menolak masalah yang menarik agar orang lain tumbuh mengerjakannya. Lead yang mengambil setiap tugas sulit menghasilkan tim yang tidak bisa berfungsi tanpanya.
Menjelaskan risiko teknis kepada non-engineer
Menerjemahkan masalah struktural menjadi konsekuensi bisnisnya â apa yang menjadi mustahil, apa yang menjadi lebih lambat, apa yang akan gagal dan kapan â tanpa melebih-lebihkannya demi memaksa tindakan maupun melunakkannya sampai ia diabaikan.
Mengembangkan engineer lewat pekerjaan
Memakai delegasi, review dan cara membingkai masalah sebagai sarana orang menjadi lebih baik, yang berbeda dari mengelola karier. Tech lead memengaruhi seberapa cepat seseorang berkembang tanpa memegang penilaian kinerja, sasaran maupun jenjang kariernya.
Kepemilikan operasional
Memastikan tim mampu menjalankan apa yang dirilisnya: alerting yang bermakna, runbook yang mutakhir, insiden yang ditelusuri sampai penyebabnya alih-alih ditutup saat layanan pulih, dan perbaikan yang dihasilkannya benar-benar dijadwalkan.
Bagaimana disiplin ini dipraktikkan
Kepemimpinan teknis tidak didefinisikan oleh sebuah toolchain, sehingga yang berikut ini bukan daftar stack. Yang diuraikan di bawah adalah praktik, metode dan artefak yang lazim dikaitkan dengan peran ini di industri â gambaran umum tentang cara disiplin ini bekerja, dan bukan keterangan tentang cara kerja individu mana pun. Keakraban dengan kosakatanya jauh kurang penting dibandingkan bukti bahwa pertimbangan di baliknya memang ada.
Memutuskan dan mencatat
- Design document
- Review RFC dan usulan
- Spike dengan batas waktu
- Catatan trade-off
- Decision log
Mekanisme kualitas
- Konvensi code review
- Definition of done
- Strategi pengujian
- Gerbang static analysis
- Anggaran refactoring
Praktik delivery
- Story slicing
- Backlog refinement
- Batas work-in-progress
- Pengurutan berbasis risiko
- Perencanaan rilis
Praktik operasional
- Rotasi on-call
- Runbook
- Penyetelan alert
- Blameless incident review
- Service-level objective
Kesehatan teknis
- Register technical debt
- Irama upgrade dependency
- Kesehatan build dan pipeline
- Pelacakan flaky test
- Metrik alur delivery
Bagaimana peran ini bekerja dengan tim Anda
Engineer bekerja di dalam tim Anda, mengikuti prioritas dan standar Anda. Anda yang mengarahkan pekerjaannya; Talent.ID menangani hubungan kerjanya. Pembagian di bawah ini adalah keseluruhan pengaturannya.
Tetap milik Anda
- Produk
- Prioritas bisnis
- Roadmap
- Arsitektur
- Prioritas sprint
- Standar engineering
- Kolaborasi teknis sehari-hari
Ditangani Talent.ID
- Hubungan kerja
- Payroll
- Benefit karyawan
- Administrasi talenta
- Hubungan karyawan berkelanjutan
Seperti apa ini dalam praktik
Skenario hipotetis, ditulis untuk menunjukkan bagaimana model kerjanya diterapkan. Ini bukan klien Talent.ID dan bukan proyek yang pernah dikerjakan.
- Tantangan
- Sebuah tim berjalan stabil tetapi codebase-nya menyimpang: masalah yang sebanding diselesaikan dengan beberapa cara berbeda, pertanyaan desain diputuskan di dalam code review alih-alih sebelumnya, dan remediasi yang lama ditunda mulai memperlambat pekerjaan fitur biasa. Para engineer-nya cakap dan tidak ada yang memegang bentuk teknis dari pekerjaan itu.
- Pendekatan
- Seorang engineer senior tambahan bergabung ke tim di bawah pengaturan yang sudah berlaku â arsitektur klien, standar klien, irama perencanaan klien dan roadmap klien. Arah teknis tetap ditetapkan oleh klien; kapasitas tambahan bekerja di dalamnya, ikut serta dalam design review dan delivery harian bersama tim, bukan di sampingnya.
- Yang ditambahkan ke tim
- Klien memperoleh kapasitas engineering senior sambil tetap memegang penuh keputusan produk, arsitektur dan standar engineering. Tidak ada yang berubah tentang siapa yang menentukan arah teknis tim.
Disiplin terkait
Pertanyaan yang sering diajukan
- Apa bedanya tech lead dan engineering manager?
- Tech lead memegang bagaimana software tim dirancang dan dibangun; engineering manager memegang bagaimana tim berfungsi sebagai kumpulan orang. Hiring, pengembangan, kinerja, gaji, komposisi tim dan koordinasi lintas fungsi adalah milik manajer. Keputusan teknis, design review, standar dan pengurutan delivery adalah milik lead. Sebagian organisasi menggabungkan keduanya menjadi satu pekerjaan, yang bisa berjalan di tim kecil dan cenderung gagal saat tim membesar, karena kedua kumpulan tugas itu memperebutkan perhatian yang sama dan yang mendesak selalu menang.
- Apa bedanya tech lead dan software architect?
- Cakupan dan horizon. Tech lead bertanggung jawab atas pekerjaan satu tim dalam hitungan minggu dan bulan serta tetap cukup dekat dengan kode untuk mereview-nya. Architect bekerja lintas sistem dan lintas tim dalam hitungan tahun, pada dekomposisi, batas antar komponen, integrasi dan kebutuhan non-fungsional, dan biasanya lebih sedikit hands-on. Keputusan arsitektural yang buruk mahal karena sulit dibalik; keputusan tech lead yang buruk biasanya terbatas di satu tim dan bisa dikoreksi dalam satu sprint.
- Apakah tech lead masih menulis kode?
- Biasanya ya, dan jumlahnya kurang penting dibanding pemilihannya. Menulis cukup banyak untuk menjaga naluri teknis tetap mutakhir dan untuk merasakan gesekan yang dirasakan tim hampir merupakan keharusan; menulis begitu banyak sampai review mengantre di belakang pekerjaan pribadi justru menggagalkan tujuannya. Lead yang tidak menulis apa pun perlahan kehilangan posisi yang menjadi tumpuan peran ini, dan lead yang menulis segalanya menjadi alasan timnya tidak bisa berjalan tanpanya.
- Apakah tech lead sebuah promosi atau pekerjaan yang berbeda?
- Pekerjaan yang berbeda, meski sering diberikan sebagai promosi. Ia bertumpu pada keterampilan yang berbeda dari kontribusi individu senior â persuasi, penentuan prioritas, kenyamanan dengan pekerjaan belum selesai yang dimiliki orang lain â dan seorang engineer yang sangat baik bisa saja buruk di posisi ini tanpa itu mengatakan apa pun tentang kemampuan engineering-nya. Memperlakukannya sebagai pangkat alih-alih sebagai sekumpulan tanggung jawab menghasilkan lead yang enggan dan jalan kembali yang terasa seperti penurunan padahal semestinya biasa saja.
- Seberapa besar wewenang seorang tech lead sebenarnya?
- Secara formal biasanya sangat kecil. Peran ini hampir selalu bertanggung jawab atas hasil yang tidak bisa dipaksakannya, dan karena itu penalarannya harus cukup baik untuk meyakinkan serta kredibilitas menjadi mata uang sehari-harinya. Organisasi yang berharap gelarnya saja akan membawa keputusan cenderung menghasilkan lead yang terus-menerus melakukan eskalasi atau yang mengeluarkan instruksi yang tidak diikuti siapa pun.
- Bisakah satu orang memimpin lebih dari satu tim?
- Bisa, dan biasanya kualitasnya menurun. Peran ini bergantung pada kedekatan â mengetahui siapa yang tersendat, seperti apa antrean review-nya, asumsi mana yang diam-diam keliru â dan kesadaran semacam itu cepat menipis ketika dibagi ke beberapa tim. Membagi seorang lead ke dua tim sering menghasilkan satu tim dengan lead paruh waktu dan satu tim tanpa lead sama sekali.
- Bagaimana tech lead bekerja dengan tim engineering yang sudah ada?
- Di dalam pengaturan Anda, bukan menggantikannya. Dalam model penambahan kapasitas tim engineering, organisasi Anda tetap menetapkan arsitektur, standar engineering, arah teknis, roadmap dan prioritas, dan arah harian pekerjaan tetap dipegang orang-orang Anda sendiri. Hubungan kerja berada di Talent.ID â payroll, benefit karyawan dan administrasi talenta â dan hanya itu. Kepemimpinan engineering tidak dialihkan, dan tidak ada bagian dari pengaturan itu yang memindahkan pengambilan keputusan teknis ke luar tim Anda.
Ceritakan kebutuhan tim Anda
Jelaskan kekurangannya â pekerjaannya, stack-nya, cara tim Anda berjalan â dan kami akan menyampaikan apa yang dapat kami dukung. Bila bukan sesuatu yang bisa kami bantu, kami akan mengatakannya.