The Manager’s Path

Judulnya sengaja gw samain dengan salah satu buku leadership yang cukup fenomenal (menurut gw) bagi para tech leaders di seluruh dunia. Di bukunya menceritakan bagaimana pengalaman Camile yang dulunya merupakan seorang Tech Lead hingga menjadi seorang CTO. Sebenarnya ada beberapa buku yang sudah gw baca mengenai leadership terutama mengenai engineering leadership seperti Radical Candor, The Phoenix Project and Leader Eat Last (general leadership book). Dari buku-buku tersebut, The Manager’s Path adalah buku yang paling mewakili perjalanan karir gw sebagai seorang tech leaders dan kali ini gw akan menceritakan bagaimana berkarir sebagai seorang tech leaders berdasarkan pengalaman gw langsung dan juga kombinasi dari ilmu yang gw pelajari dari buku-buku tersebut.

Dalam buku The Manager’s Path, Tech Lead bukan lah sebuah posisi melainkan sebuah role yang diberikan kepada individual contributor yang cukup senior dalam mengelola project. Managing project merupakan sebuah role yang cukup challenging karena menyangkut beberapa aspek berikut:

1. Understand the business and requirement.
   Mengerti dan memahami requirement adalah sesuatu yang sifatnya mutlak sebelum menjalankan project. Sebuah project dinyatakan berhasil karena requirement telah terpenuhi, bukan karena budget, deadline, efisien dan lain-lain. Disini gw menambahkan mengerti bisnis, mengapa demikian? Karena biasanya engineering terlalu fokus terhadap requirement, sehingga mereka tidak memahami fokus bisnis dalam project tersebut. Dengan memahami bisnis dalam project tersebut, sebagai Tech Lead akan memberikan insight yang lebih baik ke project tersebut dan memiliki visibility yang lebih luas terhadap maintenance jangka panjang. Contoh punya gw dulu adalah project VCC. Gampangnya VCC itu cuma buat kartu kredit yang sifatnya sementara dengan constraint seperti limit dan waktu swipe, padahal jika digali sebenarnya banyak scope yang lebih luas seperti apakah bisa digunakan transaksi online, multiswipe atau single swipe, merchant terdaftar dan lain-lain. Dengan paham konteks bisnis, Tech Lead akan memiliki visibility yang lebih terhadap suatu project.
2. Push the details and unknown.
   Tentunya Tech Lead memiliki jam terbang lebih tinggi dari anggota timnya yang lain. Hal ini memungkinkan dia untuk paham terhadap abstraksi dari requirement dengan menurunkan menjadi hal yang lebih detail lagi. Ini penting karena yang mengerjakan project itu bukan Tech Lead, namun anggota timnya. Dengan memberikan sesuatu yang detail, mempermudah timnya untuk melakukan eksekusi project. Begitu juga hal-hal tak terduga seperti yang tidak tertulis di requirement, itulah mengapa Tech Lead perlu paham konteks bisnisnya terlebih dahulu ketimbang hanya membaca requirement.
3. Pelaksana project.
   Setelah semua requirement dan detail terpenuhi, tentunya project tersebut harus dijalankan agar bisa selesai. Tech Lead berlaku juga sebagai pengawas juga apabila di tengah perjalanan project terdapat isu yang tidak tercapture sebelumnya dan memberikan insight bagaimana agar project tersebut bisa tetap berjalan sampai selesai.
4. Decision maker.
   Bisa dibilang ini ada hak istimewa yang hanya dimiliki Tech Lead. Karena dia lah yang memegang penuh terhadap project tersebut, dia juga mengawasi dan dia juga yang memastikan bahwa project tersebut bisa selesai. Dia yang menentukan berapa orang yang diperlukan untuk mengerjakan project tersebut, perlu berapa lama project tersebut hingga selesai, bagaimana deployment dan the worst scenario ketika harus rollback.

