1. Mengapa Memilih Jalur Management?
Banyak software engineer yang pada titik tertentu dalam karirnya menghadapi pertanyaan besar: "Apakah saya harus masuk ke management?" Ini bukan keputusan yang sepele, karena jalur management dan jalur individual contributor (IC) sangat berbeda dalam hal skill yang dibutuhkan, aktivitas sehari-hari, dan dampak yang diberikan.
Di Indonesia, khususnya di startup dan perusahaan teknologi, transisi ke management seringkali terjadi terlalu cepat — seseorang yang jago coding langsung dipromosikan jadi manager tanpa persiapan memadai. Ini yang disebut "The Peter Principle": dipromosikan sampai level ketidakmampuan.
1.1 Motivasi yang Benar vs Salah
| ✅ Motivasi yang Benar | ❌ Motivasi yang Salah |
|---|---|
| Ingin dampak yang lebih besar melalui orang lain | Hanya karena gaji lebih tinggi |
| Menikmati membantu orang lain berkembang | "Sudah waktunya" — merasa wajib |
| Tertarik pada strategi dan organisasi | Ingin otoritas dan kontrol |
| Memahami bahwa skill berbeda perlu dipelajari | Mengira bisa terus coding seperti biasa |
| Ingin membangun budaya engineering yang baik | Bosan coding, ingin sesuatu yang baru |
Jika Anda sudah secara natural membantu junior, memperhatikan bagaimana tim berkolaborasi, dan merasa frustrasi ketika proses/keputusan organisasi menghambat produktivitas tim — itu tanda bahwa Anda punya "management instinct".
2. Perbedaan Developer vs Engineering Manager
Perbedaan paling fundamental: developer sukses melalui kode yang ditulis sendiri, manager sukses melalui kesuksesan timnya. Ini pergeseran mindset yang radikal dan seringkali menjadi sumber frustrasi terbesar bagi new manager.
Metric: PR merged, bugs fixed
Fokus: How to build it
Success: Sistem bekerja
Metric: team velocity, retention
Fokus: What & why to build
Success: Tim berkembang
2.1 Aktivitas Sehari-hari
# === SENIN === # 09:00 - Email/Slack review, prioritas minggu ini # 09:30 - 1-on-1 dengan Developer A (career growth) # 10:00 - 1-on-1 dengan Developer B (technical blocker) # 10:30 - Sprint Planning dengan Product Manager # 12:00 - Lunch (kadang meeting informal) # 13:00 - Review PR (bukan merge, tapi code quality check) # 13:30 - Hiring: Screen calon candidate baru # 14:30 - Cross-team meeting: Alignment dengan Backend team # 15:30 - Write: Technical design doc untuk proyek Q3 # 16:30 - Slack: Answer questions, unblock team # 17:00 - Planning: 1-on-1 notes, follow-up items # === RASIO WAKTU (ideal) === # People management (1:1, coaching, feedback) → 40% # Planning & strategy (roadmap, prioritization) → 25% # Technical (design review, code review, arch) → 20% # Hiring & team building → 10% # Administrative (meetings, reporting) → 5% # === PERINGATAN === # Banyak new manager yang masih menghabiskan 60-70% # waktu untuk coding. Ini RED FLAG. # Jika Anda masih coding mayoritas waktu, Anda belum # benar-benar menjadi manager — Anda adalah "dev dengan # tanggung jawab managerial yang terbengkalai".
3. People Management Fundamentals
People management adalah skill yang bisa dipelajari, bukan bakat bawaan. Berikut fondasi yang perlu dikuasai:
3.1 Memahami Setiap Anggota Tim
- Strengths & Growth Areas: Setiap orang punya kekuatan dan area yang perlu dikembangkan. Kenali ini dan assign work yang memanfaatkan strengths mereka sambil memberi kesempatan growth.
- Career Goals: Apa yang ingin dicapai setiap anggota tim dalam 1-2 tahun ke depan? Seorang developer mungkin ingin jadi tech lead, yang lain ingin belajar data engineering. Bantu mereka ke sana.
- Motivation Drivers: Ada yang termotivasi oleh challenge teknis, ada yang oleh impact bisnis, ada yang oleh work-life balance. Kenali dan sesuaikan pendekatan Anda.
- Communication Style: Ada yang suka feedback langsung, ada yang butuh pendekatan halus. Ada yang produktif di meeting, ada yang lebih suka async.
3.2 Delegation Framework
# === DELEGATION MATRIX === # Berdasarkan COMPETENCE (kemampuan) dan COMMITMENT (motivasi) # Level 1: LOW Competence, HIGH Commitment (Enthusiastic Beginner) # → DIRECTING: Berikan instruksi detail, check frequently # → Contoh: Junior developer baru, eager tapi belum tahu banyak # → Anda: "Lakukan langkah 1, 2, 3. Hubungi saya setelah selesai." # Level 2: SOME Competence, LOW Commitment (Disillusioned Learner) # → COACHING: Berikan arahan + support emosional # → Contoh: Developer yang mulai frustasi karena banyak error # → Anda: "Ini tujuannya. Bagaimana menurutmu pendekatan terbaik?" # Dengarkan, berikan saran, tapi biarkan mereka memutuskan. # Level 3: HIGH Competence, VARIABLE Commitment (Capable but Cautious) # → SUPPORTING: Facilitate, biarkan mereka memimpin # → Contoh: Senior dev yang kompeten tapi kurang percaya diri di area baru # → Anda: "Saya percaya Anda bisa. Apa yang Anda butuhkan dari saya?" # Level 4: HIGH Competence, HIGH Commitment (Self-reliant Achiever) # → DELEGATING: Lepaskan, berikan ownership penuh # → Contoh: Staff engineer yang sudah terbukti # → Anda: "Ini goal-nya. Saya trust Anda. Update saya minggu depan." # KESALAHAN PALING UMUM: # - Micro-manage orang Level 4 → mereka akan resign # - Melepas orang Level 1 → mereka akan gagal dan frustasi # - Tidak adjust style sesuai perkembangan orang
3.3 Membangun Psychological Safety
Tim yang aman secara psikologis berani mengambil risiko, mengakui kesalahan, dan menyampaikan ide tanpa takut dihakimi. Ini adalah prediktor #1 dari tim yang berperforma tinggi (berdasarkan riset Google's Project Aristotle).
- Normalisasi failure: Saat seseorang melakukan kesalahan, fokus pada pembelajaran, bukan blame
- Lead by example: Akui kesalahan Anda sendiri di depan tim
- Invite dissent: "Apakah ada yang punya pandangan berbeda?" harus menjadi pertanyaan wajib
- Respond gracefully: Saat seseorang bertanya "bodoh", jawab dengan hormat. Tim akan melihatnya.
4. Seni 1-on-1 Meeting
1-on-1 meeting adalah alat paling powerful dalam toolkit engineering manager. Ini bukan status update — ini adalah ruang aman untuk anggota tim membahas apa pun yang menghambat mereka.
4.1 Struktur 1-on-1 yang Efektif
# === TEMPLATE 1-ON-1 === # Frekuensi: Mingguan atau 2-mingguan # Durasi: 30-45 menit (JANGAN kurang dari 30 menit) # Lokasi: Walk & talk / coffee / ruangan privat # (HINDARI meeting room formal — terlalu kaku) # AGENDA: # [5 menit] — Check-in personal # "Gimana weekend-nya?" # "Anaknya sudah sembuh?" # Ini bukan basa-basi — ini membangun relasi. # [10 menit] — Topik dari anggota tim (MEREKA yang mulai) # "Ada yang mau kamu bahas hari ini?" # "Ada blocker atau hal yang bikin frustrasi?" # Biarkan mereka yang mengisi. Manager = listener 70% dari waktu. # [10 menit] — Topik dari Anda # Feedback terbaru (positif atau area improvement) # Update organisasi yang relevan # Career development discussion # [5 menit] — Action items & follow-up # "Jadi, kita sepakat: kamu akan coba approach X." # "Saya akan follow-up dengan Tim Y tentang masalah Z." # Tulis notes dan review sebelum 1-on-1 berikutnya. # === PERTANYAAN YANG BAGUS === # "Apa yang paling kamu nikmati dari pekerjaan minggu ini?" # "Jika kamu bisa mengubah satu hal tentang tim kita, apa?" # "Ada skill yang ingin kamu develop?" # "Apakah kamu merasa workload-nya sustainable?" # "Apakah ada sesuatu yang menghambatmu tapi kamu belum bicarakan?" # "Dalam skala 1-10, seberapa puas kamu dengan pekerjaanmu? Kenapa bukan 10?" # === YANG HARUS DIHINDARI === # ❌ Jadikan 1-on-1 jadi status update # ❌ Membatalkan 1-on-1 (pesan: "kamu tidak penting") # ❌ Monolog 20 menit tentang apa yang Anda lakukan # ❌ Tidak ada follow-up dari meeting sebelumnya
Membatalkan 1-on-1 mengirim pesan bahwa anggota tim Anda tidak prioritas. Jika memang terpaksa, reschedule di hari yang sama, dan minta maaf. Konsistensi 1-on-1 adalah investasi terbaik untuk trust dan retention.
5. Memberikan & Menerima Feedback
Feedback adalah "bread and butter" seorang manager. Kemampuan memberikan feedback yang constructive — dan menerima feedback dengan lapang dada — adalah skill yang membedakan manager yang baik dari yang biasa.
5.1 Framework SBI (Situation-Behavior-Impact)
# === SBI FRAMEWORK === # Situation: Kapan/kejadian apa? # Behavior: Apa yang dilakukan? (observasi, bukan interpretasi) # Impact: Apa dampaknya? (pada tim, proyek, atau individu) # CONTOH POSITIVE FEEDBACK: # "Dalam sprint review kemarin [Situation], # kamu menjelaskan arsitektur baru dengan sangat jelas # dan sabar menjawab semua pertanyaan [Behavior], # sehingga seluruh stakeholder jadi paham dan support # rencana kita [Impact]. Great job!" # CONTOH CONSTRUCTIVE FEEDBACK: # "Dalam code review minggu ini [Situation], # saya perhatikan kamu memberikan komentar yang cukup # tajam di PR junior developer, seperti 'kode ini jelek' [Behavior], # dan developer tersebut jadi malu untuk submit PR lagi [Impact]. # Bagaimana menurutmu kita bisa memberikan feedback yang # lebih supportive?" # === TIPS MEMBERIKAN FEEDBACK === # 1. Berikan SECEPATNYA — jangan tunggu performance review # 2. Private untuk kritik, public untuk pujian # 3. Spesifik — hindari generalisasi seperti "kamu selalu..." # 4. Fokus pada behavior, bukan personality # 5. Berikan contoh konkret + suggestion improvement # 6. Pastikan ada 2 arah — minta perspektif mereka # === MENERIMA FEEDBACK === # Saat menerima feedback dari tim atau atasan: # 1. Dengarkan tanpa interrupting # 2. Jangan langsung defensive # 3. Katakan: "Terima kasih, saya akan pikirkan ini." # 4. Refleksi — apakah ini valid? # 5. Follow-up dengan action plan
5.2 Performance Review yang Adil
- Jangan surprise: Tidak ada hal baru di performance review yang belum pernah dibahas di 1-on-1
- Gunakan data: Catatan dari 1-on-1, PR review, project outcome — bukan "feeling"
- Tulis sebelum meeting: Minta anggota tim menulis self-assessment dulu
- 360 feedback: Kumpulkan input dari rekan kerja, bukan hanya Anda
6. Hiring & Membangun Tim
Hiring adalah salah satu tanggung jawab paling penting seorang engineering manager. Satu hire yang buruk bisa menghabiskan 6-12 bulan produktivitas tim. Berikut best practices:
6.1 Proses Hiring yang Efektif
# === HIRING PIPELINE === # STAGE 1: Job Description & Sourcing # - Tulis JD yang jelas: responsibilities, tech stack, growth path # - Hindari "rockstar" atau "ninja" — ini red flag # - Sourcing: LinkedIn, referral dari tim, komunitas, job fair # - Referral biasanya menghasilkan hire terbaik # STAGE 2: Resume Screening (1-2 menit per resume) # - Cari: relevansi tech stack, progression, impact # - Abaikan: nama universitas, GPA (jika pengalaman > 3 tahun) # - Red flag: loncat kerja setiap < 1 tahun tanpa penjelasan # STAGE 3: Phone Screen (30 menit) # - Konfirmasi: motivasi, ekspektasi gaji, availability # - Tanya: "Ceritakan proyek yang paling kamu banggakan" # - Goal: Filter 30% kandidat yang jelas tidak cocok # STAGE 4: Technical Interview (2-3 ronde) # - Coding test: data structures, algorithms (45-60 menit) # - System design: arsitektur, trade-off (45-60 menit) # - Practical: debug real code / design API (opsional) # STAGE 5: Behavioral Interview (45 menit) # - STAR method: Situation, Task, Action, Result # - Pertanyaan: "Ceritakan konflik dengan rekan kerja" # - Goal: Cultural fit, communication, problem solving # STAGE 6: Hiring Committee & Offer # - Debrief: semua interviewer diskusi bersama # - Gunakan scorecard, bukan "gut feeling" # - Offer letter dengan detail kompensasi
6.2 Pertanyaan Interview yang Bagus vs Buruk
| ✅ Pertanyaan Bagus | ❌ Pertanyaan Buruk |
|---|---|
| "Ceritakan proyek yang gagal. Apa yang kamu pelajari?" | "Apa kelemahanmu?" |
| "Bagaimana kamu menangani disagreement dengan tech lead?" | "Kamu tipe leader atau follower?" |
| "Jelaskan trade-off dari keputusan arsitektur yang kamu buat" | "Berapa tahun pengalamanmu dengan React?" |
| "Bagaimana kamu memprioritaskan task saat semua urgent?" | "Di mana kamu melihat diri 5 tahun lagi?" |
7. Dilema Tech vs People
Sal satu konflik terbesar yang dihadapi engineering manager baru adalah kehilangan koneksi teknis. Anda dulu menulis kode setiap hari, sekarang sebagian besar waktu dihabiskan untuk meeting. Ini bisa membuat Anda merasa tidak "berguna" secara teknis.
7.1 Seberapa Teknis Harus Seorang EM?
- Small company (<50 engineer): EM biasanya masih sangat teknis, bahkan masih coding 20-30% waktu
- Medium company (50-200 engineer): EM fokus pada people + process, tapi harus paham teknologi yang dipakai tim
- Large company (>200 engineer): EM hampir 100% people management, technical decisions di-delegate ke Staff/Principal engineer
# === KEPUTUSAN YANG HARUS ANDA BUAT === # ANDA HARUS TEKNIS ketika: # ✅ Meng-review technical design doc # ✅ Membuat keputusan arsitektur tingkat tinggi # ✅ Mengevaluasi trade-off teknis untuk roadmap # ✅ Mentoring developer junior secara teknis # ✅ Memahami blocker teknis yang dilaporkan tim # ANDA HARUS DELEGAASI ketika: # 🔶 Implementasi kode harian → lead developer # 🔶 Code review detail → senior engineer # 🔶 Pemilihan library/framework spesifik → tech lead # 🔶 Debugging production issue → on-call engineer # 🔶 Sprint task assignment → engineering lead + tim # ANDA HARUS FOKUS PEOPLE ketika: # 👥 1-on-1 dan coaching # 👥 Performance management # 👥 Hiring dan team building # 👥 Cross-team collaboration # 👥 Budaya dan process improvement # 👥 Protecting tim dari distraksi # TIPS: Tetap "technically current" dengan: # - Membaca tech blog dan design doc # - Menghadiri tech talks internal # - Sesekali ikut mob programming / pair programming # - Tapi JANGAN jadi bottleneck di production code
Jika Anda ingin tetap teknis tapi tetap punya dampak organisasi yang besar, pertimbangkan jalur Staff+ Engineer (Staff Engineer, Principal Engineer, Distinguished Engineer). Di jalur ini, Anda tetap coding dan membuat keputusan arsitektur, tapi juga mempengini teknis organisasi tanpa people management langsung.
8. Kesalahan Umum New Engineering Manager
8.1 The "Super IC" Trap
Anda masih coding 60% waktu karena "cepat" atau "lebih baik saya yang kerjakan". Akibatnya: tim tidak berkembang, Anda burnout, dan tanggung jawab managerial terbengkalai. Solusi: resist the urge, beri kesempatan tim untuk belajar bahkan jika lebih lambat.
8.2 Avoiding Difficult Conversations
Ada anggota tim yang performanya rendah tapi Anda tidak berani membicarakannya. Ini memperburuk situasi: yang lain merasa tidak adil, standar tim turun. Solusi: SBI framework + lakukan secepatnya.
8.3 Trying to Be Everyone's Friend
Anda ingin disukai semua orang, jadi tidak pernah memberikan feedback negatif. Akibatnya: tim tidak tahu area yang perlu diperbaiki. Solusi: Anda bisa friendly tapi tetap harus fair dan firm.
8.4 Not Delegating Enough
Anda menghandle semua escalations, semua decision, semua stakeholder meeting. Tim jadi tidak punya ownership. Solusi: gunakan delegation matrix di Section 3.2.
8.5 Neglecting Self-Care
Manager yang burnout = tim yang menderita. Anda adalah "shock absorber" untuk tim — jika Anda tidak sehat, seluruh tim terdampak. Solusi: jadwalkan waktu untuk diri sendiri, set boundaries, dan cari mentor/peer group sesama manager.
9. Resources & Buku Rekomendasi
| Buku | Penulis | Fokus |
|---|---|---|
| The Manager's Path | Camille Fournier | Transisi dari tech lead ke VP Eng |
| An Elegant Puzzle | Will Larson | Engineering management di perusahaan besar |
| High Output Management | Andy Grove | Klasik — management dari Intel CEO |
| Radical Candor | Kim Scott | Komunikasi feedback yang efektif |
| The Making of a Manager | Julie Zhuo | Pengalaman langsung jadi manager muda di Facebook |
| Peopleware | DeMarco & Lister | Manusia, bukan teknologi, adalah bottleneck |
9.1 Community & Peer Learning
- Rands Leadership Slack: Komunitas engineering leader global
- Engineering Managers Slack (EMSlack): Forum diskusi sesama EM
- LeadDev: Blog dan conference untuk engineering leaders
- Indonesia Engineering Leadership Meetup: Komunitas lokal (jika ada)