11 min read
I used to work in consulting, and one thing puzzled me for years: it was easy to get things done.
Not because we were smarter than the people inside the company. We were often sitting next to internal engineers who knew the system better than we did, knew the politics better than we did, and had already suggested the answer before we arrived.
But we had executive sponsorship. That changed the physics.
When middle management tried to slow the work down, and they did try, we did not have to survive their performance-review system. Our badge was a different color. That sounds small until you have watched a director realize they cannot really punish the outsider for ignoring the local ritual.
We would hit a blocker, take it to the executive sponsor, and the executive would wave the magic wand. The exception got approved. The meeting got skipped. The person sitting on the decision suddenly found room in their calendar. The policy that was immovable on Monday had a reasonable interpretation by Wednesday.
Then we kept going.
I remember thinking: why does the company not operate this way all the time?
The answer was obvious once I stopped being naive. We were in and out quickly. Our job was not to fix the remaining list. Our job was to win the battle we were hired to win. The CxO often wanted the visible win, the board slide, the promotion, the proof that their bet worked.
And then they could leave the mess behind.
That is not a moral indictment. It is a description of the incentive system. Consulting taught me one useful discipline: pick the battle. Find where executive air cover, technical judgment, and business value overlap. Win there. Then be honest about what the win did not fix.
Forward deployed engineering has to keep that discipline without repeating the lie.
The Irony Is Familiar
The $180,000 statement of work was easier to approve than the $412 token overage.
Most readers also read: We Kissed Specs and PRDs Goodbye. Product Managers Pass POCs Now.
You know this move because you did not feel reckless when you signed it. You felt responsible. The board had asked why the product date slipped. The COO wanted the claims workflow fixed before renewal season. The CISO had one sentence that could stop the whole thing. Your engineering director had three senior engineers who understood the code, the customer, and the approval gate.
They could build it. You did not believe the organization would let them.
So you hired the consultant. Not because the consultant was smarter. Sometimes they are. Often they are not. You hired them because the same sentence lands differently from outside the building.
Then the outsider said what your principal engineer said in March, and everyone nodded.
You were not fooled. You knew. You could feel the absurdity while it was happening. But you also felt the relief, because now the work had a path through the company that did not require your own people to spend their remaining political capital fighting the same hallway fight again.
That is not an engineering decision. That is a political workaround. The consultant was not just a pair of hands. The consultant was cover.
That mattered before AI. It matters more now.
AI Broke the Workaround
In the old system, bureaucracy slowed change.
In the new system, bureaucracy eats change.
That sounds small until you watch it happen. A senior engineer uses an agent to turn a three-week integration task into two afternoons of actual work. The pull request sits for four days. The security sign-off takes forty minutes. The queue takes nine business days.
The code moved at AI speed. The organization moved at calendar speed.
I have written this from the value-stream side already. If your team ships in twenty-eight days and only ten of those days are work, the other eighteen days are a leadership problem. Go read Your Engineering Team Ships in 28 Days if you have not drawn that map.
This is why the old consulting trick is no longer enough. The model can produce more attempts, test scaffolds, migration paths, and product experiments than your current operating system can absorb. The limiting factor stops being whether your engineers can create the change. The limiting factor becomes whether your company can digest it without turning every successful experiment into a political incident.
Your teams are smart. They are talented. They care. They also do not have enough reps yet.
Not because they are deficient. Because the same bureaucracy you cannot fix has limited their exposure. It kept them away from the customer. It slowed the experiments. It turned every risky learning loop into an approval path. You spend a week in quarterly planning. You stand up every morning to report that yesterday’s blocker is still blocked. You route work through intake, grooming, refinement, dependency review, change approval, release readiness, and the meeting after the meeting where someone explains why the official meeting did not decide anything. The last two years rewrote the practice faster than career ladders, governance models, architecture review boards, and delivery rituals could update. The engineer who is excellent in 2026 needs taste, domain judgment, agent orchestration, eval discipline, and the stomach to delete three hours of generated work because the shape is wrong.
You cannot read yourself into that. I wrote that already too, in You Cannot Read Yourself Into AI-SDLC Literacy. You get the reps by building. But the first attempts are messy, and your organization punishes messy.
Eventually Is Not a Strategy
Your engineers will eventually be able to build this. I believe that. Most of them have spent their careers learning whatever the company needed next. The good ones adapt.
But eventually is not a strategy.
You do not have the time. And in some cases, you do not have the talent in the building anymore.
The best AI-native engineers saw the signal early. They watched the company spend hours figuring out how to limit token consumption. Not how to turn token spend into throughput. Not how to measure cost of delay against model spend. How to cap it. Meter it. Approve it. Explain it to finance as if a $400 model bill were more dangerous than a $40,000 week of waiting.
Then some of them left.
The ones who remain are not bad engineers. But many are still using agents to automate the current process. Faster Jira tickets. Faster status summaries. Faster design docs for approval gates that should not exist. Faster compliance theater.
That is the trap. AI makes bad work faster too. If your first wave of adoption is your current team automating processes that should not exist, you have preserved the bureaucracy and given it a better typing assistant.
Your instincts are not irrational. Control cost. Manage risk. Protect the team from a failed experiment. Those are normal instincts. But under AI-speed change, they can create a disciplined-looking company while the people who know how to move leave for somewhere with fewer permission slips.
What the Forward Deployed Engineer Actually Does
Forward deployed engineering is about to matter. Not the fake version. Not a sales engineer with a nicer title. Not a product specialist who runs a workshop and disappears.
I mean a senior builder embedded where the work, the customer, the codebase, and the politics collide. Someone who can open the repository, pair with the internal engineer, talk to security, explain the risk to the sponsor, and ship something real before the organization turns the effort into a program office.
That person is not there to inspire adoption. They are there to create proof under live fire.
The forward deployed engineer has four jobs: ship the first valuable slice, map the bureaucracy, transfer the workflow while the work is happening, and leave behind a repeatable operating pattern.
The blocker map answers the questions everybody avoids. Which approval is real? Which approval is habit? Which queue protects the company from legal risk, and which queue exists because nobody has questioned it since 2017? Transfer happens in the branch, prompt history, failed eval, architecture decision record, and security conversation. Training after delivery is theater.
That last part is where most consulting fails. It ships the artifact and keeps the method. Forward deployed engineering has to do the opposite.
This is not enablement. It is exposure and judgment. If you have a principal engineer who has led five or six agent-native deployments, can talk to legal without creating panic, and understands the political shape of your company, use that person. You may not have that person. Or you may have one, and they are already carrying the three most important systems in the company.
That is why the outside experience matters. Not because outside is morally better. Because outside has seen more attempts. Outside has watched the pattern repeat across companies. And the different badge still matters, because the same manager who can punish your engineer for stepping around the ritual often cannot do much to the person with the sponsor’s name on the SOW.
A forward deployed engineer who has seen ten companies try to absorb AI-native delivery has a pattern library your internal team cannot have yet. They have seen the real CISO objection and the procurement dispute wearing a security jacket. They have seen the architecture review that catches a real blast-radius issue and the one built around the memory of a 2019 outage.
AI did not flatten expertise. It flattened production. It made mediocre output cheap, plausible wrong answers cheap, and confident bad architecture cheap.
Experience matters more now, not less.
You Need a Scapegoat and a Program
That is the ugly sentence. You need a scapegoat. Not a victim. Not someone disposable. A named accountable person who can absorb the first political heat without damaging the permanent team.
If your internal engineer challenges the approval gate and the effort fails, that engineer now has a reputation problem. “They went around the process.” “They moved too fast.” You have heard those sentences.
If a forward deployed engineer challenges the same gate and the effort fails, the organization can put the failure in a different box. “The program model was wrong.” “The outside engineer underestimated the regulatory path.” “We learned the exception criteria need to be tighter.”
That sounds cynical because it is. It is also protective. The internal team gets to participate, learn, and keep its political capital if the first pass breaks. The sponsor gets a cleaner escalation path. The organization gets a person whose job includes taking the hit.
Make it explicit. The forward deployed engineer owns the delivery hypothesis for ninety days. They own the first production slice, the blocker log, and the escalation path. They do not own legal risk. They do not bypass compliance. They do not get to turn “speed” into an excuse for bad engineering.
Pick one material workflow. Not “AI adoption.” Not “developer productivity.” Claims intake. Pricing updates. Month-end reconciliation. Legacy extraction. Customer onboarding. Something where a shipped change matters and a failed change teaches you something worth knowing.
This is where the consulting scar matters. Pick the battle. Do not take the whole org chart to war. Pick the workflow where executive sponsorship can change the physics and where a production win tells the company something it cannot unsee.
Assign one forward deployed engineer, one internal principal or senior engineer, and one product owner with authority to make tradeoffs. If you need twelve people in the core team, you are rebuilding the same coordination tax with a new label.
Give the team a governance lane, not a governance waiver. The lane says which checks must pass, who can approve exceptions, what data boundaries apply, what rollback looks like, and how incidents escalate.
Thirty days in, the team owes a working slice and a blocker map. Sixty days in, measurable throughput change and a repeatable pattern. Ninety days in, the sponsor gets a scale, kill, or redesign recommendation. No permanent limbo. No center of excellence. No fifteen-year service award. I wrote that warning in Your Transformation Org Just Got a Fifteen-Year Service Award.
The economics need to be visible from day one. If the forward deployed engineer costs $75,000 for a ninety-day engagement and the workflow saves five people ten hours a week at a loaded rate of $95 an hour, that is $4,750 a week. Over a year, roughly $247,000. If it does neither, say so and stop.
This is the same investment posture behind Find the Ceiling. Put an envelope around the bet, define the stop-loss, and measure whether the output justifies another round.
The Failure Is the Signal
Forward deployed engineering is not a substitute for changing the company. It is the first proof that the company needs to change.
If the program works, it should feed the operating model. The blocker maps become governance redesign. The repeated prompts become internal tooling. The contract tests become templates. The internal principal who paired with the forward deployed engineer becomes the next person capable of leading a deployment without one.
That is how this connects to How to Build an AI-Native Engineering Team, The Fifty Million Dollar Question, and The Tool Is a Commodity. The tool matters. The operating model matters more.
The first version of this role in most companies will fail. Good. Fail where the failure teaches you something.
If the forward deployed engineer cannot get one meaningful workflow into production with executive sponsorship, an internal pair, a product owner, explicit governance, and ninety days of focus, you learned something valuable. Your organization does not have an engineering bottleneck. It has an absorption bottleneck, a trust bottleneck, and a leadership bottleneck.
That is better to learn in one ninety-day program than after eighteen months of AI transformation theater.
Your people are smart. Your consultants were never magic. Your bureaucracy was always more powerful than you wanted to admit. AI did not remove that problem. It made the problem visible at a speed you can no longer manage with patience and steering committees.
So decide what you want to learn first.
Can a forward deployed engineer help your organization create a new path fast enough that your internal team can inherit it?
Or are you going to approve another SOW, hear your own engineers’ idea from someone with a different badge, feel relieved for thirty minutes, and then watch the bureaucracy eat the change anyway?
And one more question, because this is the one underneath the whole thing.
Is the future of software engineering forward deployed?
Not everyone, not every role, not every ticket. But the people who can sit with a customer, understand the work, open the system, build quickly, navigate the risk, and put the first useful version into production before the old machine finishes debating the intake path.
If that is the future, the old system does not have to end in a layoff deck.
It can become something better.
An organization where the people closest to the customer can build the first useful version. Where governance is explicit enough to move through, not vague enough to hide behind. Where managers create judgment, access, and air cover instead of controlling the queue. Where planning gets smaller because learning gets faster.
That is why this role makes people uncomfortable.
It is not just a new title.
It is a glimpse of the organization you would build if you were starting from the customer, the system, and the person capable of connecting them.
Companion