Ada juga perusahaan yang menganggap Tech Lead sebagai career ladder (sebagai contoh tiket.com) untuk seorang senior engineer masuk ke dalam dunia management. Biasanya career ladder seorang engineer dibagi menjadi 2 yakni management leadership dan individual contributor leadership. Untuk management biasanya seperti berikut:

1. Tech Lead. (TL)
2. Engineering Manager. (EM)
3. Head of Engineering. (Gatw biasa disingkat apa lol)
4. Vice President of Engineering. (VP Engineering)
5. Chief Technology Officer. (CTO)

Sedangkan untuk individual contributor:

1. Principal Engineer. (PE)
2. Senior Principal Engineer. (SPE)
3. Technical Architect. (TA tapi bukan talent acqusition lol)
4. Principal Architect. (PA tapi bukan performance appraisal lol)
5. Distinguish Engineer. (DE tapi bukan data engineer)

Berdasarkan pengalaman gw sebagai Tech Lead, ada beberapa hal mendasar yang harus dilakukan atau dimiliki oleh seorang Tech Lead yakni:

1. Managing project.
   Seperti role yang gw sebutkan diatas, seorang Tech Lead bertanggungjawab penuh terhadap project yang dikerjakan oleh timnya.
2. Ownership.
   Seorang Tech Lead bertanggungjawab penuh tidak hanya kepada project yang dikerjakan melainkan anggota tim yang dipimpin (healthy environment) dan juga service/aplikasi yang dipegang. Biasanya Tech Lead juga disebut squad lead yang memegang sebuah squad tertentu. Sebagai contoh squad payment, maka dia bertanggungjawab penuh terhadap service payment.
3. Regularly 1 on 1.
   Sebenarnya ini cukup menarik karena di dalam buku The Manager’s Path mengatakan bahwa ini merupakan waktu yang tepat untuk gathering the feedback atau sekedar ngobrol santai dengan anggota timnya. Hanya saja menurut gw jika terlalu sering malah akan membuat bingung mengenai topic apa yang dibicarakan. Jadi jalan tengahnya kalau gw dulu adalah membuatnya di level biweekly atau monthly. Jika ada kebutuhan tertentu maka bisa as per request.
4. Delegating.
   Buat para Tech Lead baru, biasanya ini paling sulit dilakukan karena semua ingin dikerjakan sendiri. Ini sudah tidak bisa lagi dilakukan karena sebagai seorang lead harus bisa mempercayakan pekerjaan kepada anggota timnya. Selain itu juga membuat tim menjadi tidak scalable karena jika semua harus dipegang lead, lalu bagaimana tim bisa berkembang ke depannya.
5. 70/30 Rules.
   70% dari waktu yang dihabiskan Tech Lead adalah management things. Makesure tim bisa menyelesaikan project dengan baik dan menjaga agar tempo pergerakan tim tetap sehat (tidak burnout karena terlalu banyak pekerjaan namun tidak juga terlalu santai sehingga membuat tim menjadi tidak berkembang dan membosankan). 30% adalah stay technical, melihat hal-hal yang tidak bisa dilihat oleh anggota tim seperti arsitektur aplikasi, technical debt dan sustainability aplikasi untuk jangka panjang.

Sebenarnya ada 1 hal lagi yang kadang suka tertukar dalam pembuatan job desc antara Senior dan Tech Lead. Mereka berdua dituntut harus bisa coaching dan mentoring dimana fokusnya sendiri sudah berbeda. Tech Lead bisa melakukan mentoring dan coaching sedangkan senior biasanya hanya melakukan mentoring. Lalu dimana bedanya?

• Mentoring adalah upaya mendampingi seorang individu sampai individu tersebut bisa melakukan tugas yang diharapkan dengan baik. Sebagai contoh seorang junior engineer akan dibimbing oleh seniornya sampai dia bisa melakukan tugasnya dengan baik (as a junior engineer). Bisa dilihat disini ekspektasinya hanya sampai meet expectation terhadap level yang dimiliki oleh individu tersebut.
• Sedangkan coaching adalah upaya untuk melatih individu agar individu tersebut bisa menjadi siap untuk mencapai level berikutnya. Sebagai contoh junior engineer akan dilatih oleh Tech Lead-nya agar siap ke level berikutnya menjadi mid engineer. Seorang Tech Lead akan membimbing dan juga memastikan agar junior engineer memang pantas untuk naik ke level berikutnya.

