From Strategy to FDE: A Conversation with Hayden Krush
FDE at Lamar Health
Hayden Krush is a Forward Deployed Engineer at Lamar Health, a YC-backed startup automating specialty medication workflows for pharmacies and infusion centres. Before Lamar, he was a Strategy Analyst at Northwell Health, one of the largest health systems in the US. His background is in finance and business analytics, not computer science. We talked about how he got into the role, what prior authorisation actually involves, and why FDEs need to keep customers happy with what’s in front of them.
You don’t have a formal engineering background. How did you end up as an FDE?
I took a few CS courses in college and always had a passion for building things, but I didn’t pursue it full time. I was actually a finance and business analytics major. I didn’t want to go down the finance route, so I gravitated towards startups but didn’t know where I’d fit in.
At Northwell, my role was strategy. But I still had that passion for software engineering, so I used every chance I got to work on internal tooling. My most complex project was building a replacement for an outdated mapping software we were using. That thing was a nightmare. I swear it was made 30 years ago and never updated. I figured I’d try to make a replacement to make my life easier and hopefully everyone else’s too.
I didn’t have formal training, but I had a foundation from courses and personal projects. And AI is so good now. I was basically pair programming with it. Not fully vibe coding because I didn’t trust putting sensitive healthcare data into any LLM. But it would suggest things, and I’d learn from that.
Over time I got to the point where I thought maybe I could do this as a job. Internal tooling, making processes better, coding projects. That’s what I felt my passion was, even though it wasn’t part of my job description at all.
What does your day-to-day actually look like now?
No day is ever the same. Some days all I do is write emails from login to logout. Some days all I do is write code, and those are actually some of my favourite days. I can be heads down coding for hours and then take a break and realise it’s 4am.
Coding is sort of an escape. You know how much noise there is as an FDE. Messages from clients, from team members, from everyone. So much context switching. While that’s a big part of the job and I love it, it’s nice to really just focus and get stuff done.
What dictates how much coding I’ll be doing is entirely dependent on where I am with a customer. If we’re just getting started, there might be a week-long sprint to get the initial integration up. If we’re in maintenance mode, it’s just bug fixes and minor improvements.
You were on the provider side at Northwell. How does that experience change how you work with customers now?
There’s definitely overlap, but it’s completely different in the best way.
At Northwell, I led strategic projects for a region with tens of thousands of employees and billions in revenue. Each internal business unit was equivalent to an enterprise customer for my team now. I went from a company with over 100,000 employees to maybe five or six when I joined Lamar.
On the provider side, I never spoke with patients directly, but we’d get requests from internal stakeholders for analyses that would directly support them. Where are the medical deserts we can help provide care to? What specialties would be most beneficial if we opened a new practice in a certain area?
I felt like I was making real contributions, but the timelines were years long. You can’t just open a new practice the next day. It takes years for contracts, real estate, development. I was only there about a year, so I never saw anything I worked on get actualised.
Now I’m only one step removed. It’s us, then the specialty pharmacies and infusion centres, and they’re delivering care directly to patients. My timelines are days, not years. I get to watch my work translate to better patient outcomes in almost real time.
Prior authorisation is the process where providers have to get approval from insurers before delivering certain treatments. It’s notorious for being slow, error-prone, and full of back-and-forth. Lamar automates this for specialty pharmacies.
What’s the hardest part of trying to solve this?
There’s no way around it. It’s a messy process because it’s sort of designed to be that way. Insurance companies don’t want to authorise everything left and right. They want to make sure the patient really needs the care. Which is valid, but only to a point. Sometimes they make it too hard. And if a patient is on a tight timeline, that can have real consequences for their health.
Most customers experience the same overall issues. Payer policies aren’t clear about what’s required for approval. Sometimes everything is there and they still don’t approve it. So many things can go wrong. And it’s still a fairly archaic process. Faxes instead of online portals.
What we try to do is put as much in front of the user as possible upfront. We take away manual data entry using OCR to extract information from patient documents. We do our best guess to let them know whether we think the prior auth will be approved before they even send it. If something’s missing, we tell them what to request from the provider.
But the biggest issue isn’t identifying pain points. It’s how we go live and integrate to solve them. The hardest part for me is nailing down the requirements upfront where both the client and my team are happy. It’s so hard to capture everything, even when it’s right in front of you. Even when they give you an SOP and tell you everything they know, there’s so much they don’t know to tell you.
There’s tribal knowledge that isn’t documented anywhere. There’s all the negative cases. It’s easy to plan for the happy path, but how do you plan for the countless bad paths you can’t always predict? Then there’s the question of what’s scope creep versus what’s a necessary addition.
These things make requirements gathering both the most important and the most difficult part of the job.
In healthcare, you can’t really let an agent make guesses. How do you handle that?
We try not to let any agent or automation dictate anything that isn’t black and white. We don’t make guesses. We don’t make assumptions.
Even now, we’re strict about keeping objective decisions in the hands of the customer. Say we have two patients with the same first name, last name, and date of birth. We won’t ever guess which one it is. We make the customer choose.
There are steps we could take to figure it out. More comparisons between phone number, address, all that. But it would still be us using our best judgment rather than letting our customer be 100% certain. In healthcare, that’s not a path we want to go down.
One of the ongoing debates about FDEs is whether the work feeds back into the product or stays customer-specific.
How much of your work actually improves the product versus just solving a problem for one customer?
Pretty much all of it feeds directly into the product. At the end of the day, we’re not the ones using our product. The customers are. We can brainstorm big picture ideas, but they’re the ones who can tell us in real time what they actually need.
They’re submitting 400 patients a day. They have domain expertise I can’t replicate. I can’t look inside their minds and see how they’d view something.
While each customer has specific nuances, one thing that benefits one customer will likely benefit at least one more given that most of them share the same issues.
One thing that’s maybe counterintuitive: it’s usually the smaller features that benefit more than just one customer. Something as simple as a small quality of life improvement that one customer suggests. I think, wow, that’s such a simple fix that would probably help everyone.
The bigger features all require some level of tailoring. But the smaller ones? Sometimes it’s just a simple UI fix. All of a sudden it’s there and all users can benefit. Those are quick wins that make everyone happy.
How do you prioritise between big features and small fixes?
My view is that the highest priority is keeping the customer happy with what’s in front of them. Not hoping we make them happy with what’s to come.
If we’re getting complaints or suggestions about something that can improve their work right now, I want to fix that now rather than continuing to work on something that might not come for another week or two. If they’re unhappy now, I don’t want to let that sit.
They’re my customers. I’m the one talking to them. I just want to make them happy.
I think this is actually a key tension in the role. Do we roll out that large new feature we’ve been working on for weeks, or do we fix these small quality of life issues first? I might get too focused on the little things when there’s a bigger picture to consider. That big feature might unlock so much more in terms of workflow and revenue.
But when I’m getting emails every day saying “we’re running into this issue” or “we’d like this improvement,” it’s hard to ignore that and push it down. If they don’t even want to use what they have now, what good is putting a new feature in front of them? You might just end up with two incomplete features.
What would you tell someone with a non-technical background who’s considering an FDE role?
I don’t have that formal background, so I guess I am non-technical. But honestly, if someone has done enough research to even know the term “forward deployed engineer,” odds are they have enough of a foundation to succeed. I’d never heard of the role until this job, but immediately upon hearing the description, I just knew it was what I wanted to do.
If I had to pick one non-technical skill that’s crucial, it’s process analysis. Being able to break down a process clearly. Your mind should basically be a process flow diagram.
It’s one thing to break down a process into the visible steps. It’s entirely different to think about the steps you may not see. You know you need to get data from point A to point B, and you know how you’re going to do it. But how do you monitor the data in case you stop receiving it? What happens if you stop sending it? What happens if the file format changes randomly?
It sounds simple, but thinking about not just the step in front of you but everything that comes with it is critical. And it needs to be done for every single step.
The client can tell you everything they know, but they’ll still probably leave out 90% of the information you really need. It’s not their fault. They’re telling you what they think you need to know. The core responsibility of an FDE is knowing how to gather that invisible 90%. Critical thinking and process analysis are essential to that.
What surprised you most about the role?
Probably just how much stuff there is to do. An FDE role is like six or more jobs in one.
Some days I’m a deployment strategist. Some days I’m a software engineer. Some days customer success. Some days customer support. Most days I’m all of those in one.
I can only operate at 100% or 0%. If I’m not overwhelmed with things to do, I’m just not productive. As an FDE, 100% utilisation is my floor. There’s no downtime. There’s always something to do. I might bounce between 10 different tasks in a day, but that means there’s always 10 different things I can be doing.
The other thing I wasn’t expecting is the responsibility. Once the contract is signed, the customer is pretty much mine. I’m expected to handle everything from that point. All the emails, all the meetings, all the project management, requirements gathering, a good portion of the actual development too.
It’s really cool having that level of trust from my team.
Hayden Krush is an FDE at Lamar Health. They’re automating specialty medication workflows for pharmacies and infusion centres.