Working With an FDE: The Client's Field Guide

You signed the contract on a Thursday. The forward deployed engineer starts Monday. Now it's Sunday night and you're staring at the ceiling wondering what you actually bought. Is this person a contractor? A consultant? A temporary employee? Do you give them a desk badge? Do you invite them to the all-hands? You've hired a role that doesn't fit neatly into any category, and that ambiguity is either going to be a superpower or a source of weekly confusion. The difference is almost entirely up to you.

I've been the engineer in that seat. I've also been the client hiring one. The engagements that succeed share a pattern: the client treats the FDE like a senior employee who happens to invoice differently. The ones that fail treat them like a vendor who should show up, deliver a thing, and leave without asking questions. One approach gets you software that actually works. The other gets you a polite PowerPoint and a GitHub repo nobody can run.

Here's what to expect working with an FDE: access demands, rapid demos, direct feedback requests, and a scope conversation that starts on day three instead of day thirty. An embedded engineer succeeds or fails based on how quickly you integrate them into your operations, your politics, and your messy reality. The relationship is closer to hiring a director-level operator than commissioning a website. If you treat it that way, you'll get results that make your team look good. If you don't, you'll join the long list of clients who paid for custom software and received custom disappointment.

It's Not a Vendor Relationship

The best FDE engagements feel like hiring a senior employee who happens to invoice differently. That is not a metaphor. The engineer needs to know why your last project failed, who the real decision-makers are, and which Slack channels contain the actual source of truth. They need to sit in on meetings where people complain about the current process. They need to shadow the person who does the work you're trying to improve. If you keep them at arm's length, you might as well have hired an agency.

One client I worked with refused to give me access to their production database. "Security policy," they said. Fair enough. But they also refused to provide sanitized sample data. I spent two weeks building against a schema I had never seen, guessing at field types and relationships. On day eleven, I discovered that what I thought was a date field was actually a string that sometimes contained "ASAP." The fix took an hour. The two weeks of wrong assumptions were the real cost. Small businesses especially struggle with this tension between security and progress. The answer isn't open access; it's structured, milestone-based access with clear boundaries.

Vendors deliver specifications. FDEs deliver outcomes. A vendor asks "what do you want built?" An FDE asks "what are you actually trying to do?" The second question is harder to answer. It requires honesty about broken processes, political constraints, and the real reasons previous initiatives failed. Most clients aren't used to that level of transparency with an outsider. The ones who adapt get software that works. The ones who don't get software that matches the requirements document and misses the problem entirely.

The Access They Actually Need

Systems, people, and context. What to prepare before week one so the engineer isn't shadowing shadows. The access question is where most engagements stall before they start. Clients either overshare — handing over admin credentials to everything on day one — or undershare, treating the FDE like a visitor who needs an escort. Neither works. The right approach is milestone-based access tied to specific deliverables.

Week one needs read access to the systems related to the first milestone, introductions to the people who use those systems, and honest context about what has been tried before. Not the polished version for the board. The real version. "We tried this twice. The first time the vendor ghosted us. The second time the internal champion left and the project died." That context saves weeks of discovery and prevents the engineer from proposing the exact solution that already failed.

People access matters as much as system access. The engineer needs to meet the users, not just the stakeholders. Stakeholders know what they want. Users know what they do. Those are different things. One logistics client had a stakeholder who wanted "better visibility into dispatch." The dispatchers wanted the same view they'd always had, but with one extra column showing estimated arrival time. The stakeholder's vision was a dashboard. The users' need was a column. Building the column took two days. Building the dashboard would have taken two weeks and been ignored. The FDE's job is to find the column, not build the dashboard.

Feedback Loops: Your Job, Not Theirs

The client-side work of testing builds, introducing users, and saying "no" to scope creep. The biggest misconception about hiring an FDE is that your work ends when the contract is signed. In reality, your work intensifies. You are the feedback loop. You are the user advocate. You are the scope guardian. The engineer can build anything. It's your job to make sure they build the right thing.