Apakah senior bisa coaching? Jawabannya pasti bisa, hanya saja job desc tersebut menjadi ambigu karena memang level senior memiliki kebiasaan hanya memastikan engineer yang dimentoring bisa mengerjakan sesuai dengan ekspektasi job desc di level tersebut. Jarang sekali ada senior yang memastikan engineer yang didampingi naik ke level berikutnya seperti menjadi selevel dengan senior tersebut.

Tech Lead sendiri mempunyai limitasi untuk tim yang dia pimpin. Hal ini berdasarkan pengamatan gw langsung ketika menjadi seorang lead. Sayangnya didalam buku yang gw baca, tidak ada angka pas yang diberikan langsung sehingga mungkin apa yang gw infokan bisa menjadi subjektif. Untuk strukturnya sendiri sebagai berikut:

1. Tech Lead.
2. Senior Engineer. (1 person)
3. Middle Engineer. (2 person)
4. Junior Engineer. (1-2 person)

Tech Lead jelas sebagai kapten dalam tim sedangkan senior merupakan wakilnya. Artinya jika Tech Lead sedang tidak ada, maka senior menjadi kapten tim tersebut. Itulah kenapa idealnya hanya ada 1 senior dalam 1 squad. Terlalu banyak senior bisa menimbulkan masalah seperti career ladder (ada 2 atau lebih senior memperebutkan posisi pengganti lead) dan Alpha Geek Problem. Untuk level mid biasa diberikan 2 orang agar project yang dikerjakan tetap dalam tempo yang normal (karena memang sudah memiliki experience) sedangkan junior adalah anggota yang disiapkan sebagai regerenasi dalam tim (persiapan jika ada anggota tim yang resign sehingga bisa naik ke level berikutnya apabila memang sudah siap). In total, jumlah idealnya sendiri adalah 5-7 orang yang bisa dipimpin oleh Tech Lead. Lebih dari itu maka produktivitasnya akan menurun dengan bertambahnya jumlah anggota tim yang harus dipegang (karena ekspektasinya, tanggungjawab projectnya juga akan bertambah).

Setelah mengetahui serba-serbi Tech Lead, posisi berikutnya adalah Manager. Gw disini akan menceritakan pengalaman gw sebagai Engineering Manager dan berdasarkan teori yang ada di buku.

Sebagai seorang Manager, tentunya akan ada beberapa fase yang mungkin tidak pernah dirasakan ketika menjadi Tech Lead seperti berikut:

1. Multiple meetings.
   Kalender seorang manager biasanya sangat berwarna terutama manager yang memegang squad-squad penting di divisinya. Hal ini tentu sangat menjengkelkan karena beberapa orang menjadikannya jokes seperti KPI seorang manager adalah banyaknya jumlah meeting yang dihadiri dalam 1 bulan. Padahal sebenarnya manager juga malas meeting karena kalau meeting terus kapan kerjanya.
2. The Shield.
   Sebenarnya di dalam breakdown gaji seorang manager ada part dimana harus jadi tameng bagi timnya. Artinya adalah manager akan menjadi orang pertama yang dicari dan disalahkan ketika ada salah deploy, isu di production atau ada tim yang melakukan kesalahan. Hal ini biasanya yang mengagetkan manager yang baru karena uda mereka tidak ngoding, eh tiba-tiba disalahin pas ada deployment.
3. Manage (more) people.
   Sebagai seorang Tech Lead, bisa dibilang sudah melakukan management people. Yang menyulitkan disini adalah jumlah people yang dimanage akan bertambah 2-3x dari yang biasa dipegang Tech Lead. Hal ini semakin rumit karena bisa saja culture antara squad berbeda sehingga proses membangun trust antara satu tim dengan tim yang lain akan berbeda juga.

