Friends,

There’s 4 sleeps until Startup People Summit, which means that by the time I wake up Friday, I’m hoping the persistent eye-twitch I’ve had for the past month will go away.

I’ve come to the realisation that to be someone who runs events you have to be mildly crazy. Crazy to do it. Or driven crazy after having done it.

In which case, maybe the eye-twitch is a permanent feature.

Wish me luck.

Ok, last week I asked you about where everyone is feeling on AI. Here’s the results:

When I compare my AI capability to others, I see myself as

🟩🟩🟩🟩🟩🟩 Ahead of most (16)
🟨🟨🟨🟨🟨⬜️ About the same (14)
🟩🟩🟩🟩🟩🟩 Behind most (16)
46 Votes

Six people added further commentary to their score, and confidence tracked almost entirely with hands-on use rather than knowledge:

I’ll give some thought to how this shows up in future FNDN Series topics as a means of supporting you, the reader.

In the meantime, there’s this weeks edition, which I really enjoyed writing! The traditional People team has never felt less stable than it does now, in both a scary but mainly exciting way. Case in point, People teams are now hiring engineers!

Enjoy this week’s edition ✌️

Matt

In case you’re new here (or just missed it) here’s the past three editions of the FNDN Series:

Clarinet has studied AI superusers: people who reclaim 30% of their time and energy with AI while still meeting or exceeding quality standards.

And one thing is clear, AI usage ≠ AI fluency.

In this hands-on session, Clarinet’s Head of AI Learning products shares how being “good at AI” is about measurable impact, and teaches the skills you need to become an AI superuser.

Interested in sponsoring the FNDN Series? Drop me a line!

Know a startup Head of People looking for answers 🙋 why not forward this to them for some instant karma? ✨

The People function is being stretched in ways we’d never have anticipated even five years ago. Today we’re exploring one such trend that has begun taking off in People teams. The rise of the People Engineer.

Back in 2023, the People Ops team I was leading did something I’d never seen done before in a company our size. We built an app.

It was a simple app, but an app, nonetheless.

Built in a no-code platform, it let anyone in the organisation select a country, a job family and a job level, and it showed the associated salary range.

All 650 people could use it at the same time if they wanted. It was secure, and no one could access anything they shouldn’t, or fiddle with the numbers in the back-end.

It was branded in company colours and fonts, and very functional, and it did an incredible job of supporting the company’s broader pay transparency ambitions, and driving a collective sense of trust within our culture.

It was a huge success and really well received by our people.

I didn’t see it then, but it was the earliest signal I can recall of what is now a full blown transition of the people function towards becoming product managers.

When it comes to the tech we use, People teams have always been constrained.

We watched countless demos and we bought tools, 99% of which forced us to adopt a process that the tool could facilitate. Forcing us to fit the tools, rather than have the tool fit us.

Now though, everything is changing.

In the past three months, I’ve increasingly seen companies hiring for a new kind of role in the People team. One that is rapidly shifting our place in the organisation, and our relationship with technology.

This role is the People Engineer. A professional dedicated to building technical solutions for the people team.

And with this role, comes the inevitable evolution of ourselves to enable it. It’s forcing us as People professionals to embrace the role of Product Managers.

The first question I found myself asking is, why now?

This kind of role has traditionally been reserved for the top end of town—the Google’s, or the Meta’s of the world. But now companies with significantly smaller workforces are hiring for this role. 

What gives?

But the more I thought about it, and the more I spoke with others, the more it made sense.

Firstly, AI has now lowered the barrier to entry for traditionally non-technical people, enabling anyone to build.

The technical name for this is Jevons Paradox. 

You see, People teams have always had heaps of stuff they wanted to build, they just didn’t have the technical expertise to build it themselves, and the company was never going to resource it.

AI has unlocked the ability for those of us with a decent sense of what we want, to start building solutions to problems that only technology could solve.

And while building is now easier, it still isn’t solely the domain of the average People professional. Anybody who has vibe coded something knows it’s easy to get to 90% of a product, with the final 10% being the piece that is most challenging. This is the part the People Engineer is here to solve.

Secondly, there is a ‘do more with less’ phenomenon sweeping the world right now.

Companies are expecting their people teams to cut costs and consolidate tooling, while they maintain or expand capability. The pressure is on to become more efficient.

