A „forward deployed engineer” (FDE) ma az egyik legkeresettebb szakma az AI és adat-infrastruktúra világában: laborok, startupok és befektetési cégek egyaránt mérnököket alkalmaznak, akik a vevők operációiba beülve oldanak meg konkrét problémákat. Vinoo Ganesh, a Kepler vezérigazgatója, aki három intézményben építette ezt a funkciót (Palantir, Citadel, Kepler) több mint egy évtized alatt, azt írja le, mi működött, mi nem, és hogyan érdemes felépíteni a szerepet.
Háttér: Project Frontline és a korai tapasztalatok
Ganesh Palantirnál kezdte pályafutását termékfejlesztőként, majd FDE-ként telepítették különböző iparágakba — kereskedelmi ügyfelekhez, védelmi és nemzetbiztonsági ügyekbe, egészségügybe és olaj- és gáziparba. Ő vezette a Project Frontline elnevezésű rotációt, amely során software mérnököket képeztek át FDE-kké: körülbelül 250 ember ment át ezen a programon, és sokan közülük ma olyan cégeknél vezetnek FDE-csapatokat, mint OpenAI, Anthropic, xAI vagy Anduril.
Később Ganesh a Citadelnél üzleti mérnökséget vezetett, ahol a portfóliókezelők voltak az ügyfelek, és minden kérdésre az volt a válasz: a szoftver és adatok segítik-e az alfa generálását. Most a Keplerben a forward deployed funkció termékhez kapcsolódik — nem értékesítéshez —, és olyan területen dolgoznak, ahol egy valószínűtlen rossz válasz rosszabb, mint semmilyen válasz.
Gyakori tévedések az FDE szerepét illetően
Az elnevezés elterjedése miatt ma sokféleképpen használják az „FDE” kifejezést: a beszélgetésekben előfordul, hogy FDE alatt sales mérnököt, kvótát vivő, Python-tudással rendelkező értékesítőt vagy konzultánst értenek. Egyesek számára az FDE inkább a „második hívásra” beugró szakember, másoknál egy statement-of-work alapján dolgozó külsős.
Ganesh szerint ez a pluralizmus problémát rejt, mert a funkciók különböző jelentései más riportolási vonalakat és ösztönzőket hoznak, eltérő célokat eredményezve. Az igazi FDE szerinte nem egyszerűen ügyféltámogató vagy konzultáns: az FDE feladata a mezői problémák megoldása azért, hogy megszerezze azt az ismeretet, amely alapján a terméket lehet általánosítani.
Egy hibából FDE: a Phoenix története
2013-ban Ganesh a Palantirnál a Phoenix nevű tranzakciós tár építésén dolgozott. A rendszer elméletben tiszta, jól definiált követelményekre készült, de egy banki telepítésnél a valós pénzügyi adatok hibái új problémákat hoztak elő: üres timestamp értékek az epochig estek vissza, a retention logika indokolatlanul rengeteg nyolcvan bejegyzést kérő bucketet generált — összesen mintegy 2,3 millió keyspace keletkezett, miközben a háttér-technológia, Cassandra, körülbelül 5 megabájtot igényelt fájlonként. A szerver OOM-olt (Out-Of-Memory), az újraindításhoz elméletileg 14 terabájt RAM kellett volna — a folyamat gyakorlatilag halva született.
A gyökér oka nem a felhasználói kutatás hiánya volt: volt specifikáció és érthető use case, de soha nem álltunk bent a helyszínen, miközben a rendszer élő produkciós adatokon futott. Az ismeretek másodkézből érkeztek, és senki sem birtokolta azt a rést, amely a dizájn és a napi valóság között volt.
Ganeshnek emiatt többször kellett a terepre repülnie, javítania és a felhasználókkal együtt dolgoznia — ez volt az a tapasztalat, ami őt ténylegesen FDE-vé formálta. A Phoenix végül platformmá nőtt: a Palantir FDE-i a fölé építve dolgoztak különböző megfelelőségi és kockázatkezelési eseteken. A tanulság: az FDE megoldja a vevő konkrét gondját, hogy megszerezze azt az insightot, ami eldönti, mit érdemes a platformban általánosítani.
Mit csinál(t) jól egy FDE — „főnevek és igék” gyűjtése
Ganesh azt javasolja, hogy az FDE feladata legyen a vállalat "főneveinek és igéinek" begyűjtése: a szervezeten belüli fogalmak (főnevek) és azok mozgásai, üzleti folyamatok (igék). Egy heti bentlét alatt kiderül, hogy ugyanazt a fogalmat mennyiféle néven hívják (sales: customer, ops: client, finance: billing entity, engineering: org_id), és ezek közti fordítási rések hibákhoz vezetnek, ha megváltozik egy definíció.
A „főnevek” azok a tárgyak, amelyekre a szervezet épít (pozíciók, kontrapartnerek stb.), de sokszor nem tankönyvi definíciók szerint. Az „igék” pedig a folyamatok: hogyan könyvelnek egy trade-et, mit kell teljesíteni a záráshoz, ki hoz döntést kivétel esetén. Ez a tudás rendszerint nem dokumentált; a „hat ember fejében él”, vagy egy négy éve készült spreadsheetben, amire mindenki támaszkodik. Ilyen tudást nem lehet egy interjúban kikérdezni.
Egy példa: egy ügyfélnél egy data quality mérnök minden CSV-cet kézzel nyitott meg Windows laptopon, és vizuálisan ellenőrizte a sorokat — a Parquet nem rendelkezett natív nézővel, így a javasolt migráció elvette volna a minőségellenőrzés eszközét. Amikor egy FDE végignézte a munkafolyamatot, megértette a valódi problémát, azonnal építettek egy Parquet-nézőt, a migrációt két nap múlva jóváhagyták, és a pipeline futási ideje 17 óráról 2 órára csökkent. Ezt a mérnök sosem mondta volna el szóban; a megfigyelés volt a kulcs.
A kimenetnek termékké kell válnia
Az FDE-k által összegyűjtött „nouns-and-verbs” megmutatja, mi a probléma; de a megoldásnak platformszintű termékké kell válnia. Ha az FDE csak egy ügyfelet örvendeztet meg, és nem juttatja vissza a megszerzett tudást a termékbe, akkor a funkció lényegében szolgáltatás/konzultáció marad. Ganesh egy korai hibáját is felidézi: egy évnyi hackelt groovy script ("vinoo.groovy") egyszeri rögtönzött megoldásként indult, majd éveken át futott egy nagy ügyfélnél, mivel nem tették termékké. Minden rögtönzött megoldás, amit élesben adsz ki, hosszú távon hozzád ragad.
A diszciplína az, hogy meg tudd különböztetni, mely javítások tartoznak a platformba, és melyeket kell szándékosan eldobni, amint elvégzik a feladatukat.
A fork: tanácsadás vagy platformépítés?
Itt válik ketté a dolog. Az egyik út: elvégzed a munkát anélkül, hogy alatta platform lenne — megtanulsz egy cég modelljét, pontosan arra formálod a megoldást, de az tudás elvész, amikor a projekt véget ér. Ez konzultációhoz hasonlít: jól fizet, de nem összecsomósodik.
A másik út: építesz egy platformot, amelyben minden egyes ügyfélnél szerzett ismeret a következő telepítést gyorsítja és a terméket finomítja. Ez a különbség órák eladás és tartós eszköz létrehozása között. Ganesh őszintén úgy látja, hogy sok cég az elsőt csinálja, miközben a befektetőknek a másodikat mutatja.
Hogyan építik ezt a Keplerben
A Keplernél a funkciót már az első naptól úgy szervezték, hogy az FDE-k a termék csapat kiterjesztésének tekinthetők. Ők hedge fundoknak, befektetési bankoknak, PE-cégeknek és más pénzintézeteknek adnak el — közös, megkérdőjelezhetetlen követelmény minden ügyfélnél: a számoknak helyesnek kell lenniük, és minden számhoz kell egy nyomonkövethető provenance.
Ez a követelmény a Kepler platform tervezési kiindulópontja: a provenance nemcsak helyességi követelmény az ügyfelek számára, hanem belsőleg is biztosítja, hogy a terepi munkák összeadódjanak. A rendszer nem improvizál elrontott kódolás fölött; ha félreértünk egy ügyféldefiníciót, a hibát a rendszer jelzi, és az mérnök visszajelzést kap, mielőtt hat hetekkel később egy kliens hívna fel.
A telepítések így azt mondják meg, mit kell kiterjeszteni a platformon: nem azt kérdezik, milyen funkciót szeretne egy adott alap, hanem azt, hol túl szűk a provenance-réteg, és hányszor találkozunk ugyanezzel a korláttal. Három ügyfél által kért ugyanaz a feature kevésbé súlyos jelző; három ügyfél által gátolt provenance-képesség sokkal relevánsabb.
Mi a versenyelőny (moat)?
Ganesh szerint a moats nem maguk a modellek, mert ezeket havonta olcsón lehet bérelni; nem is pusztán a tehetség, mert mindenki a legjobb pár száz embert veszti hajszolja; és nem egyszerűen egy ügyfél térképe, mert egy lezárt draftot bárki fel tud vázolni. A valódi eszköz az, hogy van-e felhalmozott, naprakész, ellenőrzött tudás arról, hogyan működnek ténylegesen a vertikum cégei, és ez a tudás egy platformban él, amely fenntartja és bizonyítani tudja azt.
Ezt a tudást nem lehet megvásárolni pusztán interjúkkal vagy felhasználói térképekkel: a folyamat az, hogy többször hibázol az ügyfélnél, kijavítanak, beépíted a javítást a platformba, és a következő céghez már úgy mész be, hogy tudod, mely kérdések fontosak. Minden ilyen ciklus olcsóbbá és gyorsabbá teszi a következőt — ez a compounding, amit birtokolsz.
Következtetések és ajánlások
- Az FDE szerepe: nem egyszerűen ügyfélszolgálat vagy konzultáció, hanem a termék kiterjesztője — célja a terepi problémák jeleinek termékké fordítása.
- Struktúra: az FDE-funkciónak a termékhez kell riportolnia, nem az értékesítéshez, mert ez más ösztönzőket hoz.
- Módszer: tölts időt a vevőnél, figyeld a valós munkát, gyűjtsd a "főneveket és igéket" és válaszd szét, mi megy a platformba és mi dobható el.
- Moat: építs naprakész, ellenőrzött, felhalmozott működési tudást a platformodon keresztül — ez a tartós előny.
Vinoo Ganesh jelenleg a Kepler vezérigazgatója, korábban a Palantirnál dolgozott (Project Frontline vezetése) és a Citadelnél üzleti mérnökséget vezetett. A cikk szerzője további eszmecserére invitál a LinkedInen.