Lalu hal penting apa saja yang perlu diperhatikan oleh seorang Engineering Manager. Berikut poin-poinnya:

1. Regularly 1 on 1.
   Berbeda dengan ketika menjadi seorang Tech Lead, 1 on 1 disini adalah sebuah keharusan. Mengapa demikian? karena tim yang dipegang seorang manager jauh lebih besar dan mengamati tim dari hari ke hari sungguh akan sangat merepotkan. Bayangkan jika seorang manager harus mengikuti semua meeting tiap squadnya, maka waktunya akan habis buat meeting aja, jadinya malah tidak kerja. Karena itu pooling informasi ke Tech Lead dalam 1 on 1 session akan menjadi salah satu cara yang efektif untuk mendapatkan informasi up to date mengenai perkembangan tim. Selain itu juga memberikan kesempatan Tech Lead untuk mengatur anggota timnya sesuai dengan kebutuhannya tanpa harus melakukan micro managing.
2. Connecting the dots.
   Ini adalah bagian essential dari seorang manager. Dalam kehidupan nyata, Tech Lead sudah pasti hanya fokus terhadap sustainability squadnya dan cenderung tidak memikirkan tim lain. Dengan menjadi manager dari beberapa squad memudahkan proses engineering itu sendiri karena masing-masing tim pasti akan memberikan update terhadap timnya dan manager bisa mengambil keputusan terbaik agar project-project yang sifatnya multisquad ini bisa berjalan dengan baik dan tentunya tetap fokus terhadap kualitas engineering yang dideliver.
3. Manage the priority.
   Sebenarnya mengatur prioritas itu adalah hal yang perlu dilakukan oleh semua orang baik engineer, lead atau siapa pun itu. Hanya saja khusus level manager ke atas (perhaps), mengatur skala prioritas itu sangat penting karena dalam kenyataan sehari-hari ada project yang perlu dikerjakan, ada yang perlu dibuang, ada meeting yang perlu dihadiri, ada yang cukup mengirimkan delegasi. Jika ingin survive dalam memanage team dan project perlu kemampuan untuk bisa mengatur prioritas.
4. Build the culture.
   Culture biasanya datang dari company dan bukan dari divisi. Hanya saja dalam kesempatan tertentu, manager membangun culture yang menjadi standard untuk tiap timnya. Sebagai contohnya being helpful, kita paham bahwa menolong orang lain adalah part dari culture yang ada di perusahaan namun dengan encourage dari manager, maka turunan dari culture tersebut lebih berasa ke tiap anggota timnya. Sebagai contoh lebih fast response ketika ada anggota tim lain yang membutuhkan bantuan dan wajib memfollow up untuk mengetahui apakah isunya sudah solved apa belum.
5. 80/20 Rules.
   Sebenarnya sama dengan 70/30 rules punya Tech Lead namun porsi management jauh lebih terasa di level manager. Selain itu yang perlu diperhatikan ketika menjadi manager adalah harus bisa catch up dengan teknologi yang dipakai oleh tim engineering saat itu. Salah satu cara terbaik adalah menyiapkan waktu 1-2 jam setiap minggunya untuk melakukan pairing code dengan salah satu senior engineer di salah satu squad. Selain membangun trust dengan senior engineer, hal ini baik untuk manager dalam mengecek code yang dikerjakan oleh anggota timnya.
6. Engineering sustainability.
   Sebenarnya masi berhubungan dengan 80/20 rules hanya saja yang dituntut di sini adalah bagaimana service yang dipegang oleh seorang manager tetap berjalan dengan baik dan juga dengan helicopter view yang dimiliki olehnya bisa melihat hal-hal yang mungkin tidak bisa dilihat jika hanya berada dalam 1 squad. Oleh karena itu dokumentasi flow end to end sebuah aplikasi menjadi essential dan harus direview berkala oleh manager agar aplikasi tetap sustainable ke depannya.
   

