The 2027 Engineering Leader's Guide to FDE

It’s 3:25 a.m. Traffic is climbing on a service that pays the bills. The alert fires half an hour later. Your on-call engineer opens the runbook, if there is one, and messages the one colleague who really understands this part of the platform. That colleague is on a plane. By morning it’s fixed. Nobody slept much. And somewhere in your backlog, the ticket that would have prevented it moves to next quarter again.

You already know the options. You could hire a senior DevOps specialist: months to find, months more to ramp up. You could bring in consultants: you’d get a good report, and your team would still have to do the work. You could add contractors: more hands, but the skills leave when they do. Or you could try the model everyone in enterprise tech started talking about in 2026: forward deployed engineering. AWS, Microsoft, Google, OpenAI and Anthropic all launched forward deployed teams this year. Job postings for the role grew several times over. And Gartner has already warned that plenty of what’s sold under the name is just consulting with a new label. So: to FDE, or not to FDE? This guide helps you answer honestly, for your own team.

Shortened version for you, dear CTO

• What it is. A Principal Engineer and a Senior DevOps Engineer embed on site in your team for six weeks to implement one clearly scoped cloud, DevOps or infrastructure Mission. Changes go into your repositories, through your reviews and change controls. When they leave, your team owns the result.
• When it fits. You run your own cloud infrastructure, with a team of four to six engineers and a technical owner, usually inside an IT organization of 100 or more people. You have one problem worth fixing now: performance and cost, security, reliability and operations, or resilience and recovery. And you can’t wait months for a hire.
• When it doesn’t. You need a strategy before anyone touches anything, you want your whole cloud estate optimized at once, or nobody on your side runs the platform today.
• What your team keeps. Changes merged in your own repositories, runbooks and documentation, engineers who know how and why every change was made, and an honest read on what to fix next.
• The catch. Six weeks won’t fix everything, and in large companies approvals, access and reviews can slow any engagement down. A good provider tells you that before you sign.
• The critics. Some say it’s consulting with a new name, that six weeks is too short, or that it creates vendor dependency. Some of that is fair. Part 2 takes the seven biggest objections head-on, including where the critics are right.

What FDE actually is

A military name for a very practical idea. “Forward deployed” comes from military language: placed at the point of action, not back at headquarters. Palantir borrowed it around 2009, when its first customers were agencies that couldn’t explain what they needed and often weren’t allowed to. So instead of asking for requirements, Palantir sent engineers to sit with the people doing the work and build what the work required.

Inside Palantir, these engineers were called “Deltas,” to tell them apart from the product engineers, called “Devs.” The company’s own distinction is the cleanest definition anyone has written: a product engineer’s focus is one capability, many customers; an FDE’s focus is one customer, many capabilities. Until around 2016, Palantir employed more Deltas than Devs.

Applied to DevOps, the idea is simple: “An FDE works inside your team for a defined period, builds in your own environment, and is judged on what is running when they leave.” Not a report. Not a roadmap. Not extra hands working your backlog your way. Senior people inside your team, making real changes with your engineers, until your engineers can carry on alone.

Why everyone is suddenly talking about it

For fifteen years, forward deployed engineering was a Palantir curiosity. Models got good faster than companies could put them into production: MIT’s 2025 research found that 95% of organizations saw no measurable return from generative AI, and 42% of companies had abandoned most of their AI initiatives, up from 17% a year earlier. The bottleneck was the integration work: legacy systems, messy data, security rules and workflows nobody designed for it. That’s exactly the work embedded engineers do, so in 2026 the biggest names moved in:

Here’s the part most coverage skips: the same problem exists without AI. Before any AI pilot can reach production, the platform underneath it has to scale, recover, stay secure and be observable. That’s DevOps work, and it’s where most enterprises are stuck today.

Four signs FDE is a real deal, not consulting with a new name

In September 2026, Gartner warned about “FDE washing”: consulting services relabeled as forward deployed engineering. Here’s how to tell the difference in about a minute.

Glossary

• Mission: one clearly scoped piece of cloud, DevOps or infrastructure work with one measurable technical outcome.
• Technical owner: the person on your side who owns the scope and can make decisions.
• Bounded engineering domain: what’s in scope, usually one engineering team and one coherent technical area, such as a Kubernetes estate or a CI/CD toolchain.
• Backlog (P0 to P3): the main outcome, three to five priority items, extras if capacity allows, and future work for your team.
• Residency: the six weeks our engineers spend embedded in your team.
• Handover: the final week, when your team validates it can operate and extend everything that was built.

What counts as “one bounded domain”?

This is where most engagements go wrong before they start. A well-bounded platform has:

• one primary engineering team,
• one technical owner,
• one reasonably consistent architecture,
• one common way of operating it,
• one clearly defined technical domain.

Good examples: a Kubernetes estate, an application’s cloud infrastructure across dev, stage and prod, a business unit’s cloud foundation, a CI/CD toolchain, an observability stack, a shared infrastructure service, or a defined hybrid-cloud environment. Several environments can still count as one domain if they share the same architecture and team. A bad example: “optimize our entire cloud.” It has no boundary and no finish line, so no honest provider can promise a result in six weeks.

