A field engineer's view of the full customer lifecycle - from first discovery call through production scale-up at an AI infrastructure company.
The field engineer role doesn't show up on most org charts the way it actually works. On paper, you're somewhere between sales and engineering. In practice, you're the person who makes the product real in someone else's environment - from the first call where they're trying to figure out if you can help, through the months of work it takes to get them running production workloads.
This is how that arc plays out at an AI infrastructure company. The specifics will vary, but the shape of the engagement is surprisingly consistent across enterprise technical sales.
Discovery: figuring out if there's a real problem
The first conversation is almost never about your product. It's about their problem. A machine learning team is hitting scaling limits. Training jobs are taking too long. GPU utilization is embarrassingly low. They're duct-taping together internal tools that nobody wants to maintain. Or they've been told by leadership to "figure out AI infrastructure" and don't know where to start.
Your job in discovery is to understand their world well enough to know whether your platform actually helps. That means asking questions about their current stack, their team structure, their data pipelines, their deployment targets, and their timeline. It also means listening for the things they don't say - the political constraints, the previous failed attempts, the competing internal project that nobody wants to kill.
Good discovery produces a clear picture of the gap between where they are and where they need to be. Bad discovery produces a demo request.
Architecture: mapping their problem to your platform
Once you understand the problem, you need to figure out how your platform fits into their existing infrastructure. This is where the engineering starts. You're reading their code, understanding their deployment topology, figuring out where the integration points are, and identifying what needs to change on their side versus what the platform handles.
This phase often reveals that the problem they described in discovery is not quite the problem they actually have. The training bottleneck they called about turns out to be a data loading problem. The "scaling issue" is actually a serialization bug in their training loop. The infrastructure question is really an organizational question about who owns what.
Architecture work produces a technical plan that's honest about complexity. It accounts for their existing systems, their team's capabilities, and the constraints they're operating under. The plan that ignores any of these things will fail during implementation, and you'll be the one explaining why.
Proof of concept: making it work with their data
The POC is where the engagement gets real. You're running their workload on your platform, usually in their environment, with their data, under their security constraints. Everything that was theoretical in the architecture phase now has to actually work.
POCs at AI infrastructure companies are particularly demanding because the workloads are expensive. A training job that takes 8 hours on 64 GPUs is not something you run casually. You need to get configuration right before you burn compute. You need monitoring in place so you can diagnose problems without rerunning the whole job. You need to show measurable improvement over their current approach - faster time to completion, better GPU utilization, simpler operations - or the evaluation ends here.
The POC is also where you learn how the customer's team actually works. Who's hands-on-keyboard. Who has opinions but doesn't write code. Who has veto power. Who's been quietly skeptical the whole time. These dynamics determine what happens after the POC succeeds.
Technical win and procurement: two different finish lines
A successful POC gives you the technical win - the engineering team agrees this is the right platform. But the technical win is not the deal. The deal requires procurement, legal review, security review, budget approval, and sometimes executive sign-off from people who have never seen a demo and don't care about GPU utilization numbers.
This is the phase where field engineers often feel useless. The work shifts to legal redlines, procurement timelines, and budget cycles. But there's a critical job to do here: keeping the technical champion engaged and armed with the information they need to sell internally. That means ROI calculations, migration timelines, support SLA details, and competitive comparisons - all translated into the language their leadership uses to make decisions.
The gap between technical win and closed deal can be weeks or months. Deals die in this gap more often than they die in POC.
Onboarding: the work that looks easy and isn't
The deal is signed. Now you're onboarding a team that may or may not include the people you worked with during the POC. Knowledge transfer is the immediate problem. The engineer who ran the POC understands the integration, but they're one person. The platform needs to be usable by the whole team, which means documentation, training sessions, and sometimes rearchitecting the integration to be simpler than what the POC required.
Onboarding is also where you discover the things that didn't come up during evaluation. Authentication requirements that weren't mentioned. Network policies that block the communication patterns your platform expects. Internal tooling that assumes a specific deployment model. Each of these is a small fire that needs to be resolved before the team can do real work.
The quality of onboarding determines whether the customer uses the platform or becomes shelfware. A customer who hits three blockers in their first week forms an opinion that's very hard to change.
Production scale-up: where it actually matters
Getting to production is the real milestone. The customer is now running their actual workloads - not POC experiments, not toy examples - on your platform. The stakes change. Downtime has consequences. Performance regressions affect their release schedule. Cost overruns affect their budget.
Scale-up exposes problems that don't exist at POC scale. A training pipeline that worked fine with one job at a time breaks when five teams are competing for the same GPU pool. A data loading pattern that was fast enough for a single dataset falls apart with production data volumes. The monitoring that was adequate for an evaluation isn't enough when oncall needs to diagnose problems at 2am.
This is also where the relationship shifts. During pre-sales, you're trying to win their business. In production, you're trying to make them successful. The field engineer who stays involved through this transition is worth more than any support ticket system, because they carry context from every previous phase. They know why the architecture looks the way it does, what was tried and rejected, and what the customer's team is actually capable of.
The thread through all of it
What connects these phases isn't a process or a playbook. It's continuity. The field engineer who does discovery understands the customer's real problem. The person who does architecture knows the constraints. The person who runs the POC knows where the bodies are buried. The person who does onboarding knows what was promised and what was improvised.
When one person carries that context end to end, the engagement works. When it gets handed off between teams at every phase boundary - sales to solutions to customer success to support - each handoff loses information. The customer ends up re-explaining their problem to every new person, and the new person ends up re-learning things the previous person already figured out.
The best customer outcomes come from the shortest path between "I understand your problem" and "it's running in production." Everything in between is the field engineer's job to compress.