Bagian yang paling sulit dipisahkan dari Engineering Manager adalah memahami bahwa posisi tersebut adalah Manager. Mau dibilang sebagai engineering leadership pun yang fokus terhadap engineering, tetap fokusnya akan kembali ke people management. Jika sebagai seorang engineer dan menemui jalan buntu ketika menghadapi masalah koding, kita cukup mencari di stackoverflow. Tetapi itu berbeda ketika sudah mengurus manusia, karena pada dasarnya manusia unik terlebih lagi jika berhubungan dengan software engineer, makin unik lagi ini manusianya. Dalam people management sendiri, ada 3 hal penting yang tidak terpisahkan dari role seorang Engineering Manager:

1. Hiring Engineer.
2. MPP Engineer.
3. Firing Engineer.

Hiring engineer berarti mencari engineer baru untuk menambah anggota tim. Sebenarnya tidak ada yang istimewa dari tugas ini. Yang menjadi challenging adalah menentukan posisi dari seorang software engineer. Beberapa orang fokus terhadap lama pengalaman kerja seorang engineer, ada yang fokus terhadap kemampuan engineer dalam melakukan competitive programming, ada yang fokus dalam kesehariannya yang dekat dengan culture dari perusahaan tersebut dan seterusnya. Jika tidak ada standard yang jelas yang turun dari engineering directorat, hal ini akan menjadi rumit karena masing-masing akan punya guideline tersendiri dalam menentukan level engineer yang masuk ke timnya.

MPP (Man Power Planning) engineer yang berarti menentukan berapa jumlah engineer yang akan dipunyai oleh divisi / squad tertentu dalam kurun waktu tertentu (bisa berubah-ubah sesuai keadaan). Biasanya MPP sendiri adalah hasil diskusi antara manager dengan managernya manager (bisa head, vp atau langsung CTO). Menurut pendapat gw, yang paling tepat untuk menentukan MPP sebenarnya adalah manager. Kenapa demikian? Karena mereka lah yang turun paling dekat dengan Tech Lead dan mengetahui medan tempur (halah) yang sedang dihadapi tim. Tentunya jika dibutuhkan, seorang manager bisa memindahkan anggota tim dari satu squad ke squad yang lain dan yang pasti harus meminta ijin terlebih dahulu kepada Tech Lead dan juga tim productnya. Gw percaya segala sesuatu bisa dinegosiasikan selama kita memintanya baik-baik dan alasannya pun jelas.

Hal ini pernah gw lakukan waktu memegang squad payment dan refund. Saat covid-19 sedang naik-naiknya pada tahun 2020, hal ini membuat banyak sekali proses refund di tiket dan perubahan regulasi pun hampir terjadi setiap minggu bahkan pernah tiap hari berubah. Tim pun menjadi kesulitan karena terjadi perubahan project yang harus dikerjakan sedangkan jumlah engineer masih belum cukup jika harus catch up. Gw pun akhirnya meminta bantuan tim payment untuk membantu refund dan bernegosiasi antara lead dan productnya karena memang waktu itu nyaris tidak ada yang belanja tiket karena memang lagi copid, jadi akhirnya timnya pun dipindahkan terlebih dahulu dan hanya menyisakan 1 senior engineer untuk standby di payment. Anggota tim payment yang lain membantu untuk membuat sistem refund yang dinamis. Sebenarnya sebagai manager, gw bisa dengan mudah memindahkan orang tanpa meminta ijin karena bisa dibilang itu tim gw juga. Tetapi hal itu tidak baik untuk jangka panjang karena ada anggota tim yang harus kalian hargai dan perlu didiskusikan dalam pengambilan keputusan yang melibatkan multiple teams.

Pelajaran penting mengenai MPP adalah ketika seorang yang bukan manager (Head, VP dan CTO) mengambil alih posisi untuk menentukan anggota timnya ditaruh dimana tanpa berdiskusi terlebih dahulu dengan managernya maka percayalah itu awal yang buruk bagi environment di tim tersebut. Sudah pernah terjadi di tiket LOL.