FDE or not FDE?

What you gain

• Senior DevOps expertise without the hiring search. No months of interviews, no ramp-up period, no single new hire becoming your next single point of knowledge.
• Experience you don’t have in-house yet. Your team may be strong and senior. What it often lacks is someone who has already done this specific thing at enterprise scale, and knows where it goes wrong.
• Skills that stay. Your engineers pair on every change, so they leave the Mission able to repeat it.
• Real changes, not a slide deck. Work is merged into your repositories, through your reviews.
• A fixed scope and price. You know what you’re buying before you sign.

Use cases: what a Mission looks like in practice

These are the situations engineering leaders most often bring to a scoping session. Each one fits a single team and a single bounded domain.

1. The cloud bill grows faster than the business. Spend on EKS clusters, databases and data transfer keeps rising, and nobody can say which team owns which cost. The Mission rightsizes workloads, tunes autoscaling, adds cost tagging and gives your team a monthly review it can run alone.
2. A disaster recovery plan nobody has tested. The document exists, but no one knows how long a real restore would take. The Mission builds the backups and failover, runs a restore drill with your team and records the recovery times you actually achieved.
3. Audit findings that keep piling up. IAM roles are too broad, secrets sit in pipeline variables and the same findings return every quarter. The Mission tightens access, moves secrets into a managed store and turns the fixes into guardrails as code, so they stay fixed.
4. Releases that take a day of manual steps. Deployments depend on one or two people, a checklist and a quiet Friday. The Mission builds a pipeline with automated tests and rollback, and moves environments into infrastructure as code.
5. New environments that take weeks. Every new service or test environment waits in a ticket queue. The Mission creates reusable templates, so your engineers can create a standard environment in hours, within agreed guardrails
6. Customers find outages before your team does. Hundreds of alerts fire, few of them matter, and on-call is exhausting. The Mission defines service level objectives, cleans up alerting, builds the dashboards that matter and writes runbooks for the most common incidents.
7. A Kubernetes upgrade that keeps getting postponed. The cluster version is close to the end of support and nobody wants to touch it. The Mission plans the upgrade, tests it, runs it with your team and leaves a repeatable process for the next one.
8. The same incident, three times this year. After a major outage, the post-mortem lists fixes that never get scheduled. The Mission turns that list into a backlog and closes the root causes in production.

The case against FDE, and where the critics are right

FDE has real critics, and some of their points are fair. Here are the seven objections we hear most, what’s true about each, and how a well-run Mission answers it.

1. “It’s just consulting with a new name.” Often, it really is, test it against the four signs in Part 1. A defined period, a fixed price, code in your repositories from the first days, and a planned exit. If any of those is missing, the critics are right about that offer.

2. “Six weeks is too short. Another quarter of planning would be safer.” This period won’t fix a whole platform, and a rushed change in an enterprise can do real damage. But at Dedicatted, Mission doesn’t start with open-ended investigation. The boundary, goal and risks are agreed before the clock starts, so six weeks deliver a finished, tested piece of work instead of another plan. In one of our past engagements, the team found where a customer’s AWS 100k+$ in costs were leaking within about three weeks.

3. “It creates dependency on the vendor.” Gartner predicts that by 2028, 70% of enterprises will abandon agentic AI built by vendor forward deployed teams, trapped by rising costs and unable to evolve what was built for them. But that’s what happens when there’s no exit plan. A Mission is designed around one: everything lives in your repositories, your engineers make and repeat the changes, and anything they can’t do alone yet is written down with an owner. If a provider can’t describe exactly what your team will run without them, walk away.

4. “My team is senior. What can two outsiders teach them?” Enterprise teams of six to eight usually include an architect and several senior engineers. A Mission that pretends to teach them the basics would waste everyone’s time. At Dedicatted, it’s not about general skill. Senior engineers in large companies often haven’t had the chance to do a specific thing at enterprise scale, such as a full recovery exercise or a large Terraform import, or haven’t had the time and approval to do it. The value is people who’ve already done that exact thing, know where it goes wrong, and do it with your team.

5. “Outsiders near production is a security risk.It is, and enterprises are right to be strict, make sure to plan for it. Expect background checks on every external engineer, sometimes across criminal databases in several countries. Every change should go through your existing repositories, review processes and change controls. If your policy requires your own staff to execute production changes, the outside engineers prepare and validate them and support your team during deployment. Use named identities, temporary credentials and least privilege, and revoke everything at the end. A good provider treats all of this as normal, not as an obstacle.

6. “It’s a door-opener to sell me a bigger project.” The end of a Mission does often reveal larger work, such as a re-architecture. The future backlog should be written for your team to use whether or not you ever hire the provider again: the problem, the expected benefit, dependencies and rough size. If the recommendations only make sense with the vendor attached, be suspicious.

Spending wisely on FDE

A Mission makes sense when your team owns the environment and knows the priority, but needs more senior expertise and focused engineering capacity to move it forward. That usually shows up as one of four moments, plus a quieter fifth. You’ll probably recognize at least one.

