The week Forward Deployed Engineering (FDE) officially launched at PagerDuty, one of my engineers and I decided to find out what this new model could actually do.

A traditional Professional Services engagement had hit a feature gap. Real blocker. Go-live at risk. Under the old model, that meant a support ticket, a roadmap conversation, and a wait.

We fired up our AI Delivery Workbench and pulled up the engineering team’s repo. Neither of us had any meaningful experience with Elixir. Didn’t know the stack. Didn’t know the deployment process. Didn’t matter. We read the patterns, studied how similar PRs had been written, and submitted one of our own.

From problem to product in hours.

That phrase became our North Star. Not because of the speed. Because of the word product. Not a workaround. Not a Lambda someone else has to maintain. A shipped fix, in the PagerDuty product, available to every customer.

Getting to a place where that was even possible took seven years. This is that story.

I joined PagerDuty in late 2017 as part of what was then called Expert Services. If you’ve worked in enterprise software, you know the model. SOW consulting. Time and materials. Help customers get configured, integrated, adopted. Move on. It was traditional professional services, and we did it well.

As leadership changed, the team became Professional Services. I grew into staff+ level IC consulting roles. Good work. Real value. Customers got better.

But the engagements were bound by design.

We’d come in, do the work, hand it off, and leave. The gap between what we knew about a customer’s real problems and what the product could actually do for them? That gap stayed open. A short-term engagement model wasn’t built to close it.

What would it look like if we actually stayed?

In 2019, a large national broadcasting and media company needed something we didn’t have an existing offering for. Not a workshop. Not a project. Someone who could come in, understand their environment, and do the work. Design it. Build it. Deploy it. Go live. Train the team. Own it until it was truly theirs.

So I did that. For six months, I was embedded with their team.

I was the solution architect, the developer, the deployment engineer, the trainer, and the person on Slack at 9 pm when something broke.

I should be upfront: I’m not a developer by nature. What I have is grit and an absolute refusal to let “I don’t know how to do this yet” be the end of the conversation. Over those six months, that meant figuring out things I had no business figuring out, one problem at a time, until they were solved.

And something unexpected happened inside that engagement.

Working closely with the PM on our ServiceNow Incident Management integration, I designed and built an addition to that solution. Something that came directly from living inside the customer’s environment. Because of the relationship I’d built with that PM, and because the work was genuinely good, that contribution shipped in a production GA release that year.

I cannot overstate what that moment meant to me personally.

After years of building things around the product, beside the product, and adjacent to the product. Something I built from a customer engagement made it in. Into the product. Available to everyone.

Unfortunately, that excitement faded faster than I expected. The conditions that made it possible were hard to replicate. It would take years more before what happened in that engagement became something repeatable and built into how PagerDuty operates.

But the seed was planted. And I never stopped believing it was possible.

Looking back, that was the first FDE engagement. We just didn’t have a name for it yet.

The embedded model worked. Deals won. Accounts expanded. Customers retained. Sales teams noticed. Leadership noticed.

During PagerDuty’s rapid growth years, the Professional Services team kept getting pulled into a harder conversation. Not “help us implement PagerDuty.” Something more like: “We need to do something PagerDuty can’t quite do yet. Can you?”

The honest answer, more often than not, was yes.

We started building. Not inside the product. Around it. Integrations, automation frameworks, workflows, and custom solutions running in our own Professional Services AWS environment. Things that made PagerDuty stickier for our most important customers. Things that let the sales team say yes when the old answer would have been “put it on the roadmap.“

The returns were real. So I proposed making it official.

Innovation Services and Scaled Delivery (ISSD) was born. At its peak, nearly 40 engineers and consultants. Thousands of hours of delivery annually for our most strategically important customers. I’m genuinely proud of what that team built.

But I’ll be honest about how we built it. Wild West style. Python or nothing. Outside PagerDuty’s architecture standards and security controls. No on-call rotation. No SLA. We’d hand over a Lambda, document it as best we could, and move on. Every solution was its own island. Every problem was solved from scratch for the next customer six months later.

We kept solving the same problems.

Not similar ones. The same ones. Different customers, same requirements, different AWS environment, different Lambda nobody would maintain in a year.

And the reach problem never went away. PagerDuty had thousands of customers. ISSD was serving hundreds. Everything we built in isolation represented value that the vast majority of customers would never see.

We were building the right things. In the wrong place.

I’ll be honest: I didn’t see it coming.

I wasn’t drafting a proposal. Wasn’t lobbying for a new reporting line. The team was heads down delivering. The conversation that changed everything came to me, not from me.

Our Chief Product Development Officer and Chief Customer Officer grabbed me in a Zoom meeting and named what they were seeing. A team with genuine, rare capability. Deeply technical. Deeply connected with customers. Able to move fast and deliver outcomes that neither pure Professional Services nor pure engineering could replicate. But all of it aimed sideways, at the space around the product, instead of forward, into it.

Their words landed because I’d been living the frustration they were describing for years.

The proposal: move the team under Product Development. Sit alongside the SVP of Product and the SVP of Engineering. Build and ship capabilities into PagerDuty, not around it.

That org chart change wasn’t cosmetic. Where you sit signals what you are and what you’re accountable for. This team is part of how PagerDuty builds. That was the statement.

