The First 90 Days on a Forward Deployed Engagement

Almost everything written about forward deployed engineering is about getting the job. Almost nothing is about doing it, and the first ninety days on a new engagement are where most of the doing goes right or wrong. Land them well and you build the trust and understanding that everything afterward depends on. Land them badly, by rushing to build before you understand, and you spend the rest of the engagement digging out. This piece is a practical guide to those first ninety days, written for the engineer who has the role and now has to succeed in it.

The advice here is deliberately concrete, because vague encouragement helps nobody standing in front of a new customer on day one. The genuine version of the role, taught properly through the Forward Deployed Engineering Program, is built on exactly this kind of disciplined early work, and getting the first quarter right is the difference between an engagement that compounds and one that stalls.

Key Highlights

• The first ninety days are for understanding before building, and the most common failure is reversing that order to look productive early.
• Split the quarter into three phases: learn the customer, deliver one narrow win, then expand from earned trust, roughly a month each.
• Resist the pressure to ship something impressive in week one, because a fast build on a shallow understanding usually solves the wrong problem.
• The relationships you build in the first month determine how much the customer will tell you, and how much they tell you determines whether you can build the right thing.
• Setting your working boundaries in this window is far easier than reclaiming them later, so do it before the pace hardens.

Why the first ninety days matter more than any later stretch

Forward deployed engagements have a compounding quality. What you learn and the trust you build early determine what becomes possible later, which means the first quarter carries disproportionate weight. An engineer who spends the first month genuinely understanding the customer can spend the next eleven building the right things. An engineer who skips that understanding spends the whole engagement building the wrong things faster.

This is why the first ninety days deserve a plan rather than improvisation. The instinct, especially for a new hire eager to prove themselves, is to start building immediately, because building feels like progress and understanding feels like delay. That instinct is the single most expensive mistake in the role. The customer's real problem is rarely the one stated in the first meeting, and the environment is rarely as documented as anyone claims. Time spent learning before building is not lost time. It is the investment that makes everything after it effective, and treating it that way is the mark of an experienced forward deployed engineer rather than a nervous new one.

Phase one, roughly the first month: learn before you build

The opening month is for understanding, not shipping, and protecting that purpose against the pressure to produce is the whole discipline of it. Your job in weeks one to four is to learn how the customer actually works, what their real problem is beneath the stated one, how their systems are genuinely put together rather than how the documentation claims, and who the people are that will make or break the engagement.

This is deliberate, structured customer discovery, and it is a skill rather than a formality. You are looking for the gap between what people say and what is true, the undocumented workarounds that reveal how work really happens, and the constraints nobody mentioned because they are so obvious to the customer that they forgot to say them. Resist every urge to jump to solutions during this phase. Every hour you spend understanding the real situation saves days of building the wrong thing later. The engineers who rush this month to look busy are the ones who, three months in, discover they solved a problem the customer did not actually have.

Phase two, roughly the second month: deliver one narrow win

Once you genuinely understand the situation, the second month is for delivering something real but deliberately small. The goal is not to solve everything. It is to ship one narrow, useful thing that proves you understood the problem and can build inside their environment. A single working capability that addresses a real pain point does more for the engagement than an ambitious half-built platform ever could.

The narrowness is strategic, not timid. A small, complete win builds trust, demonstrates competence, and gives you a real foothold in their systems from which to expand. It also validates your understanding: if the narrow thing lands well, your discovery was sound, and if it misses, you learn that cheaply rather than after a huge build. This is where technical scoping earns its keep, because choosing the right narrow win, something valuable, achievable, and revealing, is a judgement that separates strong forward deployed engineers from the rest. Deliver one thing that matters and works, and you have earned the standing to do more.

Phase three, roughly the third month: expand from earned trust

With a real win delivered and trust established, the third month is where you begin to expand, and the difference now is that you are building from a position of earned credibility rather than hopeful assumption. The customer has seen that you understand them and can deliver, which means they will tell you more, give you more access, and take your recommendations more seriously than they would have on day one.

Use that credibility to take on larger and more valuable work, often the agentic AI systems the customer originally hoped for but that you were right not to attempt before understanding their environment, and keep the same discipline that got you here. Understand before building, deliver in increments that each stand on their own, and keep validating that you are solving real problems rather than impressive-sounding ones. By the end of the first ninety days, a well-run engagement has a clear understanding of the customer, one or more real wins in production, a trusted relationship, and a credible plan for the value still to come. That is a foundation the rest of the engagement can build on, and it exists because the first month was spent learning rather than rushing.

The mistake almost every new forward deployed engineer makes

The dominant failure mode is worth stating plainly because it is so common and so avoidable. New forward deployed engineers, under pressure to prove themselves, build too fast and too early. They arrive, hear the stated problem, and start shipping within days, because shipping feels like the way to demonstrate value. It is the wrong instinct, and it is nearly universal.

The reason it fails is that the stated problem is rarely the real one, and the environment is rarely as advertised. A build launched on a shallow understanding solves the wrong thing efficiently, which is worse than solving nothing, because now there is code to maintain, expectations to manage, and a customer who has learned that you move fast in the wrong direction. The engineers who succeed resist this pressure. They tolerate the discomfort of not having shipped anything in week one because they know that a month of understanding produces better results than a month of premature building. This same eagerness to over-prove is what drives first-year burnout, and learning to resist it early serves you twice.

How to handle the pressure to show results early

