Stakeholder Alignment for Forward Deployed Engineers: What to Do When Discovery Breaks the Plan

Stakeholder alignment is the stretch of an engagement between finding the real problem and writing the first requirement, where a forward deployed engineer gets every person with power over a project to accept the same version of reality. Most of the time it is routine. The time it matters is when discovery contradicts the mandate: leadership has approved a budget, promised a customer a date, and announced an AI system, and you have just found out that the system they announced cannot be built. What you do in the following week decides whether the engagement survives, and almost none of it is engineering.

I have written about the discovery call, about diagnosing the root cause when the stated problem is a symptom, and about the scope contract that records what you agreed to build. This post covers the gap between them: the case where the diagnosis is unwelcome, and each person who has to accept it has a personal reason not to. The material comes from the consulting track of my cohort, taught by a mentor who spent years at a strategy consultancy, and from a logistics case study he used to close the track. The case is fictional. The situation, he was clear, is not.

#The case: an AI dispatch system that cannot exist

A mid-size logistics company is missing its delivery promise. On-time delivery sits at 78% company-wide. Its largest B2C client, worth roughly 30% of revenue, about ₹120 crore, has a contractual 95% target and is threatening to leave. Leadership has responded the way leadership tends to respond: it has approved ₹2.8 crore for an AI route-optimisation system, told the client it will be live in 90 days, and brought in a forward deployed engineer to deliver it.

Discovery takes the story apart in three conversations. The tech lead who championed the idea talks fluently about latency, inference and model choice, and has never checked where the data comes from. The head of IT, who has been saying so all along, knows exactly where it comes from: a twelve-year-old warehouse management system that exports in batches, several hours behind reality, from a vendor who has never granted API access and whose contract carries a termination penalty. The operations manager's team is doing the routing by hand, on their phones, off stale exports, and that manual effort is the only reason the number is 78% and not lower.

Real-time route optimisation on data that is hours old is not a weaker version of the plan. It is a machine for producing confidently optimised nonsense, and the operations team, who already ignore the current system, would ignore this one too. My mentor's line for the room was blunt: if you cannot state this as the core problem by the end of discovery, you have already lost, because everything you build afterwards will be built on the wrong premise.

Getting to that finding is the discipline the earlier posts cover. This post is about what happens next, because the finding puts a specific person's career on the line, and how you handle that is the job.

#Stakeholder alignment starts with who you tell first

The four stakeholder personas map cleanly onto the case. The sponsor is the operations director who owns the budget and reports to the board. The champion is the tech lead who sold the AI system internally. The blocker is the head of IT, who controls security and compliance sign-off on anything that touches the data layer. The end user is the operations manager whose team routes by hand. The moment you know the data is stale, your instinct is to go to the sponsor. She owns the project, she has the most at stake, and she deserves to know. That instinct will end the engagement.

Go to the champion first. He is the person who will be blamed, and if the first he hears of it is from his director, quoting you, he will conclude that you threw him under the bus. My mentor's warning was that a champion converts to a blocker in about an hour under those conditions, and that a motivated insider has a hundred quiet ways to make a project fail. You also owe it to him. He treated you as a peer and staked his credibility on the work. Sit with him, say plainly that the assumption failed, and work out the answer together, which in this case is some form of middleware: a batch or hourly pipeline that pulls fresher data out of the old system so that anything downstream has something real to optimise.

Then the blocker, and with the champion beside you. The head of IT has been saying this would happen, and he is right, which makes him dangerous in two ways. Any middleware runs through his security and compliance process, so he can slow it indefinitely. And he knows the system better than anyone, so if he is not in the room when the middleware is agreed, he can say later that it was the wrong answer and something else would have worked. He needs to be turned from "I told you so" into "I will help you do it," which is only possible if he is treated as the expert he is.

Only then do you go to the sponsor, and you go with the champion and the head of IT already aligned, so that what she hears is not "your tech lead missed something" but "here is what we found, here is the answer, and here is the team that will deliver it." The operations manager joins that conversation, because the answer depends on his team adopting whatever gets built. Sequence matters more than content here. The same facts, delivered to the same people in a different order, produce a project with no owner.

#Never fight your own battles

The blueprint underneath that sequence is one my mentor said he learned early in consulting and has never had reason to revise: never fight your own battles inside a client organisation. Find the person whose battle it is, and arm them.

The reason is not diplomacy. It is that an external person has no standing. Before anyone hears your logic, they hear that you are not one of them, and rationality does not survive that filter. So internal battles about the project itself belong to the champion, who fights them as a peer. Commercial and timeline battles belong to the sponsor, because she is the only person who can walk into the board and say the 90-day promise has to be reopened. If you, the outsider brought in to deliver it, try to reopen it yourself, the room hears exactly one thing: that your technical capability is not good enough and you are hiding behind the schedule. That is a battle you cannot win, and my mentor's advice was to stop trying. Convince the champion, convince the sponsor, and turn a ten-against-one fight into a one-to-one.

The corollary is that the champion relationship is maintained daily, not checked in on weekly. He has to feel that you are the most useful person in his working life, because he is the one who will unblock things you cannot even see.

#Show movement, not a verdict

The sponsor's real question is never "can it be done." It is "what do I tell the board, and what do I tell the customer team." A forward deployed engineer who arrives with a verdict, that the AI deployment as announced is impossible in 90 days, has answered a question nobody asked and given her nothing to say.

