Peran Tech Lead: Antara Kode dan Arsitektur

1. Apa Itu Tech Lead?

Tech Lead adalah posisi unik yang berada di persimpangan antara individual contributor (IC) dan leadership. Tech Lead tetap teknis — masih coding, masih review kode — tapi juga bertanggung jawab atas keputusan arsitektur, quality code, dan mentoring tim secara teknis.

Berbeda dari Engineering Manager yang fokus pada people management, Tech Lead fokus pada technical excellence tim. Anda adalah orang yang tim datangi ketika ada masalah teknis yang kompleks, atau ketika ada perdebatan tentang pendekatan mana yang lebih baik.

1.1 Tanggung Jawab Utama Tech Lead

• Technical Decision Making: Memilih teknologi, framework, dan arsitektur untuk proyek
• Code Quality Guardian: Memastikan standar kode, melakukan code review, setup CI/CD
• Architecture Design: Merancang arsitektur sistem yang scalable dan maintainable
• Mentoring: Membantu developer junior dan mid tumbuh secara teknis
• Technical Roadmap: Merencanakan perbaikan teknis, refactoring, tech debt reduction
• Cross-team Technical Coordination: Bekerja dengan team lain untuk alignment teknis
• Risk Identification: Mengidentifikasi risiko teknis sebelum menjadi masalah

2. Tech Lead vs Engineering Manager

Di beberapa perusahaan, Tech Lead dan Engineering Manager adalah orang yang sama. Di perusahaan besar, mereka adalah role terpisah yang saling melengkapi:

3. Technical Decision Making

Salah satu tanggung jawab terbesar Tech Lead adalah membuat keputusan teknis yang tepat. Ini termasuk memilih bahasa pemrograman, framework, database, cloud provider, dan berbagai keputusan arsitektur lainnya.

3.1 Framework Keputusan Teknis

# === FRAMEWORK PENGAMBILAN KEPUTUSAN TEKNIS ===

# STEP 1: IDENTIFY THE PROBLEM
# - Apa sebenarnya masalah yang perlu diselesaikan?
# - Siapa yang terdampak oleh keputusan ini?
# - Apa constraints-nya (budget, waktu, skill tim)?

# STEP 2: GATHER OPTIONS
# - Minimal 2-3 alternatif
# - Contoh: "React vs Vue vs Svelte untuk frontend baru"
# - Riset: dokumentasi, benchmark, case studies

# STEP 3: EVALUATE TRADE-OFFS
# Gunakan criteria matrix:
#
# Criteria        | Weight | React | Vue | Svelte
# Performance     | 20%    | 7     | 8   | 9
# Learning curve  | 15%    | 7     | 9   | 6
# Ecosystem       | 25%    | 9     | 8   | 5
# Hiring pool     | 20%    | 9     | 7   | 3
# Team experience | 20%    | 8     | 5   | 2
# ------------------------------------------------
# Weighted Score  |        | 7.95  | 7.35| 5.1

# STEP 4: DOCUMENT THE DECISION
# Gunakan ADR (Architecture Decision Record) — lihat Section 4

# STEP 5: COMMUNICATE & ALIGN
# - Present ke tim: bukan "ini keputusan saya" tapi
#   "ini trade-off-nya, ini alasan saya memilih X"
# - Beri kesempatan untuk dissent
# - Jika tidak ada consensus, Tech Lead membuat final call

# STEP 6: REVISIT PERIODICALLY
# - Keputusan yang tepat hari ini belum tentu tepat 1 tahun lagi
# - Schedule quarterly tech review

3.2 Prinsip Keputusan yang Baik

• Reversible vs Irreversible: Keputusan reversible (ganti CSS framework) — buat cepat. Keputusan irreversible (pilih database primary) — buat hati-hati.
• Two-way door vs One-way door: Jeff Bezos mempopulerkan konsep ini. Two-way door (bisa balik) = ambil cepat. One-way door (sulit balik) = pikir matang.
• Bias for action: Tidak ada keputusan yang sempurna. Keputusan yang "cukup baik" yang diambil tepat waktu lebih baik dari keputusan "sempurna" yang terlambat.
• Disagree and commit: Jika tim tidak sepakat setelah diskusi yang wajar, Tech Lead membuat call — dan seluruh tim commit meskipun tidak semua setuju.

4. Architecture Decision Records (ADR)

ADR adalah dokumen ringkas yang mencatat keputusan arsitektur penting beserta konteks dan konsekuensinya. ADR membantu tim memahami MENGAPA suatu keputusan dibuat — bukan hanya APA yang diputuskan.

# ADR-001: Pilih PostgreSQL sebagai Database Primary

