Sensors in the Field: A Conversation with Rahul Agarwal
Co-founder and COO at Medplum
Rahul Agarwal is co-founder and COO at Medplum, an open-source developer platform that digital health companies use to build custom healthcare applications. Before Medplum he was Customer Impact Lead at Applied Intuition and spent several years on the Forward Deployed Machine Learning team at Palantir. We talked about running an FDE function without product managers, the rotating delegate system that keeps his team from each lobbying for their own customer, why he hires for slope over Y-intercept, and why he tells his FDEs that the role is essentially founder school.
To set the scene for readers who don’t know Medplum, what do your FDEs actually do day to day?
Medplum is an open source healthcare toolkit for developers. We make a set of Lego blocks for the most common healthcare applications, mostly EHRs, the systems doctors and nurses use to document clinical notes and order lab work and prescriptions. There’s a whole new breed of digital health companies building these at scale, fifty states, tens to hundreds of thousands of patients a month, but only for a narrow slice like specialty pediatrics. They need bespoke solutions. We took what a standard EHR does, exploded it into modules, made them open source, and let developers at these companies put the pieces together for their care model.
The hard part for our customers is making all those choices. Our FDEs have to be highly technical because they’re working with developers on the other side. You can’t just be a product person. A lot of our daily interactions are, “what is this error message, why didn’t my lab order go through to the lab.” But they also have to be good with people. Each of our FDEs supports between five and ten customers. We don’t send a team to a customer. One FDE supports many.
We didn’t found the company saying we’d have engineering, product, FDE. We don’t actually have a product team right now. The FDE function was born out of necessity, which I imagine is true for most companies hiring FDEs.
Most FDEs I speak to work directly with operators. Yours work with engineers who are building products for operators. How much harder does that make it to surface the tacit operational knowledge healthcare is famous for?
It’s a real challenge. The ideal is that engineers are our day to day but we have direct access to operators too. In healthcare there are two flavours. There’s clinical staff, the doctors and nurses doing care. And there’s an operational layer doing scheduling and billing, making sure patients move through the workflow. We want to get to both, or at least have a champion who can give us ground truth on the actual workflow.
Our engineering counterparts are strong developers but they’re often new to healthcare themselves. They don’t always know the right questions to ask. And when you do talk to operators, they describe how they currently do things, not how things should or could work. A lot of doctors at digital health companies aren’t doing it as their day job. They work in a hospital during the day and take telehealth visits on their off days, so when you ask them to design a system they bring all the baggage of their day job into the company.
So there’s a balance. We have to earn the right to talk directly to product or to clinical, but we also don’t want to get sucked into talking to ten physicians ourselves. Someone has to own the synthesis, and someone is always going to be unhappy with the result. We’d rather the customer’s internal stakeholders own that decision, with us guiding them based on best practice.
The reason that synthesis question is so loaded is that at Medplum, the FDE team is also doing the work a product organisation would normally do. I asked Rahul to walk me through how that actually functions.
Your CEO Reshma has talked publicly about Medplum running without traditional product managers, with the FDE team being how customer reality gets into the product. How does that actually work?
We probably won’t have PMs for at least another year. I’m not saying never, but FDEs are sensors in the field. They’re with customers every day, so they have a strong understanding of what customers need.
The challenge is combining those needs into generalised feature requests rather than building a hundred features that look almost identical, where this one is the way customer one wanted it and that one is the way customer two wanted it. That’s part of the argument for keeping core engineering separate. They have to build things that are general purpose by necessity. The organisational challenge is the connective tissue between FDE and core engineering.
Everyone has access to all code bases. FDEs are encouraged to contribute to the core. There’s no gatekeeping. It’s a division of labour.
The core engineering team has a weekly standup, and we send one rotating delegate from the FDE team to it. The FDE team does pre-work the day before to collate all the burning issues from customers and stack-rank them into one unified list across all features and all customers. The point is to avoid the anti-pattern I see at other places where every FDE is advocating for their own customer at the expense of others. If everyone goes directly to engineering and throws a ticket over the fence, the squeakiest wheel gets the grease. “Oh my God, this customer needs this tomorrow, this one is a high revenue deal, we need to do this thing that we all know is a bad feature.”
We make intentional tradeoffs among the FDEs. I know this customer is upset, but I will take the heat. We can talk about workarounds until the right thing is built. The unified list also gives the whole team visibility on what’s being requested. So if you hear a request that sounds like one from another customer, you have the familiarity to say, that feature is already in development, the thing in flight will suffice.
That’s how we do reconciliation without product managers. We might need PMs in a year as the team grows and these meetings stop scaling. But adding another layer is just another game of telephone between customer, FDE, and engineering. We’re trying to reduce telephone, not add to it.
One of the failure modes I hear about is core engineering and FDE turning into adversaries. How do you avoid that?
It’s a real anti-pattern. Core engineering starts to think FDE is always asking for everything tomorrow, because customers ask for things on customer timelines, not six-month timelines. The FDE team starts to think core is too slow, too much exploration.
The rotating delegate is partly an empathy-building exercise. Everyone gets exposure to engineering, inside their standard processes. You have to understand the trade-offs. If we did this the quick and dirty way, here’s what we lose. As a leader, you can say these are the same function with different responsibilities, but the teams have to actually trust each other. The FDEs need to understand that even if their customer needs something tomorrow, a hacky implementation has long-term costs. Core engineers need to understand that not everything can be perfectly designed, that there are real commercial factors and real customer pain. Even when customers aren’t doing things the way we’d like, they’ve made certain choices and we have to support them within a framework.
The other piece is the narrative inside the company. Even if it’s not true, the story can develop that FDEs are lower-quality engineers, body shop. Keeping the technical bar high is one defence against that. It’s easier said than done because you’re already asking for people skills and product judgement on top of engineering. But the bar matters.
You’ve got a public repo, a Discord, an issue tracker, paying customers and enterprise contracts running in parallel. Where does the FDE responsibility actually start in the customer lifecycle?
It’s a bell curve where the tails extend to infinity, but there’s a middle. We have a delegate to the sales process the same way we have one to engineering.
The sales process for an enterprise platform like ours has distinct phases. The first is, “hi, how are you, is this even a fit.” Salespeople handle that. Then there’s a technical capabilities Q&A. “Can it do this, how would it handle that?” I call it the “can Medplum do X?” phase. The important thing is that it’s stateless. It’s more about us than about the customer. So in that phase we have a rotating FDE on the hook for whatever calls come up that week, just to answer can-it-do-X questions across all prospects.
As we get deeper into the funnel, around a seventy per cent chance of close, we pre-assign a dedicated FDE. That’s before the deal actually closes, because close itself is fuzzy. There’s close-a-pilot and there’s close-for-real. By that seventy per cent mark things get stateful. You have to know a lot about the customer’s care model, their business model, their legacy system, their migration challenges. So we assign the dedicated FDE then, and by the time real building starts that person is already ramped up. Earlier than that, when they’re just kicking the tires, it’s too noisy to pre-assign.
Once the deal closes and the project starts, how do you make sure you have enough context to build the right thing?
That is the fundamental challenge. You need to get all the way into the belly of the beast of the customer, really understand what they want, what they need, even when they’re not asking for it. The key skill is telling them what they should be building (based on our experience), not just what they asked for.
The methodology we use is what we call our enterprise workshop. It works under the assumption that you’re not going to know everything. The goal isn’t to spend three months gathering all the context. You won’t, you never will. The goal is to prove that our product solves a problem in a very short time. We target one to two weeks.
When I tell customers we’re going to pick one thing and build it in two weeks, people lose their minds at first. “That’s too small. We’re a core system of record, we expected Medplum to solve all these problems.” But three months is forever. People dilly-dally until the last month anyway. They’re slow to respond, slow to get you information. By reducing the scope to one or two weeks, it forces customers to think smaller, and to actually pick one problem instead of saying everything is high priority but nothing is actionable. Decision-making on the customer side is the slowest part of all this. We can always match or exceed the customer’s energy.
The problem we pick has to be end to end, from user to back end, not three back-end features with no user input. And it has to be something better than their existing system, not a re-implementation. I want to focus on why they came to us in the first place. Their old system can’t do X, that’s why they’re considering us, so let’s work on X first.
Sometimes in two weeks we can’t get real usage, but we did force their engineers to talk to their clinicians and to their ops team. It sounds paternalistic, but I think of it as the connective tissue. Now they know how to build on Medplum, and they know who needs to be consulted for the rest. Over the following months they’re often already accelerated by that connective tissue alone.
If you were hiring your next FDE tomorrow, what’s the signal that matters most? And how much does healthcare background matter?
We assume no healthcare background. I had none before I started this company. My co-founders did, which was essential as a founding team, but we don’t require it.
When we hire we think about slope versus Y-intercept. We’re looking for high-slope people who have demonstrated they learn fast, that they’re motivated to own a whole thing and eat pain. They don’t have a lot of preconditions about what their work looks like.
Give me an example of someone who showed that.
A few stories. We have one person who was in an engineering department at their previous company and had been told not to talk to customers. Just focus on your job, head down. They learned a customer was suffering, disregarded orders, went and built the feature, and then built the internal buy-in for the broader migration. When the thing shipped and they wanted to follow up, the customer manager said that’s someone else’s job. But they wanted to break the mould and actually solve the problem.
Others came from more traditional sales engineering or solutions backgrounds and volunteered for the hardest customers. There are always little bugs at go-live, and they were the ones running into the fire. With others you just see them going beyond their job description. Even when they handed something off to a salesperson, they followed up to make sure the problem actually got solved, not just that they did their job.
A lot of leaders starting FDE teams now don’t have an FDE background themselves. What’s your advice to them?
I get the question a lot. Is FDE product, sales, engineering? There are different ways to make it work, but my bias is towards engineering. Treat it as an engineering function. Putting the team structurally inside engineering is one defence against the cultural anti-patterns. Keeping the technical bar high is another.
The rest is in the messaging. I deliberately use the terms division of labour and separation of responsibilities. These are the same function with different jobs to do, not different tiers of engineer. A leader can say that, but the teams have to actually live it, which is why the rotating delegate exists. It’s as much a trust-building ritual as it is a process.
Hiring is one thing. Keeping good FDEs is another. People don’t talk enough about retention. How do you keep someone who’s an excellent engineer, a good communicator, and has product instincts, when on paper they could do anything?
At least once or twice a month when I address the team, I remind them that FDE is basically founder school at Medplum. You’re going to be so pluripotent. You’re working on sales, you’re at the head of commercial conversations, you’re doing tech, you’re doing product. You’re already doing all the functions. If you put your founder hat on, even if you’re not an expert in all of them, you’ll have enough familiarity to go found your own company, hire those roles, and have judgement over them.
So it makes the good ones really hard to retain. If they’re good they’re going to go off and do their own thing at some point. I have to price that in and just keep hiring. We haven’t had churn on this dimension yet, but I’m not holding my breath. In some ways we’d want it to happen, to know we’re providing an environment that grows people.
I had this problem when hiring FDEs myself. Everyone I grew up with at Palantir has founded their own company. I can’t get my best FDEs to come work for me because they have their own companies.
The other thing that helps is that because we hire more for slope than Y-intercept, we can accept slightly more junior candidates than we would on the core engineering side. That creates a real opportunity for mentorship. We’ve defined an FDE lead role and an FDE mentor role. New FDEs need to hit the ground running. If I’m putting them in front of a customer in two weeks, they have to own those customers within the first one to two weeks. There’s a lot of content knowledge involved. Rather than me teaching them everything, senior FDEs mentor junior FDEs. So we’ve built a progression in, where you’re responsible not just for your own customers’ outcomes but for your mentee’s outcomes too.
Anything else you wanted to share?
One thing on AI and agentic coding. The question I always get is whether that means FDEs can be more or less technical because of the coding tools. I’m coming down conclusively on more technical. If an FDE is technical enough to actually read our codebase and understand the architecture, not just talk about it, they can sometimes ship a small bug fix in between meetings. We just got off the call, we already filed the fix, and because we’re open source we can point them to the PR. As a developer tool, there are so many small one-off things, and shortening that cycle is where the delight comes from.
Rahul Agarwal is co-founder and COO at Medplum. He’s hiring FDEs in the San Francisco Bay Area.