Hiring Product & Engineering Leaders in the AI Era (without losing your mind) — with Sean Lucq, SPMB.

Hiring senior product and engineering leaders has always been hard. But lately it's gotten… loud. Every job description is "AI-first," every candidate has a strong take on working for private equity vs. venture capital, and half the internet now claims "10 years of LLM experience," which is impressive considering LLMs have been a thing for roughly five minutes. Recently, I sat down with Sean Lucq (Partner at SPMB Executive Search) to talk about what's actually changing in technical hiring, what doesn't, and how to run searches that don't turn into long, expensive group therapy sessions.

One of the first things we talked about was why hiring technical leaders is uniquely weird. If you need a heart surgeon, the world has a clean filter: residency, board certification, the whole deal. If you need a VP of Engineering, you're often dealing with wildly different backgrounds, a bunch of role titles that mean different things at other companies, and an interview process that frequently collapses under its own good intentions.

Sean's take is simple: companies often hire the best interviewer rather than the best operator. (This is one of the reasons that ParkerGale adopted the Lou Adler process over a decade ago.) They run a disorganized process, ask the same questions five times with five different people, and then someone walks out and says, "I didn't really feel it," which is polite language for "we didn't actually evaluate anything." This shows up in every function, but it's excruciating in engineering and product roles because the signal can be subtle and the people you're interviewing aren't always trained performers. Some are charismatic. Some are… Office Space Milton. Both can be excellent leaders, and if your process is built around charisma, you'll miss the quiet killers.

Here at ParkerGale, we've seen over and over: searches get easier when you work with the same search partner over time. There's a calibration period at the start—understanding what "great" looks like in your environment, what your company actually rewards, and what kinds of leaders thrive in your portfolio. After that, the process gets sharper. Not because you stop being picky, but because you stop wasting time on misfits you can spot faster.

Sean describes search as hunting, not resume-shuffling. That resonates with us, because the value isn't in dumping a pile of candidates on a table. It's about going into the market with a point of view, pressure-testing assumptions, and sometimes telling the client (lovingly) that they're wrong. (He skips the loving part with me because I am a well-known crabapple). This is the part that's hard for some people: you're paying for expertise, not agreement. If your search partner never pushes back, congratulations, you hired a vendor, not a partner. And I do not toss around the word “partner” lightly, as most of you know.

The topic of the moment is, of course, AI. Sean's blunt assessment is that AI is front and center in almost every conversation right now. But the important nuance is that "AI-first" doesn't magically create unicorn candidates who can do two separate jobs at once.

The market is split into two roles. One is the traditional Head of Engineering / VP of Engineering. You're not hiring an "AI expert" here. You're hiring a leader who can run engineering and who's using AI in practical ways today—speeding up workflows, automating pieces of QA and code review, experimenting with agent-like tools internally, and partnering with product to ship customer-facing AI features where it actually makes sense. What is implied here, but often overlooked, is that AI does not fix lousy development processes.  (For a more extended discussion on development processes and their correlation to business outcomes, read Forsgren, Humble, and Kim’s Accelerate.)

The second role is different: Head of AI / VP of AI / Analytics & ML Engineering. This person is building the AI layer and the infrastructure—platforms, frameworks, and systems— that enable the broader engineering org to develop and deploy AI-enabled capabilities. If you cram this into the VP Engineering job description, you usually end up diluting both. Either you get someone who can run engineering but can't build the AI discipline, or someone who can make AI infrastructure but isn't set up to run the broader engineering machine. Either way, the result is disappointing and expensive. This might not be true in the future as AI becomes more mature and is fully embedded in the engineering process, but I'd agree it is true today.

On the humor front, we both see too many job descriptions requiring "10 years of LLM experience." It's a good tell, honestly: if someone is asking for impossible credentials, they probably don't understand what they're hiring for. Sean makes another valid point here—AI didn't start with LLMs. Some people have been doing applied machine learning for 15–20 years; the label changed, the fundamentals didn't.

On the talent market, Sean finds that candidates are more open to conversations than you might think. Fewer people feel "safe" even at large companies; venture has its own weirdness (liquidity, valuations, FOMO term sheets), and private equity looks more attractive to many leaders these days because it often comes with a more precise timeline and a more disciplined operating model. It's not usually a moonshot, but it's also less likely to be five years of 70-hour weeks ending in a shrug.

That said, we both agree that "fit" across big tech, venture, and PE is real. People who have only worked at massive companies can struggle in smaller environments where you don't have a global Gartner subscription and a team of eight product managers per feature. On the other hand, people who have only worked in venture can be incredibly effective in PE-backed companies because they're scrappy, hands-on, and used to operating without a safety net. The best candidates tend to have range: they've seen scale and been in the mud.

One clear distinction we both agree on is how to think about product leaders versus engineering leaders. For engineering leadership, domain expertise is often overrated as long as the relevant patterns match—scaling, modernization, acquisitions/integrations, operating in the proper technical context. For product leadership, domain expertise matters more because the job is deeply tied to the problem space, roadmap, and customer understanding. Product leaders are motivated by the "why" in different ways, and in technical products, especially, having sufficient technical fluency to be credible with engineering matters a lot.

Sean has some advice for you if you still want to work in engineering leadership at PE-backed portfolio companies: Learn to talk about business impact. Not "we improved velocity," but what changed, why it mattered, and what the measurable outcome was—revenue lift, churn reduction, support ticket deflection, cost savings, cycle time improvements. A surprising number of very senior candidates can't do this cleanly, and in a PE-backed environment, it's critical. Boards can evaluate finance. They struggle to assess engineering progress. Leaders who can translate the work into business outcomes change that dynamic.

The bottom line: AI is changing the tooling and the vocabulary, but hiring still comes down to fundamentals—structured evaluation, clear expectations, honest partnership, and leaders who can connect decisions to outcomes. The buzzwords change. The job stays the job.

If you want to connect with Sean, you can reach him at  sean@spmb.com.

Listen to the full episode on Apple Podcasts, YouTube and Spotify