## Status: Accepted
## Date: 2026-06-15
## Deciders: Tech Lead, Senior Backend Engineer

## Context
Kita sedang membangun sistem e-commerce baru. Butuh database
utama untuk menyimpan data produk, order, user, dan inventory.
Tim punya 3 orang yang familiar dengan PostgreSQL, 1 orang
dengan MongoDB, 0 orang dengan Cassandra.

## Decision
Kita memilih **PostgreSQL** sebagai database primary.

## Alternatives yang Dipertimbangkan

### 1. PostgreSQL (Dipilih)
**Pro:**
- ACID compliant — critical untuk data transaksi
- Rich query (JOIN, CTE, window functions)
- JSON support untuk data semi-struktur
- Mature ecosystem, tooling, monitoring
- Tim sudah familiar
**Con:**
- Horizontal scaling lebih kompleks dibanding NoSQL

### 2. MongoDB
**Pro:**
- Flexible schema, mudah untuk prototyping
- Horizontal scaling built-in
**Con:**
- Tim kurang familiar — learning curve
- ACID transaction baru di v4.0, kurang mature
- JOIN support terbatas

### 3. Cassandra
**Pro:**
- Write throughput sangat tinggi
- Linear horizontal scaling
**Con:**
- Data model CQL — tim perlu belajar dari nol
- Tidak cocok untuk query kompleks
- Overkill untuk skala saat ini

## Consequences
- Tim perlu setup PostgreSQL HA (replication + failover)
- Pertimbangkan Citus extension jika perlu sharding di masa depan
- Dokumentasi schema dan query pattern harus dibuat
- Monitor query performance dari awal

## Review Date
Keputusan ini akan di-review ulang dalam 12 bulan
atau saat mencapai 10 juta records.

4.1 Mengapa ADR Penting?

• Knowledge transfer: Orang baru di tim bisa memahami alasan di balik keputusan
• Avoid repeating debates: "Kita sudah pernah diskusi ini dan memilih X karena..."
• Accountability: Keputusan terdokumen, ada konteks, ada trade-off
• Historical record: Bisa melihat evolusi keputusan teknis dari waktu ke waktu

5. Code Review yang Efektif

Code review adalah salah satu aktivitas paling berpengaruh seorang Tech Lead. Review yang baik bukan hanya menemukan bug — ini adalah kesempatan untuk mentoring, menerapkan standar, dan memastikan konsistensi arsitektur.

5.1 Checklist Code Review

# === CHECKLIST CODE REVIEW ===

# 1. CORRECTNESS
# ☐ Apakah kode melakukan yang seharusnya?
# ☐ Apakah ada edge cases yang terlewat?
# ☐ Apakah error handling memadai?
# ☐ Apakah ada race condition atau concurrency issue?

# 2. DESIGN & ARCHITECTURE
# ☐ Apakah kode mengikuti arsitektur yang sudah ada?
# ☐ Apakah abstraction level yang tepat?
# ☐ Apakah ada violation of SOLID principles?
# ☐ Apakah ada unnecessary complexity?

# 3. PERFORMANCE
# ☐ Apakah ada N+1 query?
# ☐ Apakah ada memory leak potential?
# ☐ Apakah ada unnecessary computation dalam loop?
# ☐ Apakah indexing di database sudah optimal?

# 4. SECURITY
# ☐ Apakah ada SQL injection, XSS, CSRF?
# ☐ Apakah secrets/password tidak hardcoded?
# ☐ Apakah input validation memadai?
# ☐ Apakah auth check di setiap endpoint?

# 5. MAINTAINABILITY
# ☐ Apakah naming conventions konsisten?
# ☐ Apakah ada code duplication yang bisa di-refactor?
# ☐ Apakah function terlalu panjang (>50 baris)?
# ☐ Apakah ada TODO/FIXME yang perlu ditrack?

# 6. TESTING
# ☐ Apakah ada unit test untuk logic baru?
# ☐ Apakah edge cases ter-test?
# ☐ Apakah integration test untuk API baru?
# ☐ Apakah test bisa dijalankan dengan cepat?

# 7. DOCUMENTATION
# ☐ Apakah complex logic ada komentar?
# ☐ Apakah API baru ada dokumentasi?
# ☐ Apakah README di-update jika perlu?
# ☐ Apakah ADR dibuat untuk keputusan desain?

5.2 Seni Memberikan Feedback Code Review

• Ask questions, don't give orders: "Apakah kita perlu error handling di sini?" lebih baik dari "Tambahkan error handling!"
• Explain why: Jelaskan alasan di balik saran — ini membantu author belajar
• Separate blocking vs non-blocking: Tandai mana yang wajib diperbaiki vs nice-to-have
• Praise good code: "Clean approach!" atau "Nice use of pattern X" — ini memotivasi
• Respond promptly: Review dalam 24 jam. PR yang menggantung lebih dari sehari = productivity drain.

