Startup Within a Startup: A Conversation with Rory O'Brien
VP Customer Experience at HappyRobot
Rory O’Brien is VP of Customer Experience at HappyRobot, a voice AI company for logistics and supply chain. He oversees post-sales operations including FDEs, deployment strategists, and customer support. Before HappyRobot, he built Solutions Architect and implementation teams at Tonkean. His background isn’t traditional FDE, but he’s been doing the work under different titles for years. We talked about what actually makes FDE different, how to hire for it, and why he’s skeptical of the hype.
You lead post-sales at HappyRobot. What falls under your team, and how do FDEs fit in?
If you cut the company into thirds, it’s sales, post-sales, and product engineering. Everything in post-sales is pretty flat. We have three roles: FDEs, deployment strategists, and customer support. We’re going to try to keep just those three for as long as we can.
The FDEs and deployment strategists have a lot of overlap. The Venn diagram is pretty strong. FDEs are more on the hook for the technical win. Deployment strategists are more on the hook for the business win. But that doesn’t mean deployment strategists can’t go in and build and configure the application. And it doesn’t mean FDEs can’t have ROI and business impact discussions with the customer.
We do whatever it takes for that customer, regardless of whose job it technically is. Just do the job.
We err on the side of everyone needs to be a little bit more technical when they come aboard. But FDEs obviously have to be proper engineers to make the biggest impact for our platform.
You mentioned you’re skeptical of the FDE hype. What are you doing internally to get the best out of it without just following the trend?
We’re still early in our stage, and I think a lot of companies are too. It does make sense to go sit down with your customers and really understand them. Our platform is incredibly verticalized. Anyone can build on it for any use case. What we want is depth. Depth in supply chain, depth in brokerage, depth in banking, depth in utilities.
You need that expertise. But is it going to take 15 customers to build a product that solves 70% of their problems? And that last 30%, maybe you need to go on site for a day or two versus two or three weeks.
These are things we don’t know yet. Is it going to be the exact same team we fly in for defense contracts versus finance versus utilities? It’s not going to be cookie cutter.
It’s all going to depend on the vertical and how deep we go in that solution. To me, it’s like a startup within a startup. Our FDEs have a lot of autonomy to figure out what they want to work on and where they think they’ll have the most impact from a commercial and technical perspective.
One of the biggest challenges I have is figuring out when a solution is actually finished. Sometimes we deliver the scope we agreed on, but it doesn’t translate to the customer getting value. How do you think about that?
A lot of that is prep work before you even get into the solution.
How big is our champion? Do they see us as just a point solution? Just good with voice? If so, we have an uphill battle. We did a bad job selling them the vision. If they don’t see us as a stepping stone to get promoted or to be something bigger, that’s our fault.
That’s a business problem for the deployment strategist and account executive. The FDE should be picking up more use cases, more problems. “Hey, we can do this, this, and this.” Or “When we’re designing this, can we include this team? Can we include this system? Then we won’t need humans involved as much.”
Sometimes the value gap is just that they’re not thinking big enough. They’re letting the automation only go to a certain point when it could go further. But they’re scared or they don’t want to ask IT for access. Those are the hard questions you need to be asking.
How much of a challenge is change management? I often include champions, work through the solution with them, try to get operators early, but it doesn’t always work. Then once the solution gets in their hands, there’s pushback.
That’s a struggle we have too.
Some companies have different policies on change management. Some have proper change management organisations that come in, help write documentation, and slow down the implementation. But it can actually be better because they understand how the politics and bureaucracy of that organisation work. They’re taking that on.
We need to work on change management. But it’s broad to just say “change management” because the use cases are so different. Are we completely replacing humans? Are we doing some of their work and they need to work with HappyRobot? Are we just doing data passing where humans come in for edge cases?
It’s super dependent on the use case. Sometimes it’s seamless. Sometimes no one even knows we’re doing stuff behind the scenes. Sometimes it’s like, wow, they’re doing a lot of work, but now I need to change my behaviour as an operator because this agent is escalating stuff to me. How do I prioritise that? Where should I focus my time?
That’s what you’ve got to work on, especially when you’re going multi-country, multi-everything. A lot can go wrong.
Going on site helps. You actually see how people deal with this day to day. Are they multitasking on calls? Getting that tribal knowledge and experience really reinforces our solution. That’s where the FDE comes in. Literally sits over their shoulder and tests what the heck their life is like.
Rory’s team has grown to about 30 FDEs. Finding people who can do this work, and keeping them once you do, is a constant challenge.
When you’re hiring for an FDE role, what do you look for beyond strong engineering?
When I look at FDEs, I look at what I call their wings. They’re engineers by trade, but they have different orientations.
Some are more product-focused. They understand the platform end to end. They can see “this feels like a custom application we can sell” or “this feels like a new feature we need” or “we need to connect to a different system.”
Some are hardcore engineers. Stick them in a dark room and they’ll code all day and push the coolest technology ever.
Some are more business-oriented. They can talk at a business level about ROI and impact, but they can still be an engineer.
Usually not everyone has all three. If you find that, it’s a purple squirrel. But we need all of those types because different accounts need different things.
I want the product-minded folks more on site, especially for new verticals. They’re reinforcing that feedback loop within our product to make it stronger. They’re building that 70% so the next customer, the FDE can build off that and it’s only 30% custom.
Where would their path be if we hired them? If they don’t have a path, that’s probably a good indication they’re not a good fit.
They obviously need to be customer-facing. That’s number one. There are a lot of engineers out there, but if they don’t know how to run meetings, run demos, sell, you need to be able to sell even if you’re not directly selling. You’re selling the solution. You’re selling the process. You’re selling why they should be doing this solution.
You’ve got to be able to push back with customers. That only happens with experience and at-bats.
Does domain expertise matter, or do you just look for people eager to learn?
Both. We have a bunch of non-domain experts as FDEs, and they became experts. Some of them know brokerage better than people who’ve worked in the industry for 10 years.
They’re just good problem solvers. At the end of the day, everything is a technical problem, and every technical problem can be solved. It’s just how you approach it.
If you have an engineering and architectural mind, all you need to know is the verbiage, the nouns, the language they speak in brokerage, in freight carriers, in banking. With ChatGPT, just write up a huge report, start to understand it, and be able to talk at their level.
Most problems can be broken down into three components: data, people, and custom business policies and rules. Literally every problem. It’s just how you approach solving it.
How do you actually find these people? Is it easy?
No, it’s not easy. We have about 30 now, and most of my role is hiring. I have an interview right after this for an FDE.
You can find really good talent at agencies where they’ve only been there a year or two and realised agency life isn’t for them because it’s slow. But they picked up good business acumen and understand how enterprises work. They want to be moving fast, having autonomy, working on cutting-edge technology. Not in slow molasses.
Previous founders are super helpful too. They know what it’s like to be told no. They know how to sit and try to figure out a product from customers and turn that tribal knowledge into a product. They understand the grit it takes to make something new.
We’re still new, two years old. No one has figured out agents across the board. We’ve got to take some bruises. Ex-founders are super helpful for that.
But there’s no real good profile. You see a profile and think “that could be it.” Then you talk to them and you’re like, okay, there’s a hunger here. There’s a way they solve problems and approach the world that would fit how we intend to solve our customers’ problems.
How do you keep these people? If they have a founder background, they might just want to start their own thing again.
Those types of folks need to be creative. They need freedom to be creative to solve problems.
If you put them in a box and they’re going to be the brokerage expert for the next 10 years, they’re going to want to die. That’s not what they signed up for.
It’s more like, “Hey, I’ll help you here, but I think there’s a lot more opportunity there. This is really exciting to me. I’d love to explore that.”
Building that culture and infrastructure is what will let them stay. We don’t want to make decisions top-down, just saying here’s exactly what we’re doing and everyone goes and executes.
When you’re on site with one of our customers, DHL, they have five business units. You’re going to hear something like, “Our duty collection process is terrible.” They introduce you to a finance team. Then there’s a whole bunch of other finance use cases.
Maybe an FDE is like, I think there could be something with finance here. Great, go explore it. Go to the next finance department in another organisation and validate or invalidate that.
It’s literally a startup within a startup. If they validate it, they can sell their case: give me funding, give me more resources, I think there’s something here, let’s get a pilot.
That’s the freedom to build your own business within the platform of HappyRobot. That’s what we’re trying to instill. Giving them the freedom to have that founder mindset.
What would you say to companies that are pre-product-market-fit and thinking of starting an FDE team hoping it will help them find PMF?
I would ask them if they’re actually building a platform or not.
Everyone says they’re a platform. I had that same complaint at a previous company. We were an actual platform. You could build a business on our application. You could build an ecosystem on it. That by definition is a platform.
I don’t think a lot of these companies are actually platforms. Their upsell maybe exists, but their cross-sell, I don’t know if it exists in the same organisation.
If you’re going to be an FDE and single-threaded in a department or specific use case, I don’t think you’re going to get seven-figure contracts unless you’re solving something aggressively painful with that one point solution.
Rory O’Brien is VP of Customer Experience at HappyRobot.
HappyRobot is building the infrastructure for the enterprise AI workforce - turning calls, emails, scheduling, dispatch, and other frontline operations into autonomous, always-on workflows. Today, 4,100+ digital workers are deployed across 150 major enterprises and delivering impressive results: faster response times, lower costs, and higher customer satisfaction. Here's a 90 second trailer of their capabilities.