Yang terakhir adalah Firing Engineer. Hal ini merupakan hal tersulit bagi seorang manager karena bisa dibilang memutuskan rejeki orang. Tetapi hal tersebut adalah part yang harus dijalankan oleh seorang manager karena merupakan part of people management. Sebelum memutuskan untuk melakukan cut terhadap anggota tim ada beberapa hal yang perlu dicek terlebih dahulu. Berikut stepnya:

1. Root Cause Analysis.
   Lol kok kayak lagi nyari isu problem di production. Sebenarnya isu engineering dan people itu mirip-mirip, ketika ada anggota tim yang bekerja dibawah ekspektasi, perlu dicari tahu terlebih dahulu apakah ada masalah yang sedang dihadapinya sehingga performancenya menurun. Bisa saja itu masalah keluarga, masalah pribadinya atau mungkin memang sedang tidak mood (kampret sih, tapi ada aja masalah manusia). Penanganannya pun bermacam-macam tergantung dengan root causenya.
2. Toxic people.
   Apakah orang ini membuat tim menjadi tidak healthy? Healthy disini bisa bermacam-macam seperti berbuat onar, tidak bisa menyelesaikan tugas dengan baik, suka hilang-hilangan kalau dicari. Memahami bahwa orang tersebut toxic atau tidak bisa digali melalui orangnya langsung atau bertanya langsung ke timnya. Disini manager harus bersifat netral dan tidak boleh berat sebelah karena akan menimbulkan bias.
3. Teguran lisan.
   Menegur secara lisan merupakan tugas manager apabila orang yang bermasalah masih melakukan hal yang tidak sesuai dengan ekspektasi perusahaan. Teguran pun sebisa mungkin dilakukan tanpa harus diketahui anggota tim untuk menghindari rasa malu yang dirasakan oleh bermasalah karena bisa saja setelah ditegur, orang tersebut sudah berubah menjadi baik lagi.
4. Teguran tertulis.
   Ini adalah proses lanjutan apabila yang bersangkutan masih melakukan kesalahan yang sama secara berulang. Yang perlu dicatat adalah kesalahan yang sama. Jadi jika kesalahannya bukan yang sama, perlu dicari dulu root causenya terlebih dahulu karena pada dasarnya manusia tidak luput dari kesalahan.
5. Performance Improvement Plan.
   Memberikan kesempatan terakhir kepada orang yang bermasalah karena masalah performance yang tidak sesuai ekspektasi (berbeda dengan toxic, yang diberhentikan melalui surat peringatan). Biasanya PIP dilakukan selama 3 bulan berturut-turut. Jika yang bersangkutan tidak bisa catch up dengan tempo tim, maka akan diberhentikan karena hanya akan menghambat tempo dalam tim. Disini tugas seorang Tech Lead untuk membimbing anggotanya yang kurang serta memberikan reportnya kepada manager untuk keputusan akhir apakah akan dilanjutkan apa tidak.

Untuk struktur ideal tim yang dipegang oleh seorang manager adalah 2-3 squad dengan komposisi yang sama dengan yang dimiliki oleh Tech Lead. Berbeda dengan Tech Lead, sebisa mungkin tim yang dipegang oleh Engineering Manager diharapkan berada di domain level yang sama. Sebagai contoh adalah payment maka untuk squadnya bisa payment, order dan refund. Jika ada domain yang agak berbeda biasanya akan menyulitkan manager ketika terjadi isu atau pun sedang melakukan solutioning karena terdapat switching context.

Yang berikutnya adalah managing the managers atau dalam leadership role adalah head / VP.

Sayang sekali gw belum sampai sini LOL. Jadi jika ada yang sudah sampai di level ini, silahkan berbagi tulisannya ya. Semoga kalian bisa belajar dari pengalaman leadership gw dan tentunya didukung oleh teori-teori yang ada di buku The Manager’s Path.

Source: