Sehari dalam Kehidupan Engineering Manager: Apa yang Tidak Diberitahukan Deskripsi Kerja

Pukul 8.47 pagi. Engineer on-call Anda mendapat halaman pada pukul 3.14 pagi untuk replika Postgres yang pulih sendiri pada pukul 3.22 pagi, artinya ia tidur delapan menit bukan sepanjang malam. Skip-level Anda menginginkan pembaruan peta jalan sebelum tengah hari dan Anda belum membuka Notion. Anda memiliki 1:1 dengan seorang senior IC dalam 13 menit yang belum Anda persiapkan, dan rekruter yang menempatkan Anda dalam pekerjaan ini enam bulan lalu mendeskripsikannya sebagai "memimpin tim berkinerja tinggi."

Kalimat itu benar seperti halnya "saya menjalankan restoran" benar ketika Anda sebenarnya sedang melakukan inventaris pukul 11 malam dan meminta maaf kepada pelanggan tetap soal pesanan yang salah. Itu headlinenya. Pekerjaannya adalah segalanya di baliknya.

Inilah tampilan hari yang sebenarnya bagi seorang Engineering Manager dengan 5 hingga 12 bawahan langsung di perusahaan B2B SaaS. Timestamp nyata, gangguan nyata, trade-off nyata. Jika Anda seorang IC yang mempertimbangkan perpindahan, baca ini dan tanyakan pada diri sendiri apakah ini terdengar seperti pekerjaan yang akan Anda lakukan selama bertahun-tahun. Jika Anda adalah EM saat ini yang merasa seperti gagal karena hari Anda tidak lain adalah gangguan, baca ini dan kenali bahwa Anda tidak gagal. Anda melakukan pekerjaan itu.

Pukul 8.00 Pagi: Persiapan Standup, Triase Slack, dan PagerDuty

Sebelum tim Anda masuk, Anda melakukan pekerjaan yang tidak dilihat siapa pun.

Buka PagerDuty. Lihat insiden semalam. Siapa yang mendapat halaman, apa yang dipicu, apakah nyata atau itu alert yang sama yang berkedip-kedip yang Anda tandai untuk pembersihan tiga sprint lalu? Jika nyata, on-call Anda butuh pengganti hari ini; beri tahu mereka di Slack untuk melewati standup dan tidur 90 menit ekstra. Jika itu kebisingan, itu adalah tiket untuk siapa pun yang memiliki observabilitas. Bagaimanapun, putuskan sebelum standup agar Anda dapat menyerap gangguan alih-alih membiarkan tim memikul bebannya.

Kemudian Slack. Anda memiliki 47 pesan belum terbaca di enam channel. Anda tidak membaca untuk kontennya. Anda memindai dua hal: siapa yang terhambat, dan siapa yang frustrasi. Engineer yang terhambat butuh jalan yang dibuka sebelum pukul 10 pagi atau mereka kehilangan setengah hari. Engineer yang frustrasi dalam thread publik butuh DM, bukan balasan publik, dan DM itu mungkin perlu terjadi pagi ini.

Buka Linear. Atau Jira. Alat mana pun yang digunakan tim Anda, pertanyaannya sama: tiket mana yang terhenti dalam review, mana yang diblokir oleh dependensi di luar tim Anda, dan mana yang terlihat "sedang dikerjakan" tapi tidak bergerak dalam empat hari? Kategori terakhir itulah yang berbahaya. Engineer yang tidak menggerakkan tiket dalam empat hari entah terhenti dan tidak mau mengatakannya, mengerjakan sesuatu yang tidak mereka ceritakan kepada Anda, atau diam-diam melihat-lihat pekerjaan lain. Anda perlu tahu yang mana sebelum hari Jumat.

