Di dunia startup IoT (Internet of Things) dan AI (Artificial Intelligence), inovasi berjalan secepat ekspektasi klien. Sebagai pengambil keputusan, kita dituntut untuk terus memacu pertumbuhan pendapatan (ARR) sambil memastikan arsitektur teknologi tidak runtuh di tengah jalan. Namun, di balik angka-angka valuasi dan baris kode program, ada satu dinamika manusiawi yang paling sering memicu suhu panas di ruang rapat: gesekan antara tim Business Development (BD) atau Sales dengan tim Engineering.
Terutama ketika berhadapan dengan proyek-proyek custom berbayar tinggi, dinamika ini bukan sekadar soal gaya komunikasi. Ini adalah benturan dua dunia dengan target KPI yang sangat berbeda.
Mengapa Proyek Teknologi Sering Gagal di Tengah Jalan?
Sebuah riset industri yang dirilis oleh Cisco mengungkapkan fakta yang mengejutkan: hampir 74% inisiatif proyek IoT di perusahaan berakhir dengan kegagalan. Menariknya, salah satu akar masalah terbesar bukanlah keterbatasan teknologi itu sendiri, melainkan disconnect antara ekspektasi bisnis dan realitas teknis di lapangan. Ironisnya, sebagian solusinya justru ada di tangan kita secara harfiah — memahami cara memanfaatkan AI di pekerjaan sehari-hari sudah cukup untuk mempersempit kesenjangan itu secara nyata.
Sumber: Cisco IoT Survey 2017
Paradoks Menjual Masa Depan vs. Membangun Realitas
Bayangkan skenario yang cukup lazim terjadi: Tim Business Development berhasil memenangkan sebuah proyek strategis dari klien korporat. Untuk mengamankan kontrak tersebut, disepakati penambahan beberapa fitur custom — misalnya, penyesuaian dashboard pelaporan yang sangat spesifik atau integrasi data dengan sistem legacy milik klien — dengan target implementasi yang cukup ketat.
Namun, ketika dokumen kerja ini tiba di meja tim Engineering, realitas teknis berbicara lain. Bagi tim pengembang, penyesuaian tersebut sering kali bukan sekadar modifikasi di permukaan. Hal itu bisa berarti perlunya penyesuaian arsitektur sistem dasar, uji coba hardware di lingkungan baru, atau sinkronisasi data AI yang secara alami membutuhkan development time jauh lebih panjang dari tenggat waktu yang tertera di kontrak.
Tim BD mungkin merasa Engineering terlalu lambat dan kaku. Sebaliknya, Engineering merasa BD terlalu optimis merancang timeline tanpa memperhitungkan kompleksitas integrasi sistem di lapangan.
Dampak Ketidakselarasan: Efek Domino pada Timeline Proyek
Ketika ekspektasi penjualan dan kapasitas teknis tidak disinkronkan sejak awal, dampak yang paling sering dan paling fatal adalah melesetnya jadwal proyek (project delay).
Demi mengejar tenggat waktu penyelesaian fitur custom untuk satu klien, sumber daya tim teknis sering kali harus dialihkan secara paksa. Dampaknya menjadi efek domino:
- Alokasi waktu untuk R&D produk utama tersendebat
- Proses testing dan Quality Assurance (QA) dilakukan dengan ruang waktu sangat sempit
- Memicu rentetan revisi berkepanjangan saat fase implementasi di lapangan
Pada akhirnya, peluncuran proyek tertunda berbulan-bulan dari jadwal awal. Keterlambatan ini tidak hanya menggerus kepercayaan klien, tetapi juga berdampak langsung pada operasional — ketika timeline mundur, termin pembayaran invoice ikut tertunda, yang berpotensi mengganggu stabilitas arus kas (cash flow) secara keseluruhan.
Filosofi The Phoenix Project dan Taktik Penyelarasan
Dalam buku legendaris manajemen IT, "The Phoenix Project" karya Gene Kim, dijelaskan bahwa malapetaka bisnis selalu terjadi ketika departemen bisnis menganggap tim IT/Engineering hanya sebagai "pabrik pembuat pesanan", bukan sebagai mitra strategis.
Referensi: The Phoenix Project — IT Revolution
Sebagai pemimpin (CEO/CTO/VP), sangat mudah untuk memihak. Berpihak pada BD akan menciptakan produk rapuh; berpihak pada Engineering akan membuat startup kalah cepat dari kompetitor. Kuncinya adalah menjadi pendengar yang strategis dan membangun jembatan.
Berikut adalah tiga langkah taktis untuk menyelaraskan kedua departemen:
1. Libatkan Engineering di Fase Pre-Sales
Jangan biarkan tim BD mendesain arsitektur produk sendirian di depan klien. Wajibkan kehadiran Solutions Architect atau representasi teknis level senior pada tahap negosiasi akhir. Mereka bertugas memfilter mana permintaan custom yang feasible dan mana yang akan menjadi mimpi buruk infrastruktur — sebelum tinta tanda tangan mengering.
2. Terapkan Pendekatan Phased Rollout (Rilis Bertahap)
Bantu tim BD untuk bernegosiasi ulang dengan klien menggunakan konsep Minimum Viable Product (MVP). Alih-alih meluncurkan sistem AI yang 100% sempurna di bulan pertama, sepakati untuk merilis 60% fitur inti terlebih dahulu. Ini memberikan kemenangan bagi BD di mata klien, sekaligus memberikan waktu bernapas bagi tim Engineering untuk menyempurnakan sisa sistemnya secara bertahap.
3. Bangun Metrik Sukses Bersama
Ubah cara memberikan bonus atau KPI. Jika tim BD hanya diberi insentif berdasarkan deal yang ditutup, mereka tidak akan peduli pada kesulitan teknis. Buatlah KPI silang: bonus proyek baru akan cair secara maksimal jika implementasi di bulan pertama berjalan stabil tanpa kendala teknis. Ini akan memaksa tim BD menjual apa yang benar-benar bisa dikerjakan oleh tim teknis.
Kesimpulan
Dalam memimpin startup berbasis teknologi (IoT dan AI), kemampuan mendengarkan dan mengorkestrasi konflik adalah alat mitigasi risiko yang paling berharga. Ketika tim Sales di garis depan dan tim Engineering di balik layar menyadari bahwa mereka berada di kapal yang sama, mereka tidak akan lagi bertarung satu sama lain. Sebaliknya, mereka akan bersinergi membangun solusi yang tidak hanya laku dijual, tetapi juga tangguh dan berkelanjutan di masa depan.