Holding the Magnets Together: A Conversation with Vlad Shulman (Part 2)
Former Head of Forward Deployed Engineering at Baseten
This is Part 2 of my conversation with Vlad Shulman, former Head of FDE at Baseten. In Part 1, we talked about what FDE actually means today and why the 70% product contribution number is really a self-accountability heuristic. Here, we get into the operational side: his unusual path from founding two companies to leading an FDE team, the daily tension between engineering and commercial priorities, and what he learned about hiring engineers for a role that most engineers don't fully understand.
You built Retain.ai over five years, then founded Stork Network, and then went to lead FDE at Baseten. Most people in FDE go the other direction, they start as FDEs and then start companies. What pulled you toward leading an FDE team after running your own companies twice?
I think there’s a very big overlap in skills between FDE and founders. The simplest way to put it is building things constrained by the commercial environment. FDEs learn that because they show up and there’s a clear outcome they’re building towards. They’re on sales calls, getting exposed to commercial considerations. A typical engineer doesn’t get exposed to that. Even a typical product manager doesn’t get exposed to that.
When the Baseten opportunity came along, the framework I used was impact. I saw a solid adoption graph going up and to the right. And I saw a place where I was uniquely positioned to impact thousands of customers because the shape of the team made sense to me based on my experience as a founder.
There’s also something very attractive about already having product-market fit. A lot of founders I know alternate. First they do something that’s pre-product-market fit, then they pick an idea where they have a very clear fit and it’s more about commercialising. I think this was an extreme version of that. You’re coming in, there’s already a product, there’s product-market fit. It’s about reiterating on that last step repeatedly and refining the product, while focusing on process, team, etc.
But you actually said no at first.
I did. I did not believe, having seen similar roles at previous companies before they were called FDE, that it could create truly durable technical artifacts. I always had this hunch that calling it something technical is just a euphemism to attract talent. And then in practice, it’s such a commercially driven thing that any sense of autonomy gets overshadowed by commercial needs.
I actually called a friend who used to run a similar team at a previous company. I asked him, do you think there’s a way to make this team truly technically empowered? He was skeptical, but out of that conversation came a list of prerequisites that I took to the Baseten founders for what I think would be required for success. Fortunately they were 100% on board.
You’ve now had six months of distance from Baseten and you’re advising multiple startups. What would you do differently if you were building an FDE function from scratch?
I don’t know that there were massive things I would do differently at Baseten if I were building that team again. There are small things.
The challenge for me personally was often forming enough belief in something so that I do it with absolute conviction. One example: in the first four to five months, hiring was brutal. We had a philosophical principle that any person who can join the FDE team should be able to join any other engineering team at the company. The technical bar should be the same. It should really be a matter of interest, that they want to work on this type of problem.
Until we hired the first two people that met that bar, there were many times I was wondering if we’d ever find them. If there was something we needed to change, if we needed to be less strict. If I were to go back, I would just tell myself it’s going to be okay. There’s a virtuous cycle that kicks in. It’s standard pipeline stuff where eventually enough things click.
But if I was starting an FDE team at a different type of company, the non-negotiable is you always want an FDE who is motivated by accelerating the customer to impact. You screen for that. Beyond that, you pick the attributes you want to augment with. Do you want them to be very technical? Do you want them to have past experience working with customers? Do you want them to have sold into an enterprise before? Do you want them to be really organised because they’ll be doing many of these at the same time?
That’s an important decision because hiring FDEs is hard. And you can’t optimise for everything at once.
When it comes to hiring, I’ve heard two schools of thought from FDE leaders. One group hires people who are seven out of ten across many things: product, engineering, customer communication, leadership. The other group hires people who are exceptional at one thing and then moulds them in other areas. Which was your approach?
It goes back to the conversation from the beginning: what kind of FDEs are you hiring for? If they’re enterprise FDEs and they need to be great at navigating an org or knowing when to take a client out to dinner, I think it’s okay to screen for that during the interview process.
For us, the main thing was that our customers were L6 engineers or equivalent. Very senior staff engineers. Our FDEs had to be able to go in front of top-tier engineers and prove they were at least as smart when it came to inference. That was the bar.
Sure, I also wanted them to be good communicators. I wanted them to keep an engagement going. I wanted them to have enough product intuition to ask, wait, what are we actually solving? But I felt I could teach those things to a sufficient degree. People could learn during onboarding or by osmosis, as long as they wanted to learn, as long as they were excited by what the role presented.
There were engineers from other teams helping out in FDE, and the number one reason they weren’t long-term FDEs is they were doing it somewhat reluctantly. Yes, they wanted the company to succeed, they were willing to get on a call. But they were not intrinsically motivated to get better at taking an ambiguous customer problem and solving it within messy constraints.
You ended up not requiring any ML or AI background for FDE hires. That’s counterintuitive for an AI inference company.
We debated that. Our version was we decided we did not care if you had any ML background or AI knowledge. A year and a half ago, that was a real discussion. Today it’s probably a red flag if someone has literally no AI knowledge. But back then, we found that engineers who operate comfortably across different stacks can pick up pertinent applied ML fundamentals on the job.
The harder part was interview design. We kept going back and forth on trying to come up with something more hands-on for FDE candidates. We’d say, well, maybe we go build an agent that does a thing. Every time we tried this, it was a disaster. The two things that are important in interviews are that you’re getting signal correlated with the outcome, and that you’re doing it consistently between candidates.
We would spend hours coming up with what we thought was the best test. And then we didn’t know what to do with the results. Did we present the problem poorly? Was it too open-ended? Did the candidate not know about some weird library that we knew about? Someone would spend half the time trying to install Python on Windows.
We tried to intellectually make up for it, but it was a mess. Keeping it simple would have saved us hundreds of hours and potentially kept candidates in the pipeline that we psyched ourselves out about.
Even with the right hires in place, Vlad found that the real challenge of running FDE isn't the work itself. It's the constant pull between the engineering side of the house and the commercial side.
In your article, you were clear that FDE should sit in engineering, not in GTM. But when deals are on the line and sales needs FDE resources, how did you actually navigate that tension day to day?
I did not want to take an FDE leadership role because I thought this tension was very hard to resolve and typically resolved only in one direction, which is in favour of the commercial side of the business.
So what do you do? I think you have to structure everything you can control in favour of engineering. At Baseten, we had FDE report into engineering. Does that solve everything? Of course not. Reporting structure is a made-up concept. But now your manager is the CTO. And the CTO thinks about long-term stuff.
The way it fails is when the CTO says, I have no idea what you want from me, leave me alone. That probably happens a lot. So reporting to engineering alone is not a solution.
For us, it was about adopting as many engineering artifacts as possible. The rituals associated with engineering. FDEs sit in the same meetings. The engineering weekly planning meeting, the FDEs are there. All these small things together add up. Optically, you feel like an engineer. You hear what people are building. They hear your problems.
Because commercially, the gravity is always going to be revenue. If you’re lucky and you’re successful, you have revenue to get. And it will find the FDE team. So you have to create a counterbalance.
My job was holding two repelling magnets together the whole time. Making sure that if one magnet moved here, you move the other magnet to make up for it. Sometimes you skew. End of quarter, January 20th, you rush to the finish line, go heads down and ship without asking too many questions.
But then as an FDE leader, you go to the CTO, you go to the CEO, and you say: what I want in return is two weeks where I can push back on commercial needs to give the team time to incorporate feedback. I think that’s the job of leadership in this world.
Was there a tactical trick that helped manage this?
Something I’m curious to try in more places. You can try to force the commercial side to be self-accountable. One of the first tricks you learn as a product manager is you don’t ask customers if a feature is important. Instead, you force them to prioritise it. Force them to say they want this more than this other thing. Because now they can’t say everything is equally important.
You can do the same thing with sales. You say, sort these deals by priority. Don’t tell me everything is important. Sales will say, if only we had hired more FDEs. But that’s not the question we’re asking.
A great salesperson is often highly aligned with the organisation’s long term outcome. If you force them to articulate what they want in terms of priority, they’ll probably give you the right priority. Not guaranteed, but it helps a lot.
As the team scaled, how did you decide what individual FDEs should specialise in?
One idea we had that turned out to be good was letting the team specialise by vertical. ASR, video, language. The reason it wasn’t obvious is you can’t guarantee customer workloads will be distributed along how you broke up your team. But the upside was massive. It lets the engineers specialise and gives them infinite runway to get better at something. They can figure out whatever techniques exist, whatever infrastructure plus model performance plus UX things they need to do.
If we’d specialised them by enterprise versus SMB instead, I feel like you end up specialising in how to say the right words so the CIO is excited. Not how to get the best product out there.
Vlad Shulman is the former Head of Forward Deployed Engineering at Baseten.