Kemarin gw liat CV calon engineer buat phase alpha kita. Gelar Master IT, sertifikasi cloud, tiga tahun di unicorn Jakarta. Gw tawarin debugging session bareng. Dia nanggepin error log pakai pattern legacy yang udah mati lima tahun lalu. Dan bilang, "Emang gak bisa dipake buat arsitektur baru, Pak." Gw langsung tutup loker.
Kita Lagi Kebanyakan Ngebeli Brand, Bukan Potensi
Rekrutmen fase awal startup sering terjebak pada ritual baca CV kayak lagi scan barcode. "Wah dia pinter banget dari kampus A." "Dia pernah build sistem enterprise di sini." Beneran loh, itu justru bikin modal MVP lo habis lebih cepet dari prediksi. Lo butuh orang yang bisa nge-rush fitur dalam 3 hari, bukan yang mau diskusi arsitektur selama 2 minggu sebelum commit pertama.
Di stage alpha, product roadmap berubah tiap sprint. Kalau tim dev rigid, iterasi jadi PR berat. Yang terjadi? Fitur unggulan delay, client mulai ngeluh, dan lo malah harus bayarin biaya idle time sama developer yang "sudah ahli". Padahal yang kita butuhin cuma kecepatan adaptasi.
Bulan kemaren, client kita di segment F&B hampir abort project karena dev senior insist mau refactor auth module pake library X yang kompleks. Padahal spec asli cuma butuh login basic. Setelah gw geser tugasnya ke junior yang 'blissfully ignorant' tapi fast learner, fitur live dalam 4 hari. Belajar simpel: kecepatan often beats perfection di alpha.
Pengalaman gw sih sederhana: berhenti fokus pada gelar atau track record perusahaan besar. Mulai cari traceability mindset-nya lewat simulasi lapangan. Gw ganti proses seleksi jadi joint debugging. Gw kasih error code acak, terus liat respon mereka. Apakah langsung nyari jawaban di stackoverflow lama? Atau tanya konteks aplikasi, cek logs, dan coba break down problem step by step? Jawaban kedua biasanya menang. Itu tandanya ada ruang buat di-coach.
Mengapa "Senioritas" Sering Jadi Boomerang di Stage Alpha
Banyak founder takut hire junior atau career-switcher karena takut produktivitas turun di awal. Gw paham banget. Tapi coba pikir balik: developer senior yang kaku biasanya punya blind spot terbesar sendiri. Mereka nempel sama framework lama karena udah nyaman. Dikit-dikit bilang "pattern ini emang standar industri", padahal industri sekarang lari ke modular dan lightweight.
Gw punya kasus nyata bulan lalu. Tim kita hire frontend dev yang sebelumnya lead project di fintech. CV-nya mulus. Tapi pas masuk phase alpha, setiap kali gw usul ganti state management library, dia langsung defensive. "Itu mah kurang secure," kata dia, tanpa pernah uji benchmark dulu. Akibatnya? Two week sprint telat seminggu cuma karena debate teknis yang gak perlu.
Sebaliknya, gue pegang satu ex-graduat bootcamp yang baru kerja 8 bulan. Nggak banyak gelar, tapi kalau dapet PR baru, dia gercep baca dokumentasi, tanya klarifikasi, dan ngerjain PR-an kecil sambil belajar. Dalam sebulan, dia udah bisa handle API integration sendiri. Kualitas karyawan startup nggak diukur dari berapa banyak sertifikat di LinkedIn, tapi dari seberapa cepat mereka absorbing feedback dan eksekusi.
Hiring untuk agility di phase alpha bukan soal siapa yang paling berpengalaman di kertas. Ini soal siapa yang paling tahan banting pas spec berubah mendadak, dan bagaimana cara mereka navigate chaos tanpa panic.
Anti-Pattern: Nge-Coach Pakai Gaya Corporate Training
Lo pasti pernah lihat tim early-stage coba terapkan "training roadmap" ala korporat. Bulan pertama wajib ikut modul XYZ, bulan kedua harus dapet sertifikat B, bulan ketiga baru boleh nge-commit production code. Di stage alpha, itu bukan training — itu ngeblock kalender sekaligus nyiksa mental. Gw dulu pernah kecewa berat waktu hire dev yang ternyata butuh checklist approval bertingkat buat setiap PR kecil. Akibatnya? Two-week sprint jadi tiga minggu cuma karena proses birokrasi internal.
Coaching yang jalan justru sebaliknya: langsung terjun ke repo, pair programming real-time, dan kasih ruang buat salah di sandbox. Founder harus paham, fase alpha bukan tempat bikin SOP kaku. Ini tempat eksperimen cepat. Kalau lo mau tau siapa yang beneran adaptif, jangan tanya seberapa bagus presentasi learning path-nya. Lihat aja gimana dia handle ticket yang spec-nya berubah mendadak pas jam makan siang.
Drop Resume Screen, Langsung Test Respon Masalah
Kalau lo masih pakai sesi coding test bawaan LeetCode atau algoritma sorting, mungkin waktunya stop. Fase early-stage bukan ujian competitive programming. Ini ujian survival produk.
Gw personally ubah format wawancara jadi scenario-based. Contoh interview question efektif yang biasa gw pakai:
- "Lo nemu bug production jam 9 malam. Deadline client besok pagi. Langkah pertama lo apa?"
- "Gw minta lo refactor module X pakai framework Y yang belum pernah lo pegang. Estimasi waktu dan strategy lo gimana?"
- "Kalau tim design kasih Figma yang logic-nya bentrok sama dokumentasi API, lo komunikasi ke siapa duluan dan gimana caranya?"
Fakta pahitnya: mock coding test di atas layar doang ngasih ilusi kompetensi. Padahal di lapangan, 70% pekerjaan dev phase alpha adalah komunikasi, context-switching, dan ngadebug system yang belum punya monitoring proper. Kalau lo mau tahu level adaptabilitas mereka, kasih tantangan yang mirip real-world friction, bukan puzzle akademis.
Fakta Pahit Tentang Mitos "Full Stack"
Istilah "full stack developer" itu sebenernya marketing term yang udah kebawa terlalu jauh. Di dunia nyata, gak ada yang benar-benar jago frontend, backend, DevOps, testing, DAN product design sekaligus. Yang ada adalah T-shaped people atau generalist dengan satu area depth. Dan di phase alpha, kita butuh generalist yang humble, bukan specialist yang kaku.
Gw pernah ngerasa aneh juga waktu mutusin buat skip rekrutmen kandidat dengan 5 tahun pengalaman. Partner gw bilang, "Ntar susah manage-nya, Mas. Mereka biasanya sudah punya ego tinggi." Gw jawab simpel: "Tadi kita udah coba debug bareng. Ego-nya lebih gede dari capacity dia buat change direction." Jujur aja, di tahap bangun produk, yang mahal itu bukan salary. Yang mahal itu opportunity cost dari timeline yang kebentur pola pikir kaku.
Startups yang survive phase alpha biasanya punya budaya psychological safety yang kuat. Engineer harus berani bilang "gw belum tau, tapi weekend ini gw belajar". Bukan berani claim expert di segala hal. Founder yang mikro-manage teknis bakal burnout duluan. Founder yang delegate learning cycle bakal see product ship.
Red Flag Pas Pair Programming Session
Kalau lo masih ngedenger "tunggu sampai release candidate baru" pas tengah sprint berjalan, itu tanda bahaya. Di phase alpha, perubahan requirement itu normal, bukan exception. Developer yang resisten biasanya punya satu alasan klasik: takut tanggung jawab kalau hasil akhir meledak. Tapi paradoxnya, semakin mereka nahan diri buat adaptasi, semakin besar risiko technical debt yang numpuk.
Gw selalu kasih rule sederhana di sesi pairing: "Lo bisa beda pendapat soal implementasi, tapi kalau decision udah final, eksekusi tanpa drama." Hasilnya? Repo commit-nya lebih bersih, dan time-to-review turun drastis. Jangan lupa, coaching itu bukan tentang bikin orang setuju sama lo. Ini tentang bikin sistem feedback-nya jalan cepet.
Di SatuTim kita rekomen fitur Brief biar requirement nggak ngeblur dan coaching path-nya ketahuan jelas. Jadi kalau lo mau develop internal talent, traceability-nya tetap bisa dilacak tanpa harus rely sepenuhnya pada "master of all trades". Task gantung berkurang, review-an jadi transparent, dan feedback looping-nya kenceng.
Kalau lo pengen coba pendekatan ini, di SatuTim ada fitur Discussions buat async review logic atau sharing insight technical. Jadi proses coaching-nya tercatat, transparan, dan ga perlu meeting panjang yang cuma buang waktu. Gw pribadi suka pake itu buat narik thread perbaikan dari junior dev ke senior, tanpa harus nunggu slot standup yang sering molor.
Coba minggu ini: ganti satu sesi screening berikutnya jadi joint debugging atau scenario question. Catat berapa menit waktu yang lo save dari debate teknis, versus hasil iterate yang actually shipped.
Kalau tim dev lo di phase alpha masih sibuk ngebela pattern lama daripada ngerush feature baru — symptom utamanya biasanya dari mana? Dari gap di proses hiring, atau dari culture yang nggak ngasih ruang buat fail fast?