A 2025 report found HR teams have on average 26 modules, with only 10 of them being used regularly.

The opportunity for disruption is ripe, and I spoke to a CPO recently who had done this very thing.

They replaced a performance management tool with a custom built app. It added features missing from their previous vendor, such as a dashboard, and Slack integration, and as a result saw adoption surge 13x, with more than 200 pieces of feedback in the first month of being launched.

This is the reality facing most People teams today.

But this sentiment isn’t reserved solely for them. Companies in general are moving towards leaner structures. Fewer people, doing more.

What this does is raise the inherent value of those people to an organisation.

If one person is now doing the work of two, three or four people as much as a year ago, the cost of low performance, or of attrition, suddenly goes up.

It’s this confluence driving the creation (and widening adoption) of the People Engineer as a new role in People teams.

You don’t have to look far to see that People teams everywhere are building more and more ambitious things. 

Just take a look at some of the discourse online where people are openly claiming to be building even an entire HRIS (seems crazy to me).

The need for a People Engineer makes sense, but what do they look like and how do I hire one?

I mentioned having seen companies hiring for this role, and I can cite four that either are or have hired for this kind of role lately; Lovable, Gitlab, Leapsome and Safety Culture (recently rebranded to Mitti).

They say imitation is the greatest form of flattery (and we love a template in the People profession), so here are the Job Ad’s each of them published to hire for it.

(Ps. if you’ve seen this sort of role advertised elsewhere, hit reply and let me know so I can add it to this resource)

In the lead up to writing this article, I had the good fortune of being on a call with Jessica Zwaan (VP of People Strategy and Operation at Leapsome), so it was a great chance to discuss this with her.

Jessica started by saying she hired someone out of a product-focused engineering role, closer to solutions engineering. 

This is someone who would be on calls with clients, working out what wasn't landing and shipping the fix straight back. So not your traditional engineering role.

I said that it sounded a lot like a new role I’ve been hearing about recently, called a Forward Deployed Engineer, and she said "that's what I've called it".

What was screened out was just as important as what she looked for.

Systems architecture backgrounds don't make the cut, and her reasoning was "we don't need these things to be that robust. They have like 100 users."

So a technical expert who is able to easily interact with the customer (i.e. you) but not so technical they could build the next Slack (because it probably doesn’t need to be that robust).

This role sits outside engineering, which makes you in the People team the escalation path for problems you can't assess yourself.

Jessica mentioned having had a deployment issue on AWS the morning we spoke. It got resolved because her engineer raised it early and explained it in terms she could take to the engineering team herself. This marks another skillset you need to be able to hire for in this role, the ability to speak in layman's terms so that non-technical people can get what’s going on.

She also warned against hiring someone chasing technical mentorship. "I don't want someone that's like, oh, I want you to help me grow as a technical engineer." You can't give them that, and you'll both end up frustrated.

Jessica gave me the best framing I've heard for what's actually changed, and it comes back to T-shaped teams.

The T used to be self-limiting. You could push someone on your team to get more technical, but the breadth of that T was capped by what a human could realistically learn.

AI removed the cap. "Someone can basically build an HRIS if you want them to," she said. "It will be shaky and bad and not good for security, not reliable and all those things. But they could."

So now she draws the line herself, on purpose.

"I don't want my team to be experts at site reliability and security. I want them to be experts at understanding a problem statement and wire framing something out. And then someone else needs to be good at all the other things."

That's the job now. Define the problem properly and sketch the solution, then know exactly where to stop.

Which is product management, whether or not anyone's updated your job title.

It's a big topic and I've barely scratched it here. The best read on it is Jessica's first book, Built for People, which I'd recommend whether or not you're heading this way.

So what do you think? I’ve found a handful of companies hiring for this role, do you think we’ll see more, or will the function head in a different direction.

Hit reply and let me know your thoughts.

If you enjoyed this post or know someone who may find it useful, please share it with them and encourage them to subscribe.

A roundup of the most interesting stuff from the week:

When you’re ready, here’s three ways I can help you:

1. Tools & resources
Resources and tools that give you what you need to build your own startup compensation practices.

2. Comp consulting
Building startup compensation practices that are clear, fair and competitive.

3. Startup People Summit
A 1-day annual event for People professionals in scaling companies. Creating the playbook for startup people practices. Grab recordings from past events, or subscribe to join the next summit.