Anda belum menulis kode dalam tiga minggu. Dulu Anda melakukan bagian hari ini dengan kopi dan compiler. Sekarang Anda melakukannya dengan kopi dan konteks tujuh orang yang dimuat ke dalam kepala Anda. Pergeseran dari "saya menulis kode" ke "saya membuka jalan bagi 7 orang yang menulis kode" adalah hal pertama yang tidak ada yang memperingatkan Anda, dan ini adalah bagian yang paling banyak diratapi mantan IC selama enam bulan pertama.

Pukul 9.00 Pagi: 1:1 yang Belum Anda Persiapkan

1:1 adalah 30 menit Anda dengan leverage tertinggi dalam seminggu, dan ini adalah hal pertama yang dikorbankan ketika sprint planning melebihi waktu. Hari ini bersama Maya, seorang senior backend engineer. Ia telah ada di sini tiga tahun. Ia men-ship migrasi besar Anda terakhir. Dan dua minggu lalu LinkedIn-nya diam-diam berubah dari "terbuka untuk peluang: tidak" menjadi "terbuka untuk peluang: ya."

Anda tidak memulai dengan itu. Anda memulai dengan: "Bagaimana minggu Anda?" Dan kemudian Anda diam.

1:1 yang nyata bukan pembaruan status. Pembaruan status terjadi di Linear dan standup. 1:1 adalah untuk segala sesuatu yang tidak cocok dalam tiket: umpan balik yang telah ia tahan, keputusan arsitektur yang tidak ia setujui, fakta bahwa manajernya (Anda) tidak cukup mendorong kembali ketika produk memotong desain ulang miliknya setengahnya. Tugas Anda adalah membuatnya aman untuk mengatakan hal yang sulit, lalu bertindak berdasarkan apa yang ia katakan.

Pada pukul 9.18 pagi, PagerDuty menyala. Bukan layanan tim Anda, tapi cukup dekat sehingga Slack menjadi ramai. Anda melirik ponsel Anda. Maya melihat Anda melirik. Ini adalah skrip yang berhasil:

"Itu bukan milik kami, tapi Slack sebentar akan ramai. Beri saya 20 detik untuk menonaktifkannya, lalu kita lanjutkan. Waktu Anda lebih penting dari thread itu."

Kemudian Anda benar-benar menonaktifkannya. Anda tidak setengah mendengarkan selama 12 menit berikutnya sementara mata Anda memantau notifikasi Slack. 1:1 mendapat perhatian penuh Anda atau Anda membatalkannya. Tidak ada pilihan tengah. Pilihan tengah adalah bagaimana senior engineer belajar bahwa manajer mereka tidak benar-benar hadir, dan itulah cara LinkedIn Maya berubah dari "ya" menjadi "saya baru saja menerima penawaran."

Pukul 10.30 Pagi: Review PR, Tapi Bukan untuk Kebenaran

Anda membuka GitHub. Atau GitLab. Ada 14 PR terbuka di seluruh tim Anda. Anda tidak meninjau untuk kebenarannya. Staff engineer Anda meninjau untuk kebenaran, dan ia lebih baik dalam hal itu dari Anda sekarang.

Anda meninjau untuk aliran.

Siapa yang telah menunggu review lebih dari 48 jam? Engineer itu kehilangan momentum dan mungkin context-switching ke hal lain, artinya ketika review akhirnya masuk, mereka perlu satu jam untuk menukar konteks kembali. Temukan reviewer-nya, cari tahu mengapa mereka terhambat, buka blokirnya.

PR mana yang menyentuh file yang sama? Itu konflik merge yang akan terjadi, dan salah satu dari engineer itu akan kehilangan pagi karena harus rebase. Satukan mereka dalam panggilan 10 menit sekarang.

PR mana yang memiliki enam putaran komentar nitpick pada perubahan 40 baris? Itu senior engineer yang terlalu berhati-hati dengan junior, dan itu mengikis kepercayaan dari kedua arah. Anda tidak berkomentar di thread. Anda DM senior tersebut: "Hei, perubahannya terlihat baik. Setujui dan kita lanjutkan." Itulah keputusan yang tidak akan dibuat siapa pun, karena tidak ada orang lain yang memiliki wewenang untuk membuatnya.

