Bottom Line Up Front (BLUF)
Forward deployed engineering is implementation consulting rebuilt for new probabilistic based software systems. AI agents will make building these software solutions cheaper, but durability sits in the translation between a Profit and Loss statement and software behavior (including the software controls, change management, and owned capabilities). AI is quickly changing the tools to implement and increasing the pace of change, but it does not remove the need for the implementation discipline, nor the work needed to bridge the talent supply shortage we are currently facing.
Time Machine to 2014
In 2014, implementing a Laboratory Information Management System (LIMS) meant wiping my clipboard with isopropyl alcohol, gowning up in my blue bunny suit, and walking into ISO 8 and ISO 7 manufacturing areas.
The site made injectable IV bags across multiple manufacturing lines: saline, Lactated Ringer’s, and other terminally sterilized products (i.e., non-aseptic filled products). I was helping implement some of the LIMS workflows for biological and chemistry quality (BQ and CQ) on what was then Lonza’s MODA platform.
That meant locating the environmental monitoring points across the actual manufacturing plant. For example, that could be identifying physical tank-sampling valves or viable and total-particulate monitoring locations. Then, determining how frequently each one needed to be sampled. The BQ and CQ teams needed to know what sample to collect, where to collect it, and the sample scheduling to make sure they were compliant.
Also, those aligned answers had to be consistent across the process, the standard operating procedure, and the LIMS system configuration. If one of those aspects was incorrect, the software was wrong, and we could be at risk of a potential investigation (if you haven’t written a CAPA before, you’re in for a treat). The implementation also had to go through pharmaceutical software validation and hold up during an eventual FDA audit.
This overall exercise taught me one of the most valuable lessons of my career:
None of the implementation exercise started with the code. The process started with walking the floor, physically speaking with the operators doing the work, and translating that work into the software.
Implementation as a Discipline
Today, many folks would describe much of that implementation process as forward deployed engineering. At the time, my badge said engineer, but we didn’t call that work “Forward Deployed Engineering,” we just called it software implementation.
I am not making the old-man-on-the-internet claim that we secretly invented FDE first (I hope I’m not there yet, but my kids may say otherwise). Admittedly, the FDE title is also still useful, and the current AI assisted tooling genuinely changes what one person can build. My point is that the discipline underneath this new motion already had a name, a methodology, and history several decades before the current label arrived.
That methodology really narrowed down to business // technology translation; how can one translate a problem into a system that changes (and hopefully improves) the operation in a meaningful way.
See the below metaphorical translation “chain” that starts with the Profit & Loss (P&L) of the business and walks forward all the way to “reality” where things are executing and working within that business.
In the above translation chain, the software box is only one small part of driving improvements that translate back to the P&L of a business. If you enter the improvement process at the “software behavior” box, you are gearing up to learn an expensive lesson. By starting downstream, you inherently agree to every upstream assumption, and treat them as settled.
Starting this late, it’s much harder to challenge the process.
Outside of technical implementation chops, an FDE should be able to work through tough implementation questions about the process and push back where the best solution is NOT AI.
Likewise, as a buyer, I would hope and expect that an FDE would ask questions like:
Process Hops: Is this process handoff necessary?
Regulatory Requirements: Is it required by a regulation / law?
Change Management: Does this process exist because it is just “the way we have always done it?”
Exception Management: Is the exception actually exceptional or should it be a warning?
Outcome Measurement / KPI / OKR: Does the measurement metric measure the desired outcome of the process?
Optimization: Do we even need this process at all? (the most efficient process is an eliminated one)
Often, one of those assumptions / questions actually highlights the breakdown in the value chain.
ERP vendors built an enormous talent market around folks who could cross the gap between SAP transaction codes and a business process. Over time seasoned consultants would also build a heuristic understanding of where these flows would typically fall apart within an organization AND how to help redesign process around their system (partly for the betterment of the organization, but also partly because it made the ERP more sticky).
Over time, the implementation process became repeatable, and a competitive advantage for consultants. There was much time spent honing implementation methods, building talent development pipelines (through materials and a lot of on-the-job training), and even rate differentials for on/nearshore delivery. As the market saturated, the generic delivery DID get cheaper, but the domain expertise, business judgment, and apprenticeship / capability building genuinely remained scarce.
Back to the Present
With new capabilities (i.e., AI), the time it will take us to build repeatable implementation processes, build new implementation methods, talent development pipelines, etc. will almost assuredly decrease. Agent / software factories, lowcode agent builders, managed code environments (i.e., runtimes) and model provider tooling are already compressing the build and execution. At the same time, the frontier labs like Anthropic & OpenAI are investing billions in “last mile” implementation and delivery because access to foundation models does not guarantee a change in client operations.
I argued in my first article that the model was the small piece in a much larger ecosystem required to create value. When it comes to the FDE / talent play, the model IS a real difference in this wave because it enlarges the whole diagram rather than just one box. When you have these probabilistic models, you must embrace and defensively design systems that handle receiving different answers to the same question (the model is a software slot machine after all).
To resolve this, there are several best practices we have to consider in designing and building these systems (i.e., building continuous evaluation, ensuring your failures are loud and not shaped like successes, facilitating meaningful organizational change management, and being ready to manage the complexity of ongoing maintenance).
Consequently, these factors make the implementation discipline MORE important. With this in mind, it makes sense that the current demand for these folks is outstripping supply, but that leaves us with a new question…
Ok, how do we mint more of these people?
My current working prediction is that many excellent FDEs will come from business analysis, operations, domain roles, and automation engineering, not only conventional software engineering. Code is getting cheaper to teach and produce, and access to world class training materials is being created for free on YouTube and made available by the foundation model providers. However, twenty years of expertise and judgment from a niche domain continues to be scarce.
Therefore, while we shouldn’t lower the talent standard, we must consider broadening the talent pool to meet the demand.
Please check out the full essay including proposed hiring models here.
I’m curious where you draw the line between implementation and forward deployed engineering!
Have a wonderful week and upcoming weekend,
-T