Why cost sits inside performance. In large companies, nobody tracks every cloud resource. Unused and oversized capacity piles up, and you pay for it every month. Finding the owner of each resource and deciding whether it’s still needed, and at what size, is one of the fastest ways a Mission pays for itself. Cost work goes beyond deleting idle resources. It also asks the bigger questions: is this the right service for the job, could an open-source or simpler option do it for less, and is the tooling around the platform (monitoring, logging, security tools) sized for what you actually use? A careful team confirms the owner and the usage of every resource before removing anything, and buys long-term commitments such as Savings Plans only once demand is stable and understood.

The quiet fifth moment: manual work nobody has time to automate. In one of our enterprise engagements, developers were spending four to five hours a day on manual steps to get database-related requests done. The team automated the process in a few weeks and handed over a working solution. Developers stopped waiting, DevOps engineers stopped doing repetitive work, and everyone could see what the process cost and who used it. In large companies with long backlogs, this is often the fastest visible win, and it’s what the CI/CD & Infrastructure Automation Mission is for.

What you should expect, and how to prove it

The biggest value of a Mission isn’t the changes alone. It’s what your team can do after we leave. Your engineers work on every change with ours, then lead the next similar task while ours observe. By week six, they should be able to explain each change, repeat it, and validate the result on their own.

Some numbers look like progress but prove very little on their own:

• Higher CPU or memory utilization. It helps explain a result, but it isn’t the goal. Latency, errors and cost at comparable traffic are.
• Fewer alerts. Useful only if real failures are still caught. Track how many pages needed action, not just how many there were.
• A better security score or fewer findings. Scores support the story. The real evidence is a serious risk that’s verifiably gone: the old credential no longer works, the exposed resource is no longer reachable.
• A successful failover. Infrastructure can fail over while the application never reconnects. Recovery is proven only when the service works and the data checks out.
• An estimate from a tool. Services like AWS Resilience Hub can estimate whether your design should meet recovery targets. Only a real exercise shows what actually happens.

One rule makes your report credible: separate what was measured from what was estimated. A lower daily cloud bill supports a monthly savings estimate, but it isn’t a full month of savings until a month has passed.

What six weeks inside an FDE Mission look like

The Mission is a commitment to a goal, not to an unlimited list of tasks. The backlog usually has four levels:

• P0, the main outcome: the measurable technical result the six weeks are designed to move.
• P1, priority items: typically three to five pieces of work that get most of the engineering effort.
• P2, extras: items addressed if capacity allows and they support the main outcome.
• P3, future work: valuable work found along the way that belongs with your team, a future Mission or a larger project. Each item is written up with the problem, expected benefit, dependencies and rough size, whether or not you ever work with us again.

The fixed price covers the two-person team, the six-week residency and the agreed Mission, not an unlimited task list. That’s what keeps the price fixed while leaving room for what engineers discover once they’re inside your environment.

A normal day inside a Mission: FDE experts from Dedicatted

The day starts with a short review of priorities, blockers and planned changes. Then engineers pair on investigation or implementation, review changes together, test the result and update the runbooks as they go. Architecture discussions always come back to the problem being solved and the tradeoffs involved, so your team understands the why, not just the what.The shift happens gradually. First, our engineers and yours do a task together. The next time a similar task comes up, your engineer leads and ours observe.

How you’ll know your team is ready. For every important change, agree on practical exit criteria. By week six, an engineer on your team should be able to:

• explain what the change does and why,
• find its configuration and who owns it,
• make a similar change on their own,
• validate that it works,
• perform the related operating task, such as diagnosing a scaling issue, rolling back a deployment, restoring a backup or responding to an alert.

Anything your team can’t do alone yet goes into the final report with an owner and a follow-up action. All code and documentation live in your own systems, not ours.

In large companies, the engineering work often fits comfortably in six weeks. What slows things down is everything around it: approvals, reviews, security checks and communication across teams. Expect external engineers to go through background checks, and expect production access to be limited or handled through one of your own engineers. None of this is a problem if it’s planned before week one. That’s why the clock starts only once access is in place.

What six weeks can’t do. Be wary of anyone who promises these in six weeks:

• an estate-wide cloud migration,
• replacing an entire landing zone,
• a full multi-region architecture,
• a broad database modernization or application redesign,
• an organization-wide identity overhaul,
• a platform rebuild spanning many teams.

In large enterprises, a full disaster recovery program can easily take a year, mostly because of coordination and approvals. A Mission can still help: it can prove recovery for one critical service, show your team how to do it properly, and give you a realistic plan for the rest.

To FDE or not to FDE?

If your team is capable, your problem is specific, and you want the skill to stay after the experts leave, the answer is probably yes. If you need a strategy first, or nobody on your side owns the platform yet, the honest answer is not yet. Either way, it’s worth a 45-minute conversation.

Book a free Mission scoping session. A Principal Engineer will help you pick the right Mission, check that it fits in six weeks, and tell you who on your team should be involved and what it costs. If a Mission isn’t the right fit, we’ll say so. Dedicatted is an AWS Premier Tier Services Partner with the AWS MSP designation, the Generative AI Competency, and SOC 2 and ISO 27001 certification.