Şirketler İçin 3 Adımda FDE Modelini Hayata Geçirme Rehberi
Geçen yazımda Forward Deployed Engineer (FDE) rolünün ne olduğunu ve neden şu an bu kadar popüler olduğundan bahsetmiştim. Yazıyı yayınladıktan sonra birkaç farklı yerden gelen şu soru ile karşılaştım: "Tamam, rolün ne olduğunu anladık. Peki biz bunu nasıl hayata geçireceğiz?"
İlgili Eğitimlerimize Hemen Göz Atın
Bu soru aslında rolün kendisinden daha zor bir soru. Çünkü FDE kavramının tek başına bir pozisyon değil, bir organizasyon tasarımı konusu olduğunu düşünüyorum. Doğru kurgulanmadığı ve kültürel olarak bu role alan açılmadığı durumda, ortada sadece güzel bir ünvana sahip olan ama değer üretemeyen bir grup insan olması kaçınılmaz.
Bu yazıda, FDE modelini gerçekten hayata geçirmiş şirketlerin bunu nasıl yapılandırdığına bakmaya çalışacağız. OpenAI'ın bu ekibi sıfırdan nasıl kurduğuna, Palantir'in FDE ile "normal" mühendislik arasındaki dengeyi nasıl sağladığına ve bu modelin neden sadece "sahaya birkaç mühendis gönder"den ibaret olmadığına dair somut örnekler paylaşacağım.
İki Temel Rol: Developer ve Delta
Palantir bu ayrımı çok net bir şekilde yapıyor. Şirket içinde iki farklı mühendislik kimliği var: Developerlar ve Deltalar. Developerlar platform ürünü üzerinde çalışır, odak noktaları "bir yetkinlik, birçok müşteri" mantığıdır. Deltalar ise sahada müşteri ile birlikte çalışır, odak noktaları "bir müşteri, birçok yetkinlik" mantığıdır. Bir Delta, müşterinin hedefine giden yolda platformun mevcut yeteneklerini kullanır, gerektiğinde kendisi kod yazarak platforma küçük eklemeler yapar, ama asıl işi müşterinin somut bir metriğini iyileştirmektir.
Bu ayrımı kurmadan FDE modelini uygulamaya çalışan şirketler genellikle şu tuzağa düşüyor: Sahadaki mühendisler öğrendiklerini hiçbir yere aktaramıyor, her müşteri için sıfırdan iş yapılıyor ve şirket giderek daha çok "özel çözüm" üreten bir hizmet firmasına dönüşüyor. Marty Cagan bunun tam da geleneksel danışmanlık şirketleriyle FDE modelini uygulayan şirketler arasındaki en kritik farkı oluşturduğunu söylüyor. Platform ürün organizasyonu, farklı müşterilerden gelen öğrenmeleri sentezleyip, bir sonraki müşteri için işi çok daha hızlı hale getirecek genel yetenekleri platforma ekliyor. Bu, söylemesi kolay ama yapması gerçekten zor bir iş. Doğru yetenek, ürün vizyonu ve organizasyonel disiplin gerektiriyor.
Geçen yazıda bahsettiğim "kaba yol/patika, otoyol" benzetmesi tam olarak burada devreye giriyor. FDE'ler kaba yolu açar, platform ürün ve mühendislik ekibi bu yolu otoyola çevirir. Ama bu otoyola çevirme işi kendiliğinden olmuyor. Şirketin bunun için özel bir mekanizma kurması gerekiyor.
Organizasyonların FDE Modeli
OpenAI'da müşteri projeleri üç aşamada ilerliyor. İlk aşama sahada kısa süreli bir keşif: kullanıcılarla birlikte oturup süreçleri haritalamak, en değerli alanları belirlemek, sentetik veriyle hızlı prototip çıkarmak. İkinci aşama doğrulama: scope edilen şeyin müşteri için gerçekten en değerli iş olup olmadığını test etmek, bunun için ölçüm kriterleri belirlemek ve bu kriterlere göre performansı iyileştirmek. Üçüncü aşama teslim: müşteri sahasında birkaç gün geçirip problemin ayrıntılarını netleştirmek, veriyi almak ve çözümü uçtan uca çalışır hale getirmek.
Bu üç aşamalı yapı kadar önemli olan bir başka nokta, ekibin şirket içiyle nasıl bağlantı kurduğu. OpenAI'da FDE ekibi, araştırma ekibiyle düzenli bilgi paylaşım oturumları yapıyor, ürün yöneticileriyle periyodik olarak bir araya geliyor, tüm FDE'lerin sahadan topladığı gözlemleri paylaştığı şirket içi bir kanal işletiyor ve farklı şehirlerdeki ekibi bir araya getiren düzenli buluşmalar organize ediyor. Yani saha ile merkez arasındaki bilgi akışı tesadüfe bırakılmıyor, bunun için özel ritimler tasarlanıyor. Bu ekibin şirketin Agents SDK'sına verdiği katkı da tam olarak bu bilgi akışının bir sonucu.
Ramp örneğinde ise farklı bir yapı var. Şirket, FDE'lerini küçük takımlar halinde organize ediyor ve bu takımlar hem satış ekipleriyle hem de temel ürün mühendisliği ekipleriyle iç içe çalışıyor. Buradaki mantık, FDE'nin sadece müşteriye bakan değil, aynı zamanda hangi işin özel çözüm olarak kalacağına, hangisinin platforma taşınacağına dair önceliklendirme kararlarını da vermesi.
Palantir'in erken döneminde çalışan Adam Judelson'ın anlattığı bir başka organizasyonel karar da dikkat çekici: şirket, resmi bir satış ekibi kurmak yerine mühendisleri doğrudan müşteriyle konuşturmayı seçmiş. Mantık şu: karmaşık, misyona dayalı bir satışta müşteriyi ikna eden şey profesyonel bir satış söylemi değil, işin içinde bulunmuş birinin verdiği güven. Judelson'a göre bu yaklaşım, satış ekibinin komisyon odaklı motivasyonuyla mühendisin işin özüne olan bağlılığı arasındaki farkı ortadan kaldırıyor.
Bunun organizasyonel sonucu şu: eğer şirketiniz FDE modelini kurarken satış, ürün ve mühendislik arasında klasik silo yapısını korursa, FDE rolü bu yapının içinde sıkışıp kalıyor. Modelin gerçek gücü, bu üç fonksiyonun aynı kişide ya da aynı küçük ekipte birleşmesinden geliyor.
Kurumsal Bir Şirket İçin Bu Ne Anlama Geliyor?
Buraya kadar anlattığım örnekler teknoloji şirketlerinden. Peki geleneksel bir kurumsal şirket ya da bir Agentic dönüşüm sürecindeki organizasyon bunu nasıl uygular? Benim önerim 3 adımlı bir yapı:
Adım 1: Pilot Deneme
FDE rolünü kurumsal olarak bir yapıya dönüştürmeden önce AI-First dönüştüreceğiniz bir iş sürecini seçip, bu süreci sıfırdan tasarlayacak geçici bir takım kurmak faydalı olacaktır. Bu takım içerisinde FDE rolünü gelecekte alması potansiyel kişilerden birisi, dönüştürülecek sürecin ana sahibi (product/process manager vb) ve bu süreci daha sonra üretim hazır hale getirecek ürün geliştirici (AI Engineer, Data Scientist vb.) yer almalıdır. Bu takım ilgili süreci sıfırdan tasarlayıp, prototipleyecek ve AI’dan kazanılacak değeri görünür kılacak şekilde çalışacak. Sonraki adımları da belirleyip çalışmalarını tamamlayacak. Biz bu takımlara “Pod” adı veriyoruz.
Adım 2: Yaygınlaştırma
Bu adımda birden fazla Pod kurulumu gerçekleştirerek, FDE rolünün ve Pod yapısının organizasyonda yarattığı fayda ve sürtünmeleri netleştirilmiş olur. Bu sayede bir sonraki adımda bu yapının organizasyonel yönetişimini kurgulamak için gerekli saha öğrenmeleri elde edilmiş olur.
Adım 3: Organizasyonel FDE Yapısının Kurulması
Birden fazla Pod üzerinden elde edilen öğrenimler ile birlikte, FDE’lerin Ürün/Teknoloji/Mühendislik organizasyonu ile nasıl çalışacağı tasarlanır. Buradaki en önemli iki konu saha öğrenimlerinin nereye iletileceği ve saha ile merkez takımların iletişim ritminin belirlenmesidir. Bu adımda bu iki konu netleştirilmeli ve hayata geçirilmelidir.
Sonuç
FDE modelini kurmanın en zor kısmı, doğru insanı işe almak değil, sahadan gelen öğrenmenin kurumun hafızasına dönüşmesini sağlayacak bir sistemi tasarlamak. Bu sistem kurulmadan işe alınan her FDE, sadece bir sonraki süreç dönüşümüne/projeye kadar değerli olan bir bilgiyle sınırlı kalıyor. Yönetişim mekanizmaları kurulduğunda ise, her süreç dönüşümü/proje bir sonrakini daha hızlı ve daha güçlü hale getiriyor.
Agentic dönüşüm sürecindeki şirketler için bu modelin bir zorunluluk olduğunu düşünüyorum, çünkü AI inisiyatiflerinde şu an tam olarak Product Discovery yapılması gereken bir alan var ve bu ancak sahada, gerçek kullanıcılarla çalışılarak yapılabilir.
6 Ağustos'ta gerçekleştireceğimiz Forward Deployed Engineer Introduction eğitiminde, bu organizasyonel kurulumu daha ayrıntılı işleyeceğiz. Hepinizi bekleriz.
Bir sonraki yazıda görüşmek üzere.
Yorumlar