Weekly demos are non-negotiable. Not status meetings. Demos. Working software. If the engineer can't show you something that runs by Friday of week one, that's a yellow flag. If they can't show you something useful by Friday of week two, that's a red flag. The demo is the heartbeat of the engagement. It forces prioritization. It surfaces misunderstandings early. It gives you something concrete to react to instead of抽象 plans that drift.

Saying no is part of your job. Scope creep is inevitable. The engineer will discover edge cases. Users will request features. Someone will suggest "while you're in there, could you also..." Your job is to protect the milestone. Not because the other ideas are bad, but because unfocused engagements ship nothing. Keep a running list of post-milestone ideas. Revisit it after the first win. The best scope management sounds like: "That's a great idea. Let's ship the core workflow first, then tackle that in week four."

Scope Will Creep. Here's the Antidote.

Fixed-phase check-ins, demo-driven milestones, and the contract language that protects both sides. Every engagement I've seen that ran over budget had one thing in common: the scope was discussed verbally and never written down. The client remembers agreeing to "the core feature." The engineer remembers agreeing to "the core feature plus the export function we talked about on the call." Both are sincere. Both are wrong. Write it down.

The contract should define milestones, not just deliverables. A milestone is a working demo that solves a specific user problem. "Users can submit a request through the form and see it in the admin queue." That's a milestone. "Build the request management system." That's a deliverable, and it's too vague. Milestones are testable. Deliverables are debatable. Structure the engagement around milestones and you get clarity. Structure it around deliverables and you get arguments.

Kill fees protect both sides. The client can end the engagement without penalty beyond a small wrap-up fee, usually two weeks of work, that covers documentation and handoff. The vendor knows they won't be stuck building forever for a client who lost budget. It's not pessimistic. It's professional. Every engagement should have an exit ramp that leaves both parties better off than a lawsuit would.

When It Isn't Working

The honest conversation framework: lagging progress, misaligned priorities, and the graceful exit. Sometimes the engagement doesn't work. Not because anyone is incompetent, but because the fit is wrong, the problem is different than expected, or the organization's readiness isn't there. The worst thing you can do is pretend everything is fine for six weeks and then declare the project a failure.

Address problems early. If week one demo is thin, say so. If the engineer is building for the wrong user, redirect them. If you realize the problem is actually organizational, not technical, have that conversation. FDEs are not software engineers in the traditional sense. They solve business problems with code. If the business problem is that your team doesn't have time to test, no amount of code fixes that.

The graceful exit is a skill. If it's not working, refer to the contract. Pay the kill fee. Take the documentation. Thank the engineer for what they built. I've ended engagements early and had the client hire me again two years later for a different problem. I've also watched engagements drag on for months past their usefulness because neither side wanted to admit it wasn't working. The early exit is cheaper, kinder, and more professional.

The Handoff Nobody Talks About

Documentation, knowledge transfer, and the internal owner who takes over when the FDE leaves. The handoff is where most FDE engagements succeed or fail in the long term. The software works on the engineer's laptop. The tests pass. The demo is smooth. Then the engineer leaves. Six months later, something breaks and nobody knows how to fix it. The tool becomes orphanware. The business goes back to spreadsheets.

Prevent this by identifying an internal owner by week two. Not a stakeholder. An owner. Someone whose job description includes keeping the tool running. If that person doesn't exist, the tool will die. It doesn't matter how good the documentation is. It doesn't matter how clean the code is. Without an owner, software is a rental that expires when the builder leaves.

Documentation should cover three things: how to run it, how to fix common problems, and who to call when something goes wrong. The last one is the most important. Write down the engineer's contact, the hosting platform's support number, and the client's internal IT contact. Tape it to the inside of the admin panel if you have to. The goal is that a new employee, reading this document for the first time at 10 PM on a Sunday, can get the system back online without panicking.

Hiring a forward deployed engineer is an investment in speed, specificity, and outcomes. But it's not magic. It requires your active participation, your honest feedback, and your willingness to treat an outsider like a senior member of your team. Do that, and you'll get software that actually works. Don't, and you'll get a very expensive lesson in what happens when you hire expertise and ignore it.