GitHub adalah alat kode untuk engineer Anda. Untuk Anda, itu adalah permukaan manajemen, dasbor real-time tentang di mana perhatian terhenti, di mana kolaborasi menjadi gesekan, dan di mana kecepatan pengiriman tim Anda bocor melalui hambatan review. Sebut ini pajak antrean PR. Setiap PR yang duduk lebih dari dua hari mengenakan bunga majemuk dalam bentuk fokus yang hilang, dan Anda satu-satunya orang yang tugasnya adalah memperhatikan.

Pukul 11.15 Pagi: Sprint Planning, Lalu Gangguan

Anda sedang 15 menit ke dalam memperbaiki board Linear sprint berikutnya dengan tech lead Anda. Anda menolak sebuah story yang bertuliskan "investigasi migrasi penyedia auth" karena itu bukan story, itu satu kuartal pekerjaan yang menyamar sebagai selasa siang.

Slack: "hei ada 2 menit untuk pertanyaan cepat?" Dari VP of Product.

Tidak pernah dua menit. Tidak pernah satu pertanyaan. "Pertanyaan cepat" adalah "kami memajukan peluncuran fitur AI tiga minggu, apa yang realistis dapat dikirimkan tim Anda sebelum itu?" Jawaban itu mengharuskan Anda mengetahui kapasitas tim Anda, komitmen sprint yang ada, utang teknis yang memblokir fitur AI, PTO senior engineer Anda bulan depan, dan realitas politik bahwa mengatakan "tidak, kami tidak bisa" adalah kalimat yang mendefinisikan karier yang hanya bisa Anda gunakan beberapa kali dalam setahun.

Anda mengambil panggilan itu. Anda tidak memberikan jawaban dalam panggilan itu. Anda berkata: "Biarkan saya melihat dependensinya dan kembali dengan angka nyata sebelum pukul 4 sore." Kemudian Anda kembali ke sprint planning pukul 11.38 pagi dengan tech lead Anda, yang telah dengan sopan menatap layarnya selama 23 menit.

Inilah peran yang tidak disebutkan JD mana pun: penerjemah konteks. Anda duduk antara strategi eksekutif ("kami ingin AI pada Q3") dan realitas rekayasa ("migrasi auth memblokir itu, dan engineer yang mengetahui auth sedang cuti parental"). Anda tidak bisa mengatakan ya untuk keduanya. Tugas Anda adalah menerjemahkan satu ke yang lain dengan cara yang tidak merusak kepercayaan ke arah mana pun. Beberapa minggu Anda melakukannya dengan baik. Beberapa minggu Anda melakukannya buruk dan tim Anda guncang. Keduanya normal.

Pukul 1.00 Siang: Rapat dengan Diri Sendiri yang Tidak Pernah Terjadi

Setelah makan siang, kalender Anda menunjukkan "FOKUS: dokumen perencanaan Q3." Sudah ada di sana selama tiga minggu. Bergeser setiap hari.

Ini adalah masalah rapat-dengan-diri-sendiri. Pekerjaan yang memerlukan pikiran tanpa gangguan (rencana kuartalan tim Anda, tinjauan kinerja, keputusan arsitektur yang staff engineer Anda eskalasikan kepada Anda hari Jumat) tidak pernah memiliki tenggat waktu hari ini. Jadi selalu kalah dengan pekerjaan yang ada. Alert on-call. DM Slack dari engineer yang butuh pengganti. "Pertanyaan cepat" dari VP.

Sebagian besar EM kalah dalam pertarungan ini. Dokumen Q3 ditulis pukul 11 malam hari Minggu karena direktur Anda membutuhkannya Senin pagi. Tinjauan kinerja dijejalkan ke dalam minggu sebelum jatuh tempo, dan itu terlihat jelas.

