Welcome to Anchor Deployed / Lorikeet’s former Head of FDE: ownership is everything

Editor’s note: Welcome to the inaugural edition of Anchor Deployed. I’m grateful you’re interested in the topic of AI deployment and have made your way here. In this new series, my goal is to get into the details of the “forward deployed engineering” motion that Silicon Valley can’t seem to stop talking about. 

We’ll sit down with the leaders of AI deployment motions and rockstar deployment specialists. There’s some surface level on this topic out there and very little in the weeds. We’re going into the details. The goal here is to provide actionable insights that can be valuable to you, whether you’re an investor/board member helping a company think about whether/how to build a forward deployed motion, you’re the head of that motion yourself, you’re a current deployment specialist looking to advance, or you’re looking to break into the role. 

My asks from you:

Now, back to why we’re here:

I had the privilege to recently interview JJ Refling, a leader who has built out a Forward Deployed organization from scratch. JJ was, until recently, Lorikeet's Head of Forward Deployed Product and Engineering. JJ didn't just lead the forward deployed team: he built the company’s first FDE motion from scratch. In this interview, we talk all about what it was like to build the forward deployed motion from 0 to 1 and the lessons learned along the way.

Lorikeet builds AI concierges for complex businesses. They’re a global company headquartered in Sydney, Australia that has raised over $50M from QED Investors, Blackbird, and others.

JJ: For most of Lorikeet's customers, launching an AI concierge from scratch meant building a new muscle. That's where the forward deployed team came in: we needed technical all-stars who could work side by side with customers as they built it.

That work matters because without deep integration into a customer's systems, an AI agent is just a regular chatbot. What our customers actually needed was a concierge that could pull real customer data and act on it. Closing that integration gap is why the forward deployed team exists.

Integrating AI into customer support, namely, architecting the processes for a bot that can execute complex tasks end to end, involves many cross-functional stakeholders, and the forward deployed team helps those stakeholders see around corners while building out their AI CX operations.

Forward deployed engineers embed closely with customers to understand:

From there, FDEs do the building: they architect the workflows, build the technical integrations, and work alongside the customer's team to get the AI deployed into their live support operations.

JJ: We hired our first dedicated FDE about two years ago. They were one of the earliest hires on our go-to-market team. Now the forward deployed team is one of the most critical components of our go-to-market function.

JJ: Lorikeet builds AI concierges for complex businesses. What that means in practice is that we do chat support, email support and voice agents for businesses in verticals like fintech and healthtech.

JJ: The need we were trying to fill through hiring FDEs was to holistically help our customers solve real business challenges using Lorikeet’s tools.

We needed someone with a unique skillset: someone who could (1) work with our customers to deeply understand and internalize the challenges they were trying to solve, and (2) drive technical innovation for our customers as they integrate with AI and Lorikeet.

The final necessary component, especially for early hires: someone who could help me build the org. Not someone who was simply a rock star with individual customers, but someone who could identify patterns across customers, bring those themes back to me, and help build our overall team operations.

We did think through the other titles, such as solutions engineer, solutions consultant, and technical account manager. But none of these titles accurately conveyed the scope of the role. Being ‘forward deployed’ means to integrate deeply within our customers' organizations, become experts in their businesses, and then figure out how to best use Lorikeet to solve their hardest problems.

JJ: ‘Fully integrating’ means deeply understanding a customer’s business goals and challenges, and architecting creative solutions to achieve their goals.

One of our earliest customers at Lorikeet is a good example of what this looks like in practice. I really took the title "forward deployed" to heart and probably worked in their office >50% of the time during my first few months at Lorikeet.

When we reflect on our relationship with that customer, one thing the customer always remarks on very positively is the fact that "JJ sat in our office with us for four months while we were first working together." That level of co-location builds a level of trust that is so important when working with customers.

JJ: Physical proximity is a means to an end. The non-negotiable is to build deep connections with customers, but that can be done in different ways. Many relationships are best built in person, particularly around milestone moments like major launches, but you need to adjust to individual customer circumstances.

JJ: I joined in September 2024, and it was about three months before I hired our first full-time FDE. I had gotten a couple of reps and deeply considered a couple of things: What does the baseline operating model look like here? And even more so, who do I need to hire? What type of person will be right for both Lorikeet and our customers?

The biggest lesson I learned over those first few months was the value of embedding deeply in the customer's organization. Building relationships is incredibly important, both with direct stakeholders, and with the second- and third-order connections that let me help customers unblock themselves. I also learned that you need someone who is a creative problem solver, from both a technical point of view and a business point of view.

