The other half of the
job isn’t code.

Engineers are trained to see technical systems clearly — components, dependencies, failure modes. The FDE insight is that the customer’s organization is also a system, with its own components (people), dependencies (who influences whom), and failure modes (a champion leaves, a security lead objects, two departments disagree). Treat it with the same seriousness you’d give an architecture, and the “soft” side of the job becomes tractable.

This isn’t about being political in the cynical sense. It’s about recognizing that a technically perfect solution with no internal support goes nowhere, while a good-enough solution with a strong champion and no blockers ships. The people dynamics aren’t a distraction from delivery — they are part of delivery.

One person can play several roles, and the mapping shifts over time. The mistake is to see only the friendly champion and ignore the quiet blocker until they surface a veto at the worst moment. Discovery is where you first draw this map — the “whose approval could stop this?” question exists precisely to find the blocker before they find you.

The instant a demo lands, the “can it also…” requests begin, and they never stop. Each one is a compliment — it means they see value — and a threat, because silently absorbing them turns a scoped two-week POC into an unscoped forever-project. The FDE move is to make scope visible and deliberate.

Then judge each ask against the agreed success metric from discovery. Does it help prove the value you scoped, or is it a separate project wearing the costume of a small tweak? Tying scope decisions back to the metric everyone agreed on turns “no” from a personal refusal into an objective, shared standard.

Engineers often default to a reflexive “sure, I can add that,” because saying no feels like bad service. It’s the opposite: a vague yes you can’t deliver on erodes trust far more than an honest, reasoned not-yet. The skill is to say no to the timing, not the idea, and always attach a reason tied to their goal.

Every good “no” is really a “yes, to protecting the outcome you care about.” Framed that way, saying no builds trust instead of spending it — the customer learns you’ll guard their goal even against their own impulses.

Trust in a deployment is built less by good news than by accurate news. The FDE who under-promises and over-delivers, and who surfaces a risk the moment it appears, becomes someone the customer relies on. The one who paints everything green until it suddenly turns red does not get a second engagement.

Two habits do most of the work. Under-promise: commit to what you’re confident you’ll deliver, then beat it — a demo that exceeds a modest promise lands far better than one that falls short of a grand one. And give honest status updates: when integration is stuck on the customer’s security review, say so plainly and name what would unblock it. Surfacing a risk early looks like competence; hiding it until it explodes looks like negligence, even when the underlying problem is the same.

The most fragile deployment is one that rests on a single relationship. Champions leave. Reorgs happen. A lone advocate can be overruled by a lone skeptic. Multi-threading — building support across several people and levels — is how you make the effort resilient to any one of them changing.

Practically, that means the champion isn’t your only contact: the user loves it, the decision-maker has heard the ROI, and the blocker’s concerns have been addressed so they’re at least neutral. When support is broad, one person’s departure is a setback, not a death; and no single objection can quietly kill months of work. This is also insurance for you — a deployment with many advocates is one where your wins are seen by many people, which is how an FDE builds a reputation. With the org navigated and the solution demoed, the remaining work is making it durable: passing security and hardening the POC into production.

Deployments fail on org charts, not architecture. A data owner who never says no but never grants access, a manager whose team the system automates, a sponsor who changes jobs in month five, and a set of users who quietly kept the spreadsheet — each of those ends a deployment regardless of how well the software works.

Keep it in the repository beside the code, not in your head. It takes ten minutes a month and it makes the political state of a deployment reviewable by someone other than you — which matters most in exactly the week you are unavailable:

The last line is the one to act on. A single-champion deployment is one job change away from a new manager reviewing a commitment they did not make, and over an eighteen-month engagement in a large enterprise those odds are not small. Build a relationship in a different reporting line in month four, when it costs nothing, rather than in the week you need it.