Perbaikannya tidak glamor: pesan blok fokus di kalender Anda dan perlakukan seperti rapat eksternal. Tolak permintaan yang tumpang tindih. Terima bahwa beberapa minggu Anda akan kehilangan blok tersebut karena kebakaran nyata, dan itu tidak apa-apa, tapi default-nya harus dipertahankan. Engineer yang menjadi Senior EM dan Director adalah mereka yang belajar melindungi waktu berpikir mereka sendiri sebelum itu menjadi krisis.

Pukul 3.30 Siang: Notion Async, Bukan Slack Real-Time

Menjelang sore, otak Anda sudah lelah. Inilah saat Anda seharusnya melakukan pekerjaan dengan pikiran paling rendah namun volume paling tinggi: menulis dokumentasi yang ada di Notion dan tidak mengubah apa pun dalam hari Anda tetapi berkumpul selama dua kuartal ke depan.

Pembaruan panduan tim. Runbook on-call yang diminta engineer Anda dua minggu lalu. Catatan retrospektif dari sprint terakhir yang Anda janjikan untuk disebarluaskan. Dokumen kalibrasi hiring loop yang telah ditunggu rekruter Anda.

Tidak ada yang mendesak. Semuanya penting. Efek penggandaannya adalah enam bulan dari sekarang, ketika Anda orientasi engineer baru, mereka membaca tiga halaman Notion dan mulai dalam seminggu alih-alih menanyakan pertanyaan yang sama kepada tech lead Anda selama sebulan. Itulah leverage dari pekerjaan tertulis, dan itu tidak terlihat sampai Anda berhenti melakukannya dan menyaksikan tim melambat tanpa ada yang bisa menunjukkan alasannya.

Pukul 5.00 Sore: Pekerjaan Paket Promosi

Tim sudah logout. Anda membuka Notion. Anda sedang menulis dua berkas promosi (satu untuk engineer yang akan naik ke Senior, satu untuk engineer yang akan naik ke Staff) dan self-review untuk diri sendiri.

Berkas promosi adalah pekerjaan yang ditunda setiap hari sampai musim tinjauan kinerja datang seperti truk. Dan engineer yang dipromosikan adalah mereka yang manajernya menulis kasus tersebut sepanjang siklus, dengan bukti spesifik, bukan mereka yang manajernya menjejalkannya dalam satu akhir pekan dengan bahasa samar tentang "dampak yang terlihat."

Berikut potongan template Notion yang benar-benar berhasil:

## Kasus Promosi: [Nama] → [Level]

### Apa yang berubah dalam cakupan (2 kuartal terakhir)
- [Proyek spesifik, dikerjakan dari awal sampai akhir, dengan hasil terukur]
- [Kolaborasi lintas tim spesifik dengan hasil yang disebutkan]
- [Momen mentoring spesifik dengan nama mentee + hasil]

### Bukti bahwa level berikutnya sudah terjadi
- [Tautan ke desain doc yang mereka tulis]
- [Tautan ke insiden yang mereka pimpin]
- [Tautan ke umpan balik dari rekan/skip-level]

### Risiko yang akan diangkat panel (dan jawabannya)
- [Risiko]: [Jawaban yang sudah disiapkan]
- [Risiko]: [Jawaban yang sudah disiapkan]

### Permintaan kepada panel
- [Apa yang Anda ingin mereka pertimbangkan lebih/kurang berat]

Bagian risiko-dan-jawaban adalah yang paling sering dilewati manajer. Itulah yang menang. Panel promosi secara default skeptis, dan berkas yang mengantisipasi keberatan mereka melakukan 80% pekerjaan sebelum mereka membuka mulut.

Anda menyelesaikan berkas pertama pukul 5.51 sore. Anak Anda memiliki resital pukul 7. Anda akan mengerjakan berkas kedua besok, kecuali besok ada 1:1 yang Anda lupakan, tinjauan insiden, dan panel kandidat. Jadi Anda akan mengerjakannya Kamis. Mungkin.

Titik Infleksi Skalabilitas: 5 Engineer ke 9