But an org chart is just a box on a slide until you earn what goes inside it.

We weren’t walking into neutral territory. Before FDE, another field team had built customer-facing solutions that generated real excitement and genuine value. Through sheer force of customer escalations, they shifted the product roadmap. Sounds like a win. In practice, it left scars.

The solutions were built in non-standard, non-scalable technologies. When engineering tried to move that work into the product, they couldn’t build on any of it. Every line of code was scrapped. Rewritten from scratch. Engineering felt handed a mess and a mandate at the same time. Nobody was happy. And that history was alive in the room when FDE showed up asking to ship code into the product.

We didn’t try to talk our way past it.

We embedded. A lead FDE engineer was onboarded directly into a product feature team. Not as a visitor. As a virtual team member. We learned their norms. Their coding standards. How they wrote PRs, tested, and shipped. We didn’t ask them to adapt to us. We adapted to them. The Wild West era was over.

Are we perfect yet? No. But that’s what the FDE flywheel is for. Every PR, every standard learned, every piece of feedback incorporated makes the next contribution faster and better. Each cycle compounds. Yellow zones become Green zones. Velocity increases. The gap closes.

That’s the trust we’re earning. One commit at a time.

After all that story, I’ve earned the right to answer this properly.

Here’s how I explain it to someone hearing about FDE for the first time: it’s not a new name for Professional Services. Not a Technical Account Manager program with engineers. Not a skunkworks team building prototypes that never ship. And definitely not a Wild West AWS environment with no SLA.

FDE is the connective tissue between three groups that rarely operate in genuine partnership in most software companies: the field and customer teams closest to the problems, the product and engineering organization that builds the solutions, and the customers whose outcomes determine whether any of it matters.

Field teams surface signals constantly: Blockers stalling deals. Adoption gaps threatening renewals. The same feature request showing up across five customers in one quarter. Those signals are used to get triaged into a backlog and wait months or years. FDE intercepts them early, assesses feasibility and business impact, and executes in partnership with PM and EM counterparts.

We call this the FDE Deployment and Engagement Flywheel: Signal Detection, Assessment, Execution, Learn and Scale. Four stages. Continuous rotation. The compounding effect is the point. Each cycle, FDE engineers become more familiar with the codebase. PM and EM partners better understand our capabilities. Patterns get richer.

We work inside a Green, Yellow, Red zone framework that defines where FDE can contribute independently, where we collaborate, and where core engineering owns the work. We onboard into each product area by learning the zone map first. Then the codebase. Then we earn the right to contribute before we contribute.

Forward Deployed Engineering is the bridge between what customers need and what the product becomes. Customer problems that actually make it into the product. Not as a Lambda someone forgets to maintain. As a shipped feature. Available to every customer. That’s the whole point.

The FDE team didn’t happen by accident.

When I built ISSD, I hired differently than anywhere else in PagerDuty. The technical bar mattered. It wasn’t the filter. The filter was harder to put on a resume.

Could this person walk into a problem with no playbook, unfamiliar tools, a codebase they’d never seen, a customer with no patience for uncertainty, and figure it out anyway?

Not everyone can. Most people don’t want to. There’s real comfort in a well-defined scope and a known stack. That model builds great products. It’s just not what FDE needs.

What we hire for is the person who runs toward the ambiguous challenge when everyone else quietly finds something better-defined to work on. More grit than the situation calls for. When handed an unfamiliar tech stack and a go-live deadline, they don’t ask for more time. They ask for access to the repo.

Those people are hard to find. When you find them, you don’t let them go.

The FDE team is full of them. Genuinely exceptional people. Deeply technical, deeply customer-focused, committed to outcomes. The flywheel, the AI-first tooling, the PM and EM partnerships. None of it works without the people turning the crank.

Which brings me back to Elixir.

That first-week PR wasn’t a fluke. It was proof. Grit plus the right tools changes the math. Our AI Delivery Workbench makes it possible to move into unfamiliar territory fast, read patterns, contribute at a standard the product engineering team respects, and ship. From problem to product in hours is not a tagline. It’s an operating standard.

The FDE team is AI-first by design. The problems our most strategic customers bring us are AI problems. Alert noise at scale. Automating low-judgment repetitive work burning out on-call engineers. Cutting through the noise to surface relevant context exactly when responders need it most. We’re building agents. Shipping product features. Using PagerDuty to run PagerDuty and feeding what we learn back into what we build.

This post is the first in a regular series from the FDE team on the PagerDuty Engineering Blog. Every month, you’ll hear directly from the engineers and FDE product managers doing the work. AI architectures. Agent frameworks. Product problems. What we’re learning from sitting at the intersection of customer reality and product development. Engineering content. From engineers. About actual work.

One foot in the customer’s world. One foot in the product organization. Both hands on the keyboard.

In the months ahead, you’ll hear from all corners of FDE: FDE Engineering, FDE Delivery, AI & Customer First, and Product Management. Each has a distinct story to tell. Each will tell it.

Welcome to Forward Deployed Engineering at PagerDuty.

It started with one engineer, six months embedded with a customer’s team, figuring it out alone. Today, it’s a team shipping AI-powered capabilities into a product used by thousands of companies worldwide, through a flywheel that compounds with every rotation.

That’s what Forward Deployed Engineering looks like when it works. Stay tuned.