Skip to content
Published on

From Backend, DevOps, or Data Engineering to FDE — a Six-Month Transition Roadmap

🇰🇷KO🇺🇸EN🇯🇵JA🇨🇳ZH
Split View필사 모드
Share
Authors

Whatever Your Background, Half Is Already There

Most engineers considering the FDE move start from backend, DevOps/SRE, or data engineering. The good news first: measured against the eight domains of the skill map in part 2, roughly half the map is already filled from any of the three. FDE is not a from-zero role; it is your existing engineering career translated into the coordinate system of the field.

The bad news is that the empty half differs by background. So preparation starts not from someone else's roadmap but from a gap analysis of your own. The three backgrounds follow in turn — read your own, but skim the others too, because once you join a team you will be patching gaps with colleagues from those backgrounds.

If You Come from Backend

Already there — API design and integration, databases, code quality, and the speed of reading and fixing product code. Since the FDE deliverable is ultimately code running in a customer environment, writing code fast and safely is the most solid capital a transition can have. In domain terms, databases sit around working level and Linux near the baseline.

To fill — the infrastructure layer. Kubernetes and networking are the areas a platform team handled for you, so they tend to be empty. Then operational experience: if you have never been woken at dawn by an incident on a service you built, fill it — move to a team with an on-call rotation, or genuinely operate a side project. Last, entry speed into unfamiliar codebases; reading someone else's system without documentation is trained well by contributing to open source.

If You Come from DevOps or SRE

Already there — most of the technical axis. Linux, networking, Kubernetes, observability, cloud: five of the eight domains were likely your day job itself. The order-of-operations instinct for incidents, runbook culture, and blameless postmortems are already in your body. On technical gaps alone, this is the best-positioned background of the three.

To fill — two things pointing the other way. First, product code. Infrastructure automation scripts and product feature code use different muscles; if you have not taken a customer requirement and built a feature from it, build one, however small. Second, reversing the direction of communication. Your conversation partners so far were mostly internal developers; the FDE counterpart is an external non-engineer. Practice turning what you would write on an internal wiki into a report sent to a customer.

If You Come from Data Engineering

Already there — databases and SQL at working level, plus the terrain sense earned building pipelines. One of the first jobs in any customer environment is understanding the structure and quality of the customer's data — you have done that for a living. The feel for data boundaries and personal-data handling is already in place.

To fill — the service operations layer. The batch-pipeline world and the real-time service world have different grammars of failure. Networking, auth, and the experience of diagnosing an outage while users are living through it tend to be relatively empty. Observability also needs extending from pipeline monitoring to service monitoring.

The Common Gap — Standing in Front of Customers

Across all three backgrounds, the emptiest box in common is not technical; it is customer facing. Concretely, three things. First, the spoken demo. Demonstrating what you built to non-engineers in 15 minutes and taking questions is a format that does not work without rehearsal — create chances, even internal talks, and stack repetitions. Second, delivering bad news. The expectation management covered in part 5 is a skill where the distance between reading and doing is unusually long. Third, turning vague requests into a scope document: taking "it would be nice if it did something like this" and producing one page with success criteria — practicable even with an imaginary customer for a side project.

And if you aim at global positions, English is part of the stack. The bar is not fluency; it is whether you can report precisely during an incident.

The Six-Month Roadmap

Below is a generalized guide in two-month blocks. It assumes you are preparing alongside a full-time job, and the span stretches or shrinks with your starting point.

  • Months 1 and 2 — measure the gap, pour the foundation. Locate yourself with the FDE Curriculum Roadmap, pick your two emptiest domains, and pull them up to baseline. Building a home lab and operating one small Kubernetes cluster yourself is the shortcut that touches several gaps at once.
  • Months 3 and 4 — build evidence. Pick a product with a public API, define an imaginary customer scenario, and build an integration project. The deliverable is not just code: an architecture diagram, a success criteria document, and an incident runbook belong in it. These artifacts become the core of your portfolio of evidence. In parallel, repeat diagnosis drills of the FDE Career RPG kind until the first 30 minutes in an unfamiliar environment become muscle memory.
  • Months 5 and 6 — turn it into stories and apply. Choose the episodes from your career with the most field texture, shape them into situation-action-result stories, and assemble the application with your portfolio. Interview formats and preparation get their own treatment in the next part.

After six months you are not a finished FDE — you are someone an FDE team would reasonably hire and grow. That is the honest goal of this roadmap.

Practice by Doing

Both axes of transition prep — gap measurement and diagnosis drills — can start with the tools on this blog.

  • FDE Curriculum Roadmap — run the gap analysis across 10 domains and 65 skills and track progress.
  • FDE Career RPG — rehearse the decisions of unfamiliar-environment diagnosis as missions.

FDE Complete Guide series

Discuss on Twitter • View on GitHub