Three Questions to Ask Before You Let a Vendor Embed an Engineer in Your Codebase
AWS put a billion dollars behind Forward Deployed Engineering, so the Palantir model of dropping vendor engineers into your codebase is now a default. Three questions to ask before you sign, all pointing at one thing: a running system is not an understood system.
I'm not against forward deployed engineering. I've watched a vendor engineer solve in three weeks what an internal team circled for six months. My framing here isn't "should you do this," it's "what are you actually buying, and what's the bill that comes due later?" The question nobody asks in the sales conversation is: when that engineer ships to your production system and then goes back to their company, what does success look like for them? It's rarely "this team can operate without me."
Key takeaways
- Ask the exit criteria, and whether they include your team operating alone: "the system works" and "the system is understood" are different products at the same price; the bar is 2am paging
- Ask how the FDE is incentivized and what happens at renewal: measured on renewal means a quiet incentive to stay indispensable; measured on knowledge transfer means the opposite
- Ask who owns the decision log: not API docs, but why this abstraction and this boundary in your environment; "out of scope" is itself an answer
- What good looks like: documenting as they go, someone on your team explaining the architecture by month two, logged trade-offs, a handoff that's a week of your team running it while they watch
Who this is for
Engineering leaders and architects sitting across from a vendor account team with a contract in front of them. Also useful if you're the internal engineer who'll inherit the system. Advice essay, no code.
The full piece is on Substack.