JJ: My number one recommendation is to do the job yourself before you hire for it. Until you've run a few deployments end to end, you're only guessing at the exact traits that you need. The reps are what teach you what the baseline operating model looks like, where deployments actually get stuck, and what type of person will be right for both your company and your customers.

The second thing I'd say is that your first hires will shape the org significantly. We didn't know exactly what we'd need six months out, so I hired technical generalists who were energized by ambiguity and could help me build the team. Then I let the role sharpen from there.

JJ: There was never a typical day. What I really viewed as my core role was hiring and team development. Early on, Lorikeet was growing really quickly, so I needed to figure out what our FDE hiring strategy looked like, and what kind of person we would bring in. For a while, probably upwards of 20% or 30% of my time was related to hiring and talking to candidates.

A large bucket of my time went to supporting the team. Oftentimes I took a "see-one-do-one" approach, especially early on: I'd work closely with them on integrations, help them build credibility with their customers, and show them what good looked like. Then I'd step back and watch them do it. My framework was: how do I help them level up their thinking and their process building?

The piece of work I'm most proud of at Lorikeet is the development of the folks on the team. The forward deployed role is incredibly ambiguous. It was brand new across the industry, and when I started the team, it was brand new at Lorikeet. I really enjoyed seeing people come into the role and figure out how they could use their unique skill set to spike their own careers, and then spike their value to the company and our customers. Because the team was relatively amorphous, managing it was a combination of directing and letting people figure out how they best add value, then watching them develop from there.

JJ: FDEs are such a great source of product feedback. It's really nuanced; we could talk at length about the benefits and the perils of using FDEs as a proxy for customers. That said, I really think the forward deployed organization is a natural home for a strong feedback loop.

FDEs are on the front lines of the way that customers use the product, and they're extremely well-positioned to be building the connections between engineering teams and end users. It's been both a challenge and an asset: it seems like all roads lead to the forward deployed team in one way or another.

JJ: One interesting thing about the FDE role is that part of the job is incubating new ideas that may eventually become first-class product experiences. And by incubate, I mean FDEs should be prototyping bespoke new products with their customers on a regular basis.

At the same time, there's a baseline expectation that they're providing really clear, rich product feedback to product and engineering teams so that things that FDEs are prototyping for individual customers can make it into the ‘mainline’ product. FDEs need to balance prototyping and shipping what their customer needs right now with collaborating with product and engineering teams to ship experiences for all customers.

In the end, all incentives are aligned. The more the product gets built to a user's specs and a user's standards, the more success an FDE can have. Where FDEs can add a ton of value, especially at early-stage companies, is helping to build that feedback loop.

JJ: Each day can vary, but the work generally falls into three buckets: scoping, planning, and execution.

Scoping is digging deep with our clients' technical stakeholders and understanding why our customers have built their tech stack the way they have. It's less about figuring out how we can integrate Lorikeet and more about figuring out where Lorikeet can have the largest impact on their business.

Planning is taking what we learned in scoping and mapping out the implementation: what to build first and how to sequence the work so our customer sees value as early as possible.

Execution is building out the workflows and the technical connections. What's interesting to me, though, is how that almost comes secondary, because it's the part of the job that is absolutely expected. The core value of an FDE is in how we work with our customers to navigate challenges along the way.

JJ: Two traits are non-negotiables for me when hiring FDEs. The first is a strong level of technical curiosity. FDEs are going to dive into tech stacks with wide variance: some are very AI-ready, others are more legacy. They need to be able to problem-solve across a bunch of technical layers, and they've got to get their energy at work through solving hairy technical challenges with customers.

The second is an ownership mindset: a demonstrated track record of taking a task and owning it to completion, no matter the roadblocks they encounter along the way. It's not as simple as following a checklist, but rather, the best FDEs that I’ve seen are incredibly tenacious problem solvers.

JJ: When I say technical curiosity, what I really mean is that the folks who succeed are the folks that get the most energy from their work when they are solving technical challenges. They’ve got to enjoy the process of solving the technical challenge.

This is different from integrating a product in more traditional companies, where, if you hit a roadblock, you tell your customer, "Okay, change X, Y and Z." When you’re forward-deployed, your job is to problem-solve with your customers and partner together with them to build a workable solution to challenges you run up against.

JJ: This has changed significantly over the past couple of years. A person without a traditional technical background certainly goes much further than they could before the days of Claude Code, but part of being forward deployed is to meet your customers where they’re at. 