6. Mentorship & Knowledge Sharing

Sebagai Tech Lead, Anda bertanggung jawab atas pertumbuhan teknis tim. Ini dilakukan melalui mentorship formal dan informal:

6.1 Program Mentorship

• Pair programming: Coding bersama developer junior, ajarkan pattern dan approach
• Tech talks internal: Present topik teknis setiap 2 minggu (Anda atau anggota tim)
• Book club: Baca buku teknis bersama (misal: "Clean Architecture" atau "DDIA")
• Architecture review: Libatkan mid-senior dev dalam diskusi arsitektur
• Stretch assignments: Beri task yang sedikit di atas kemampuan saat ini

6.2 Knowledge Sharing Culture

• Runbooks: Tulis step-by-step untuk prosedur umum (deploy, rollback, on-call response)
• Post-mortems: Setelah incident, tulis post-mortem yang blameless dan share ke seluruh tim
• Internal wiki: Document keputusan, arsitektur, dan best practices di satu tempat
• Code walkthrough: Saat fitur besar selesai, author present ke tim bagaimana kodenya bekerja

7. Membangun Technical Vision

Technical vision adalah gambaran besar tentang arah teknis tim dalam 6-12 bulan ke depan. Ini membantu tim membuat keputusan yang konsisten dan menghindari "architecture by accident".

# === TECHNICAL VISION — TIM E-COMMERCE ===
# Periode: H2 2026 - H1 2027

## Current State (Hari Ini)
# - Monolith Rails application
# - PostgreSQL primary, 1 read replica
# - Deploy manual ke VPS
# - ~50K requests/day
# - Tech debt: authentication system legacy, no caching

## Vision (12 Bulan dari Sekarang)
# - Extract 3 critical services: Auth, Order, Payment
# - Event-driven architecture dengan Kafka
# - Full CI/CD pipeline, deploy otomatis
# - Handle 500K requests/day
# - Redis caching layer untuk product catalog
# - Observability: metrics, logs, traces

## Quarterly Milestones
# Q3 2026:
#   - Extract Auth service (JWT + OAuth2)
#   - Setup CI/CD pipeline (GitHub Actions)
#   - Implement Redis caching
# Q4 2026:
#   - Extract Order service
#   - Setup Kafka untuk event streaming
#   - Monitoring & alerting (Grafana + Prometheus)
# Q1 2027:
#   - Extract Payment service
#   - Performance optimization & load testing
#   - Documentation & runbook update

## Migration Strategy
# - Strangler Fig pattern: extract service satu per satu
# - Tidak ada "big bang rewrite"
# - Setiap extraction: feature flag → canary → full traffic
# - Rollback plan untuk setiap milestone

## Risks & Mitigations
# - Risk: Tim belum experienced dengan microservices
#   Mitigation: Training + start dengan service yang simpel
# - Risk: Data consistency antar service
#   Mitigation: Saga pattern, event sourcing

8. Tetap Hands-On: Berapa Banyak Coding?

Ini adalah pertanyaan yang paling sering ditanyakan oleh Tech Lead baru: "Apakah saya masih perlu coding?" Jawabannya: YA, tapi dengan porsi dan fokus yang berbeda.

9. Tantangan Umum Tech Lead

9.1 Managing Up

Anda perlu "menjual" keputusan teknis ke management yang mungkin tidak paham teknis. Skill yang dibutuhkan: translate masalah teknis ke bahasa bisnis. Alih-alih "kita butuh refactor database", katakan "kita perlu investasi 2 minggu untuk optimasi database agar bisa handle 10x traffic saat diskon akhir tahun".

9.2 Tech Debt Management

Tech debt tidak bisa dihilangkan — hanya dikelola. Alokasikan 20% capacity sprint untuk tech debt reduction. Prioritaskan tech debt yang paling menghambat velocity tim, bukan yang paling "menarik" secara teknis.

9.3 Dealing with Differing Opinions

Akan ada saatnya anggota tim (terutama senior) tidak setuju dengan keputusan Anda. Ini normal dan sehat. Proses yang baik: diskusi terbuka → evaluasi trade-off → Tech Lead membuat final call → semua commit. Jangan ambil pusing secara personal.

9.4 Scope Creep in Technical Work

Refactoring yang awalnya "hanya 2 hari" jadi 2 minggu karena "sambil jalan, kita juga perbaiki ini dan itu". Solusi: tulis scope yang jelas sebelum mulai, dan tangani "nice to have" di iteration berikutnya.