Hand Them the Keys
On FDE onboarding, early ownership, and what we learned from getting it mostly right.
When a new software engineer joins a team, the traditional playbook is well established. Spend the first week reading documentation, getting familiar with the codebase, setting up your local environment. In week two, maybe pick up a small bug. By month two or three, you start owning a feature. It’s a gradual handoff of responsibility, widening in scope over time. AI tooling has probably compressed this timeline significantly by now, but the underlying logic is the same: start small, expand slowly.
When we onboarded our newest FDE at Lleverage, he was running his own client within two weeks. That’s not because we were reckless. It’s because FDE onboarding operates on a fundamentally different logic.
Ownership from day one
The core difference between onboarding an engineer and onboarding an FDE is that FDEs need to own things end-to-end from the very beginning. The unit of ownership isn’t a module or a ticket. It’s an outcome for a client.
The scope starts small, of course. A proof of concept. An extension to an existing solution. But even when the scope is small, the ownership is complete. You’re not fixing someone else’s bug. You’re figuring out what the client needs, how to build it, and how to deliver it.
When I started at Lleverage, my first two days looked like what we do when we begin any client engagement: gathering context. Meeting after meeting, absorbing everything I could about the sales process, the platform, the technology, existing customers, how the team operates. Two days of listening and asking questions.
On day three, a colleague from the sales team walked over. We need someone to run a PoC for a prospect. Can you pick it up? The demo was due in two days.
I said yes, obviously. You don’t join a role like this and hesitate when someone hands you a real problem to solve. But looking back, that moment was the best onboarding decision anyone made for me. It forced me to learn the platform not by reading about it, but by building something on it under a real deadline. I was paired with someone who could show me the basics, give me that initial push, and then I had to figure the rest out.
By the end of my first week, I was already picking up existing clients, maintaining their solutions, and starting to think about where those solutions could go next.
The layers underneath
What makes FDE onboarding uniquely dense is the number of dimensions you’re absorbing simultaneously. It’s not just “learn the codebase.” There are distinct layers, and they all matter.
There’s the platform itself: how you build on it, its capabilities, its constraints. There’s the project management side: how we track work, communicate progress, manage timelines across multiple clients. There are the clients themselves: their industries, their systems, their stakeholders, their particular expectations. And then there’s the internal layer: how the team works, how decisions get made, what the culture around quality and pace looks like.
A software engineer might absorb these layers over months, one at a time. An FDE has to take them all in more or less at once, because the moment you sit in a client meeting, all of these layers are active.
Calibration, not probation
When our newest FDE joined a couple of months ago, we followed the same instinct. He shadowed me on an existing client for about two meetings. Then he started picking up tasks. Within two weeks, we’d done the full knowledge transfer and he was in charge of that client relationship. By the end of his first month, he’d taken on a completely new client from scratch. He’s now onboarding with a third and fourth in his second month.
That pace might sound aggressive, but it reflects something important about how we think about onboarding. If you’ve done the hiring process right, you should be at least 95% confident that this person can do the job. The hiring process itself, its entire purpose, is to establish that baseline.
So the onboarding period isn’t a trial. It’s a calibration. You’re not figuring out whether someone can do the work. You’re figuring out how quickly you can increase scope, how soon they can handle bigger clients, more complex projects, more simultaneous engagements. The approach is to stretch people relatively quickly, to find out where their ceiling might be, without actually pushing them to a breaking point. That’s very different from the cautious approach of holding back responsibility because you’re worried about overloading someone.
Our newest hire came from a technical background, fresh from university but with a couple of years of building his own companies behind him. The entrepreneurial experience was a strong signal: someone who’s built products, talked to customers, handled the pressure of making things work with limited resources. That profile told us a lot. It was just a question of how quickly he’d adapt to this specific context. He adapted faster than we expected.
Staying close
How do you actually monitor all of this without micromanaging? For us, it starts with regular check-ins. Bi-weekly conversations between mentor and mentee, in addition to the normal managerial ones. Those check-ins are a mix of practical and personal: how are you feeling, what’s blocking you, but also let’s talk through this specific client situation.
Beyond the structured check-ins, physical proximity matters. I don’t mean this in a “remote work doesn’t work” way, plenty of FDE teams operate remotely and do it well. But in our case, sitting next to each other in the office made a real difference. I told my mentee early on that I don’t mind being interrupted. That I’m available for questions whenever they come up, within reason, but that it has to come from them.
That last part is deliberate. I’m not going to chase someone down and ask if they need help every hour. I make myself available, I show that I care, and then I let them come to me. There’s a practical reason for this: I have my own clients and my own work. But there’s also a diagnostic element. A big part of the FDE role is asking questions. When you’re with a client, you need to ask constantly, probe, clarify, push back on assumptions. You should never be embarrassed to say “I don’t understand, can you explain that again?” If someone is hesitant to ask their own mentor for help, that’s a signal. It might mean they’ll also hesitate to ask the client, and instead build something based on what they think they understood rather than what actually needs to happen.
In the early days, I sit in on client calls so the new FDE can shadow. One or two calls to observe the dynamic, understand how we communicate, see how conversations flow. Then they start taking over gradually: leading parts of the call, then running the whole thing while I observe, and eventually handling it independently.
The KPI through all of this isn’t code quality or technical elegance. It’s whether the client is happy and the solution is delivering value. That’s what’s measurable, and that’s what matters. If the solution works and the client sees results, the code behind it is secondary.
The gap we found
If I had to identify the one thing we got wrong, it’s that we didn’t spend enough time walking through existing solutions.
When I started, I got a broad overview of what was in production: the different clients, the different use cases, the general landscape. But the emphasis was, rightly, on the clients I’d be taking over. With our newest FDE, we did even less of this. We jumped straight into client work, gave him context on the solutions he’d be owning, and moved quickly.
It worked, but in retrospect, we left something on the table. There’s real value in sitting down with a new FDE and walking through a range of completed and in-progress solutions. How we typically collect data. How we handle integrations that aren’t native to the platform, where we’re relying on HTTP requests. How we move from development to production. How we manage credentials. When we use LLMs versus structured workflows versus full agentic setups.
These are patterns. And you only develop an instinct for them by seeing enough examples. Our mentee said it himself: seeing more of the existing work earlier would have accelerated him further. He was already moving fast. But that kind of pattern recognition, knowing that “oh, this new client’s problem looks a lot like what we already solved for another client,” saves real time and produces better solutions.
If I were redesigning the onboarding, I’d keep the same structure of short, focused sessions spread across the first week, anywhere from one to two hours each, covering different aspects of the platform, the solutions, and the workflow. But I’d add a dedicated track that walks through the architecture and patterns of existing solutions, not just the ones the new FDE is picking up. And I’d leave room between those sessions for them to explore on their own, to identify their own gaps and focus where they feel weakest.
When I started, for example, I was coming from six years of working directly with enterprise customers. I was confident in how I communicate with stakeholders, how I run meetings, how I manage expectations. But I was rusty with coding and building. So that’s where I put my own focus in those early days. Everyone’s profile is different, and the onboarding needs to accommodate that.
Good enough is good enough
One more thing that’s important to instil early, especially in a startup environment, is the idea that things need to be done well but not perfectly.
Every good engineer has high standards. That’s a feature. But in an FDE role, those standards need to be in service of the client’s outcome, not your own sense of craft. Sometimes you ship something that you’re not 100% happy with. The architecture isn’t as clean as you’d like. The edge case handling is functional but not elegant. If it’s delivering value to the client and it’s working reliably, then it’s good enough. Chasing perfection at the expense of pace is a luxury that FDEs, particularly in a startup, can’t afford.
This doesn’t mean you cut corners recklessly. It means you develop judgement about where the bar needs to be high and where good enough genuinely is good enough. That judgement, like most FDE skills, comes from exposure and repetition.
Still figuring it out
I’m not presenting this as a finished playbook. We’ve onboarded exactly one new FDE at Lleverage, and my own onboarding was only about nine months ago. The sample size is small. But the principles are becoming clearer with each iteration: ownership early, scope that grows based on calibration, proximity and availability, pattern recognition through exposure, and the confidence to stretch people when you’ve hired well.
I know a lot of FDEs read this newsletter, and I’m genuinely curious how your onboarding looked. Whether you were thrown into the deep end or eased in gradually. Whether your team had a structured process or figured it out as they went. And for those of you who lead or mentor FDEs, how you think about shaping someone into this role. I’d love to hear about it in the comments.