The answer that works has three parts. The system as announced cannot be built on the current data, and here is why. The middleware plus the operations team's existing manual process can plausibly move on-time delivery from 78% toward 84 or 85% inside the 90-day window. And here is the path from there to 90% and beyond once the data problem is solved. The real world does not grade a 90-day mandate as pass or fail. It grades whether the number moved and whether the story is credible. Notice too that the operations team, which everyone in the case treats as the problem, is the asset: they are the only people who have made the number go up, and the middleware is built to help them do it faster.

#The noise stakeholders

Real organisations do not come with four people. The case deliberately adds two more, and my mentor said that if he were interviewing on this case, his questions would be about them: is she even important, what is your update to her, what do you make of the EV problem.

The finance controller does not control the budget, but he tracks a metric, cost per package, that the sponsor has named as her second priority, and he has a diagnosis of his own: the new electric trucks complete fewer trips than the diesel ones. He is right. The EV fleet is dragging throughput, it can be quantified, and it has nothing to do with why the routing misses its SLA. Left unmanaged, a confident person with a correct but adjacent diagnosis will turn a routing project into an EV investigation in one meeting.

The head of customer success controls nothing and absorbs everything. She takes the calls and the emails from the client that is threatening to leave. Twenty days into the build, the client escalates, she gets shouted at, and she transmits that pressure straight to the sponsor and then to you. She is not a problem to be handled; she is a person under pressure who cannot manage a conversation she has no information about.

Neither of them needs a daily or weekly cadence. Both need a cadence, and both need the same three-part answer, tailored. My mentor frames every update as what, so what, now what. The "what" is the same for everyone: the pilot is deploying, we are six weeks in. The "so what" and the "now what" change with the listener. For the customer success lead caught in a lift after a bad call, the so what is that the SLA starts moving in roughly eight weeks, and the now what is that she can tell the client that and ask for the time. She does not need the middleware architecture, and giving it to her would be a failure of the update, not a courtesy.

#Re-prioritise the scope contract when an assumption breaks

The failure that started the case was a single unverified assumption. A senior product leader said the data was available, everyone believed him, and nobody wrote it down as an assumption to check. The rule from the scope contract applies with full force: an assumption you log and that breaks is a scope change the client owns; an assumption you never logged is your failure. Verify anything a core architecture depends on, however senior the person who told you.

When the assumption breaks, the priorities have to flip, and the document should show it. The must-have is no longer the AI routing model; it is the data freshness fix, the middleware. Putting the model at P0 means committing to deliver it whatever happens, with a dependency you cannot control sitting underneath it. The model moves to should-have, as phase two. The real-time client dashboard the sponsor asked for drops to could-have. The EV fleet analysis goes to won't-have, as a separate workstream that is explicitly not this project. Each move is stated with its implication: if the data problem is not fixed first, the company spends ₹2.8 crore on a system that optimises stale inputs and that the operations team ignores exactly as they ignore the current one.

The dependencies section is where the outsider puts the uncomfortable options on the table without owning them. The vendor contract can be renegotiated or terminated. Yes, there is a penalty, on the order of ₹3 to 4 crore, and against it sits ₹120 crore of revenue at risk. That is not a technical decision and it is not yours, so it is written as a dependency on the company: if you can crash the vendor timeline, we can collapse P0 and P1 into a single phase. The operations team's adoption is the second dependency, written as a go-to-market plan for an internal tool, because the whole result depends on them moving from their phones to the middleware.

Written that way, the document reduces to five sentences you can carry into any room. This is the requirement, because this assumption failed, which changes the priority to this, otherwise this is the implication, and here is what we need from you. Every question the client or an interviewer asks about the case is answered by one of those five.

#When the champion turns anyway

Someone in the cohort asked the question everyone was thinking: what if you do all of this and the champion flips regardless, decides the project is a failure, and pushes it onto you. My mentor did not offer a tidy answer, and I found that more useful than a framework would have been.

The order is still the same. Go to the champion first and try the collaborative route. If he refuses, if it becomes "you have not thought this through, it is your fault, I will tell the director you are making excuses," then you go to the sponsor, without throwing him under the bus but without hiding the situation either, because at that point you are protecting yourself and there is nothing wrong with that. If the sponsor will not hear it from you, ask who she would hear it from, and bring that person in: a neutral expert for a day who can look at the warehouse system and say the same thing you said. And then accept that there is a real, non-zero probability it still goes badly. Discovery is time-bound and there is very little room to recover from getting it wrong, which is why he kept saying the only real answer is not to get it wrong.

#The documents are not the job

One of the more useful things my mentor said about this case was that he had generated the model answer with an AI assistant, and that this was fine. Given a structured case and the format of a problem definition sheet, a good model will produce a decent document in a few prompts. Writing the artefact is close to a solved problem. Two things are not.

The first is that real inputs are not structured. They are your own messy transcripts, and the skill of turning six conversations into "the warehouse system is batch-processed and that is the whole problem" is still yours to develop. The second is everything in this post: the sequencing, the battles you do not fight, the noise you manage, the update you tailor. A lesson he was given early in his consulting career, that the client is not a data ATM you withdraw requirements from but a human being with a career at stake, is the same lesson that separates a forward deployed engineer from a developer with a client, which is the distinction the pillar post on this site draws. Smartness, he added, is overrated. Nine times out of ten the problem is not hard. Handling the people around it is.

Alignment is the deliverable that comes before architecture. Once the sponsor, champion, blocker and end user agree on the middleware as P0, the routing model as phase two, and the vendor negotiation as a dependency, the requirements documents write themselves: one for the pipeline, one for the model, one later for the dashboard. Get the order of those conversations wrong and there is nothing to write requirements for.