The real challenge, and the real technical floor, is the ability to think and problem-solve on your feet and be a technical advisor. This means that the technical bar is still high.

I can't give you a metric such as three years of software engineering experience or an engineering degree. I never had that sort of bar in my hiring process. I looked to make sure the person had some sort of deep technical experience. That could be self-taught, or it could be more formal.

JJ: Oftentimes there’s a level of ownership over a metric or a goal that can be challenging to actually see on a resume, in terms of what their actual role was in figuring out how to move mountains to achieve their goal.

Folks can have a ton of successes on their resume, but you don’t know what tailwinds they had going into that. Or there can be the opposite, where folks maybe don’t have a ton of really clear wins under their belt, but the journey they took to get really close is actually a story of extreme ownership.

What I’m really looking for is to test out that ownership and get really specific with candidates on what they actually did to drive impact.

JJ: My favorite interview question is to ask FDEs to tell me when they were last in their flow state at work. I want them to paint a picture for me of a time when they felt like they were working in their unique zone of genius. I find that the answers really illuminate where folks are most effective.

Then I ask them, "Tell me about a time when you owned a project or a result end to end." What I'm really looking for is for them to demonstrate that they've been proactive in figuring out how to rally a team around solving a problem, and, when they hit a roadblock, how they led a team to get around it.

If someone tells me they hit a roadblock and handed it off to their team, that's an important signal. What I'm looking for is the person who was blocked and still took the problem to completion.

JJ: What I really want to see is a strong level of agency in the person I'm hiring.

I don't expect folks to come into initial conversations having done a ton of research on the company that they're interviewing with. People don't always have the time for that. But I want them to have some hypotheses around the challenges we're facing, and give me some clear examples around how they can bring unique value to the organization with their past experiences.

Really tactical examples from the past are of course very important. But the candidates who stand out tie their past experience to challenges they hypothesize we may be facing. They don't need to be correct. Past candidates have really impressed me by offering hypotheses based on the size and scale of the company: "They're at this stage. They've raised a Series A. They're probably thinking about scaling. I want to demonstrate a time in my past that I built a process that may be applicable."

JJ: The role is titled engineer, but ultimately the best FDEs are the ones who really internalize the business value they're adding for both their customers and the companies they work at. That’s how they’ll grow in their individual roles, grow their effectiveness with their customers, and grow the success of their company.

They need to figure out how their job ultimately ladders up to the business's success. If they can't articulate the business value that they’re providing, they need to work with their leadership to better understand the impact they were hired to drive. Taking that level of agency and ownership is how they learn to perform and operate in an ambiguous environment.

It's also really important for people who are building out a forward deployed organization to ask: What is your number one goal? What is the metric you're trying to drive? Implementation teams often get blinders on: they're a hammer looking at a nail, thinking, "How do I get this implementation done?" and ultimately miss the forest for the trees.

It can be really tough for folks to get their head above water and reflect on, "Why am I here? What metrics am I actually trying to drive for my customers? What is a successful implementation ultimately driving in terms of business value and business outcomes?"

JJ: It's important for folks to have a strong knack for pattern recognition and to identify common threads that they're seeing across their customer work. Once they identify the patterns, they can build playbooks so that they're not solving the same problem repeatedly.

Ultimately, it's not going to be a simple "Step one, do X. Step two, do Y." Customers are all different, and the underlying technology is improving very quickly. When the tech is moving that fast, you can't build a static playbook. What works is identifying high-level principles and sequencing that are relatively consistent across implementations.

While every implementation is unique, there are nearly always common patterns that folks can build processes around to make the team more effective at delivering value to customers. For example, there may be a common set of discovery questions / principles that you should dig into at the beginning of every implementation that minimize the chances of hiccups that may cause delays.

JJ: The best thing they can do is give concrete examples. They need to demonstrate to the recruiter or hiring manager a pattern they observed working in their current role, how they extrapolated that pattern, and how they brought that knowledge to the rest of their team.

Playbooks are called different things in different organizations, but the core concept is pattern recognition and then figuring out how to lead the organization to roll a new process out. Often that means leading from the side: convincing folks that your way is the effective way to do it.

JJ: It doesn't, actually. Two years ago, when I founded my first forward deployed team, I had extremely strong conviction that the function would be a growth driver for the company. I'm very excited that the role is at the place it is, newsletter included. But given the value I've seen this role provide to our organization, I'm not surprised at all.