The hardest part of running the first ninety days well is not knowing what to do. It is withstanding the pressure to do the wrong thing, which arrives from every direction at once. The customer wants to see progress for the money they are spending. Your own company wants evidence the engagement is going well. And your own eagerness to prove yourself pushes hardest of all. Under that combined pressure, spending a month understanding rather than shipping feels almost unbearable.

The way through is to manage the perception of progress without abandoning the discipline of understanding. Progress in the first month is real, it just looks like insight rather than shipped features, so make that insight visible. Share what you are learning about the customer's real problem, show that your understanding is deepening, and communicate a clear plan for the narrow win coming in the second month. This reassures everyone that the engagement is moving while protecting the understanding phase from being cut short. Customers and managers panic when they see silence, not when they see deliberate, communicated learning. The engineers who fail here are usually the ones who went quiet during discovery and then felt forced to ship something premature to break the silence. Communicate the learning, and you buy the time to do the first month properly.

When discovery reveals a harder problem than the one you were sold

Sometimes the first month surfaces something uncomfortable: the real problem is bigger, harder, or different from the one the engagement was scoped and sold around. This is one of the most testing moments in the early period, and how you handle it shapes the entire engagement. The temptation is to ignore what you have found and build against the original, easier framing, because raising the discrepancy feels like creating a problem. That temptation is a trap.

The better move is to surface it honestly and early, while it is still cheap to adjust. A problem discovered in month one and named clearly is a manageable rescoping conversation. The same problem discovered in month six, after you have built against the wrong framing, is a crisis. Bringing it up requires the trust you have been building and the judgement to know when to reset the original scope, but customers generally respect an engineer who tells them an inconvenient truth early far more than one who lets them discover it late. This is exactly why the understanding phase matters: it surfaces these discrepancies while they are still cheap, which is one of the highest returns the first month produces.

Build the relationships before you need them

The technical work of the first ninety days rests on a human foundation that is easy to neglect and expensive to lack. How much the customer tells you determines whether you can build the right thing, and how much they tell you depends on the relationships you build in the first month. People do not hand their real problems, their political constraints, and their undocumented workarounds to a stranger. They hand them to someone they have come to trust.

So the early weeks are as much about people as systems. Learn who actually makes decisions versus who holds the title. Find the person on the customer's team who knows how things really work and invest in that relationship. Understand who is threatened by the project and who champions it, because both will shape what you can achieve. None of this is manipulation. It is the honest work of understanding an organisation well enough to help it, and it is the foundation the technical work stands on. An engineer who builds these relationships early has access to the truth. One who neglects them builds in the dark, however strong their engineering.

Set your boundaries while it is still easy

There is one more thing the first ninety days are uniquely good for, and it has nothing to do with the customer's problem. This is the window in which you set how you will work, and it is far easier to set boundaries now than to reclaim them later. Before you have trained the customer and your own team to expect constant availability, you can define reasonable working patterns from a position of strength.

Decide, early, your response-time expectations, your travel limits, and how escalations reach you, and hold those lines while you still can. The pull in the opposite direction is strong, because a new engineer wants to say yes to everything to prove commitment. But the boundaries you set in the first month tend to hold for the whole engagement, and the ones you fail to set are nearly impossible to establish once the pace has hardened around your over-availability. Part of the discipline here is knowingwhen to say no to a request, a skill that starts in these first weeks and protects both your effectiveness and your longevity. Setting these boundaries is not a lack of dedication. It is what makes your dedication sustainable.

Start planning the handoff before you think you need to

It sounds premature to think about leaving an engagement during its first ninety days, but the engineers who create lasting value plan for the handoff from the beginning, and the early period is where that planning starts. The reason is that work which only functions while you personally are present is fragile, and an engagement that collapses when you leave was never as successful as it looked. Building for eventual handoff from day one is what separates durable value from impressive-looking dependency.

In practice this means documenting as you go rather than at the end, building in ways the customer's own team can understand and maintain, and involving their people in the work rather than doing everything yourself behind a curtain. It also means resisting the quiet temptation to become indispensable, which feels like job security and is actually a trap that pins you to one account and leaves nothing behind when you move. Theclean handoff is a discipline in its own right, but it begins in the first ninety days with choices about how you build and how much you bring the customer's team along. An engagement designed for handoff from the start produces work that survives you, which is the truest measure of a forward deployed engineer's success. Learning to build this way is part of what the Forward Deployed Engineering Program develops, because durable delivery is the whole point of the role.

A simple ninety-day framework

Pulling it together, the first quarter has a clear shape that you can hold yourself to even when the pressure to deviate is strong.

The phases are approximate and overlap in practice, but the sequence is not optional. Understanding precedes delivery, delivery precedes expansion, and each phase earns the right to the next. An engagement that tries to skip to expansion without the understanding and the win beneath it is building on sand, however capable the engineer.

The bottom line

The first ninety days on a forward deployed engagement are for understanding before building, and the sequence matters more than the speed. Spend the first month learning how the customer really works and building the relationships that give you access to the truth. Spend the second delivering one narrow, complete win that proves your understanding and earns trust. Spend the third expanding from that trust into larger work, keeping the same discipline throughout.

The near-universal mistake is rushing to build early to look productive, which solves the wrong problem efficiently and undermines the whole engagement. Resist it, set your working boundaries while it is still easy, and treat understanding as the investment it is. Doing the first quarter this well is a learnable discipline, and building the underlying capability through the Forward Deployed Engineering Program or by grounding yourself in agentic AI engineering is how you make sure that when the ninety days start, you are ready to use them well.