Semua yang baru saya uraikan bekerja untuk 5 engineer. Rusak pada 9.

Pada 5, Anda dapat menyimpan setiap PR dalam kepala Anda. Anda dapat 1:1 mingguan dengan semua orang dan masih memiliki waktu untuk berpikir. Anda tahu siapa yang terhenti sebelum mereka bertanya, karena Anda bisa melihatnya dari bahasa tubuh standup.

Pada 9, Anda tidak bisa. Matematikanya tidak berhasil. Sembilan 1:1 30 menit mingguan adalah 4,5 jam; dengan persiapan dan tindak lanjut, itu satu hari penuh. PR yang dulu Anda lihat sekilas sekarang memerlukan filter tech lead sebelum mencapai Anda. Standup berhenti menjadi sinyal dan mulai menjadi teater status karena terlalu banyak suara.

Sistem yang Anda abaikan pada 5 menjadi tidak bisa ditawar pada 9: piagam tim tertulis agar anggota baru mengetahui standarnya, rotasi piket yang tidak bergantung pada memori Anda, rubrik perekrutan yang ada di luar kepala Anda, dan 1:1 yang menjadi dua mingguan untuk orang yang paling senior karena mereka paling tidak membutuhkannya dan mingguan untuk orang yang paling baru bergabung tim atau paling baru ke level senior.

Ketika Anda membuat pergeseran ke dua mingguan, seseorang merasa terabaikan. Katakan langsung mengapa. "Saya lebih ketat dari sebelumnya. Dua mingguan adalah yang bisa saya pertahankan. Jika ada yang mendesak, DM Slack saya terbuka dan saya akan merespons dalam satu jam." Kejujuran itu membeli lebih banyak niat baik daripada biaya 30 menit yang hilang.

Apa yang Salah dari Deskripsi Kerja

"Pimpin tim berkinerja tinggi" sebenarnya berarti:

• Lindungi fokus mereka. Sebagian besar hari Anda menyerap kekacauan agar mereka tidak harus melakukannya.
• Terjemahkan ambiguitas. Strategi eksekutif sengaja samar. Tim Anda butuh tiket, bukan vibes.
• Pertahankan waktu mereka. Mengatakan tidak pada "pertanyaan cepat" VP adalah bagian dari pekerjaan, bukan penghindaran.
• Tulis dok yang tidak akan ditulis siapa pun. Runbook, piagam, berkas promosi, ringkasan retro.
• Serap stres agar mereka tidak harus. Inilah inti tidak glamor dari peran ini dan bagian yang membuat orang kelelahan kerja.

Deskripsi kerja mengatakan "dorong hasil." Hari itu mengatakan "tulis halaman Notion yang berarti orang berikutnya tidak harus mencari tahu ini dari awal."

Penutup

Jika semua yang ada dalam artikel ini terdengar membangkitkan semangat (1:1 yang benar-benar Anda nantikan, kekacauan yang Anda nikmati untuk diterjemahkan, penggandaan lambat dari dokumentasi tertulis yang tidak akan dilakukan orang lain), Anda siap.

Jika terdengar menguras tenaga (Anda lebih suka men-ship kode daripada menyerap rapat, Anda lebih suka memecahkan masalah teknis yang sulit daripada masalah manusia), jalur IC bukan sebuah penurunan. Itu bentuk pekerjaan senior yang berbeda, dan industri akhirnya memberi penghargaan yang layak. JD Staff Software Engineer adalah pendamping artikel ini bukan tanpa alasan. Baca keduanya. Pilih yang bagian sulitnya bersedia Anda jalani selama lima tahun ke depan.

Jawaban yang benar adalah di mana hari-hari buruk masih terasa seperti pekerjaan yang layak dilakukan.

Pelajari Lebih Lanjut

• JD Staff Software Engineer (pendamping)
• Menjalankan 1:1 yang Tidak Ditakuti Engineer
• Transisi dari IC ke EM
• Menulis Berkas Promosi yang Benar-Benar Berhasil