For years, digital transformation has followed roughly the same playbook. A business team writes up its requirements, hands them to IT, IT hands them to a vendor or a dev team, and months later (sometimes a year later) a solution finally ships. By then the business has usually moved on to something else. The requirements have shifted, and a good chunk of the budget went into a discovery phase nobody quite remembers signing off on.
I've come to think the problem was never really the developers, or the business side, or even the tools. It's the distance between them. And I think the next wave of digital transformation is going to come from closing that distance, not from adding another process layer on top of it.
That's basically what Forward Deployed Engineering (FDE) means in practice: the person building the solution sits inside the business problem, instead of somewhere downstream of it.
Agile got us halfway there
Agile was supposed to fix this. Sprints, backlogs, standups, all of it was meant to shorten the loop between what the business needs and what actually gets built, and it helped, to a point. But in most of the organizations I've worked in, agile still runs through a relay: business analyst to product owner to developer. Each handoff loses a bit of context and adds a bit of delay.
Forward deployment cuts out a leg of that relay. The developer isn't sitting around waiting for someone to translate a requirement for them. They're in the room, watching the process happen, and they can ask the question that changes the whole approach before anyone's written a line of code. Needs get captured at the source rather than filtered through layers of documentation. I wouldn't call it "agile version 2" exactly, more like agile with one of its last barriers taken out.
From months to weeks
Over the past while, I've been digitizing a fairly complex business process, one spanning multiple stakeholders, a lot of legacy habits, and no shortage of "well, actually it's more complicated than that" conversations. Under the traditional model, that kind of process means months of requirements gathering before anyone even sees a working screen. And in my experience it usually means a few more months of rework after that, because the first version rarely matches what people actually meant.
What changed things for me was combining a forward-deployed way of working with "vibe coding" - building fast, working prototypes directly from a conversation with an AI coding assistant, rather than from a written spec that gets handed off to a build team later. A week is often genuinely enough now to go from a raw idea to a working mock-up. Not a slide explaining the concept - something a stakeholder can actually click through.
That's not just a speed gain worth mentioning in passing. It changes how the requirements get discovered in the first place, and that's really the part that matters for how a transformation program runs.
People would rather criticize than invent
Here's something I've become pretty convinced of after building out pieces of a complex digital tool this way: the fastest way to find out what end users actually need isn't to ask them. It's to put something in front of them and watch what they object to.
Ask someone to describe their ideal process starting from a blank page, and you'll usually get vague, cautious, fairly generic answers. Most people aren't naturally good at inventing requirements in the abstract, and that's not a failure of process, it's just how people think. But show them a rough mock-up and something shifts. Suddenly they have very specific opinions - that step happens before this one, actually, or nobody would ever click through three menus to get there. It's much easier for people to react to something concrete than to generate ideas from nothing. A mock-up turns a vague conversation into a specific one, and specific conversations are where the real requirements come out.
This is where forward deployment and vibe coding start reinforcing each other. When the build cycle is measured in days rather than quarters, you can afford to be wrong the first time. You show something, get sharp feedback, rebuild - sometimes within the same week. A mock-up stops feeling like a "deliverable" and starts working more like a question you're putting to the business, one they end up answering more precisely than most requirements workshops manage.
That's roughly how I approached the individual building blocks of a much bigger digital tool meant to digitize a business process end to end. Instead of trying to design the whole system upfront, each piece started as a quick prototype, shaped by whoever would actually use it, and got refined as their feedback came in.
Needs don't hold still, so capturing them shouldn't either
There's one more thing this approach fixed that agile never quite solved for me: needs keep changing while you're building. A requirement you captured in week one is often stale by week six on a longer project. The traditional way of working treats requirements as something you gather once and then defend against scope creep afterward.
Working forward-deployed with fast iteration does the opposite. You keep capturing needs continuously, because the developer is close enough to the business to notice when reality has moved. And because vibe coding makes iterating cheap, adjusting course doesn't have to turn into a formal change request sitting in someone's inbox. It's just the next version of the thing.
Where this needs guardrails
I don't want to present this as a free lunch, because it isn't one. Moving this fast puts a lot of decision-making in the hands of one person - the forward-deployed engineer - right at the point of contact with the business. That's exactly what makes it fast, and it's also exactly what makes it risky without the right structure around it. Architecture standards, security review, data governance - those can't be things an FDE is improvising in the moment. They need to get set once, centrally, and then built into the tools and guardrails the FDE actually works within, rather than re-negotiated on every project.
Speed at the mock-up stage isn't the same thing as production-readiness either. A week-one prototype earns its keep by validating the idea, not by being the code that quietly ends up in production untouched. And honestly, the whole model leans on finding people who can hold both the technical and the business conversation at once, which is a narrower hiring profile than a typical developer role.
None of that is an argument against the approach. It's an argument for treating forward deployment as an operating model that needs its own governance, not just a faster way to write code.
What this means for how you organize
For a transformation leader, the real implication isn't "hire developers who talk to the business more." It's more of a staffing and structure question: does your organization actually have a track - reporting lines, career path, incentives - for people who sit permanently close to the business, rather than treating that closeness as a temporary project assignment? Most organizations still route their best builders through central engineering pools and route business closeness through business analysts, and then wonder why solutions take months to reflect what the business actually meant.
The organizations that get ahead here probably won't be the ones with the best AI coding tools. They'll be the ones willing to restructure who sits where - putting a smaller number of highly capable, business-fluent builders directly inside the processes they're transforming, with clear guardrails around them, instead of running every idea through a long relay of handoffs. That's a people and org-design decision before it's a tooling one, and it's the one I'd want on the table before the next transformation roadmap gets written.