Hva er en Forward Deployed Engineer – og hvorfor høres det så kjent ut?

For ikke lenge siden kom jeg over en stillingstittel jeg ikke hadde sett før.

Forward Deployed Engineer.

Jeg antok at det var en slags nisjeinfrastrukturrolle og scrollet forbi. Så så jeg det igjen. Og fortsatte å se det.

Det viser seg at dette er en av de raskest voksende stillingstitler i Silicon Valley akkurat nå. Og da jeg faktisk så nærmere på hva det betyr, var min første tanke: er ikke dette bare slik god programvareutvikling alltid har sett ut?

Så hva er det?

Definisjon

Forward Deployed Engineer (FDE) — en programvareutvikler innebygd direkte i en kundeorganisasjon som både forstår forretningsproblemet og bygger den tekniske løsningen. I motsetning til tradisjonelle utviklere som jobber fra en spesifikasjon, holder en FDE seg nær kunden gjennom hele prosjektet og justerer løsningen basert på hva som faktisk skjer i det virkelige miljøet.

Begrepet ble lånt fra militæret, der en fremskutt utplassert soldat er stasjonert nær der ting faktisk skjer. I tech er ideen den samme: noen nær problemet, ikke håndterer det på avstand.

Denne måten å jobbe på har alltid eksistert i gode programvareteam. Det som er nytt, er at Silicon Valley nå ansetter for det ved navn.

Forbes sier det enkelt: FDE-er er mest verdifulle i dynamiske, hurtigbevegelige miljøer der det å holde seg på linje med virksomheten krever løpende tilstedeværelse, ikke en engangsoverlevering.

Det er en viktig distinksjon. En FDE er ikke bare noen som bygger ting. Det er noen som forstår hva som må bygges og hvorfor, og forblir ansvarlig for å sikre at det faktisk fungerer i miljøet det ble bygget for.

Hvorfor ansetter alle for dette nå?

Det korte svaret er AI.

AI-verktøy har gjort det enklere enn noensinne å bygge noe raskt. Men raskt betyr ikke riktig. De fleste bedrifts-AI-prosjekter mislykkes ikke fordi modellen var dårlig. De mislykkes fordi ingen sørget for at løsningen faktisk passet til organisasjonen den skulle tjene.

Modellen fungerer. Distribusjonen gjør det ikke.

Noen må fortsatt forstå arbeidsflytene, kanttilfellene, dynamikken i hvem som bruker hvilket verktøy og hvorfor. Noen må sitte med menneskene som faktisk vil bruke tingen og finne ut hva de faktisk trenger. AI kan ikke gjøre den delen. En god ingeniør som har vært i rommet kan.

The New Stack dekker dette godt: etter hvert som AI akselererer hvor raskt kode skrives, skifter flaskehalsen. Den vanskelige delen er ikke lenger å bygge. Det er å forstå hva som skal bygges i utgangspunktet.

Det er ikke en ny idé. Det er bare at bransjen endelig setter en stillingstittel på det.

Hva dette betyr hvis du bygger noe

FDE-trenden er bransjens måte å innrømme noe som mange gründere allerede vet fra erfaring.

Å overlevere en beskrivelse til et utviklingsteam og vente på resultatet fungerer ikke så godt som det høres ut. Noe går tapt i oversettelsen. Teamet bygger det de ble fortalt, ikke alltid det som faktisk var nødvendig. Og innen noen legger merke til det, er ekte tid og penger allerede brukt.

Det er ikke en svikt i ferdigheter. Det er en svikt i nærhet. Utvikleren var for langt fra problemet til å fange opp misforholdet.

Den bedre tilnærmingen er å ha noen nær problemet gjennom hele prosessen. Noen som forstår forretningskonteksten, ikke bare den tekniske spesifikasjonen. Noen som kan fange opp misforholdet før det blir dyrt.

Det høres åpenbart ut. Men det er overraskende sjelden i praksis – noe som er nøyaktig grunnen til at det nå er et av de mest ettertraktede kompetansesettene i Silicon Valley.

Hvorfor det høres kjent ut for oss i Rocksoft

Da jeg leste om hva Forward Deployed Engineers gjør, tenkte jeg hele tiden på hvordan vi jobber.

Før noen bygging starter, kjører vi et Discovery Workshop. En strukturert økt der vi jobber gjennom hva som faktisk er nødvendig før noen skriver en kodelinje. Ikke fordi det er en prosess vi følger, men fordi vi har sett hva som skjer når du hopper over det.

Og hva skjer hvis du hopper over det?

Du ender opp med å bygge feil ting svært godt.

Gjennom vår AI Engineering Partner-tjeneste gjelder den samme tankegangen. AI kan generere raskt. Ingeniørene våre sørger for at det som genereres er det riktige, trygt å lansere og faktisk koblet til det virksomheten trenger.

Jeg visste ikke at "Forward Deployed Engineer" var en stillingstittel før nylig. Men ideen bak det – forstå problemet først og bygg etterpå – er noe vi har gjort fra starten.

Det større poenget

Silicon Valley begynner å sette en stillingstittel på noe som de beste programvareteamene alltid har gjort stille.

Bedriftene som får mest ut av AI – og av programvare generelt – er ikke de som beveger seg raskest. De er de som har noen i rommet som stiller de riktige spørsmålene før byggingen starter.

Det er hva en Forward Deployed Engineer er. Og hvis konseptet resonerer, er det sannsynligvis fordi du allerede har kjent forskjellen mellom et team som forstod problemet ditt og ett som ikke gjorde det.