Friends,

If you’re reading this then it means I am dead (from overdosing on chocolate 🐰 🥚 🍫).

Or that’s what I plan to be doing by the time this comes out, over a luxurious four-day Easter weekend.

Not sure about you, but I have a love hate relationship with long weekends. I love them because who doesn’t love more down time in a world where hustle culture is still rampant (and I’m super guilty of it).

But also the condensed work week gets me every time and I end up undoing any rest and recovery I managed to get from the extra time off 🙃

Is this just a me thing? Possibly.

But I’ll see you next week, hopefully not having gone through that cycle.

Enjoy! ✌️

Matt

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

Workflows run on schedules and follow rules. They can't follow up when a manager goes quiet, or act the moment something changes in your HRIS.

The next generation pulls signals from across your systems to build a real picture of each employee, then acts on what it finds. Scheduling the check-in when someone falls behind.

Consolidating five nudges into one message that actually gets read.

Pyn is building that system, and they want to hear from the People leaders who see this coming.

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

This edition is based on the latest episode of the FNDN Series podcast, with Arif Ender.

Arif Ender is the Director of Compensation for EMEA and Latin America at Palo Alto Networks, where he leads compensation strategy and program implementation across more than 65 countries. Before that, he spent years at Meta scaling compensation across the EMEA region as the company grew from around 1,500 to over 11,000 employees. Arif is also a faculty member at WorldatWork, teaching certification programs in Total Rewards Management.

Five years ago, if you wanted custom tooling for your comp processes, you had two options. Buy enterprise software and bend your workflows to fit it. Or have a dedicated engineering team build something from scratch. Option one is expensive and rigid. Option two was only available to companies like Meta and Google, who could afford to throw engineers at HR problems.

That's changed.

AI coding tools have made it possible for someone with no engineering background to build working, fit-for-purpose HR tools in days. You don't need to learn to code. You don't need to understand programming languages. You describe what you want in plain English, and the tool builds it. If the output isn't right, you tell it what to change, again in plain English, and it iterates.

And the person best placed to do this is you, because you already understand the process, the edge cases, and the logic that no vendor or engineer is going to know.

I spoke to Arif Ender about exactly this on the latest episode of the podcast.

Arif is Head of Total Rewards for EMEA and Latin America at Palo Alto Networks, and before that he spent years at Meta scaling comp from about 1,500 to over 11,000 employees. At Meta, they had an internal people engineering team that built custom HR tools from scratch.

At one point, Arif's three-person EMEA comp team was handling 800 non-standard offer approvals a year (up from around 200 the year before). The tooling made that possible. Comp logic was baked into the approval workflow so the right constraints existed without a rewards person in every decision chain.

That was a competitive advantage reserved for the biggest companies in the world. The technical barrier to building those same tools has now effectively disappeared.

Arif has no formal engineering background. He studied coding at university years ago, in languages nobody uses anymore. Despite this, in a single weekend, he built a personal finance tracker using AI coding tools: automated stock price fetching, AI-categorised transactions, the lot.

The important detail here is how he did it. He didn't learn to code. He didn't take a course. He watched 10 to 15 YouTube videos on how modern software works (just enough to understand the shape of what he was building), then searched for best practices on how to prompt Claude Code effectively. 

That's it. 

From there, he described what he wanted the tool to do, and the AI wrote the code for him.

When the tool used technical language he didn't recognise, he'd search it, learn what it meant, and carry on. It was a conversation with the tool, not a programming exercise. A few days in, he had something working.

His immediate reaction was that the same opportunity exists for people processes.

Think about the work that eats your week: pulling survey data into spreadsheets, manually benchmarking roles, formatting offers, chasing approvals over Slack. 

None of that requires your expertise, but all of it requires your time. You could build a market pricing tool that parses salary survey CSVs, auto-maps roles, and gives you structured output. Hand it to hiring managers and talent acquisition, and you're no longer the gatekeeper for every data request. The team that used to wait three days for a benchmark can now pull it themselves, within the parameters you've set.

That's the same principle that made Arif's team at Meta so effective. 

They didn't scale by hiring more comp analysts. They scaled by building tools that let the broader business move fast within guardrails the comp team had defined. The difference is that Meta needed a dedicated engineering team to build those tools. You can now do it yourself, in a weekend, by describing your process to an AI.

The code was always the easy part. Knowing what to build is where the real difficulty sits.

Understanding why an offer approval needs a certain escalation path. Knowing which edge cases will blow up your pay equity. Being able to look at a process and say "this step exists because of a regulatory requirement in Germany, and this step exists because our CEO once approved something that cost us six figures."

That knowledge lives in your head. An engineer can write software, but they don't have that context. They'll build what you describe, but they won't know what you forgot to mention until it breaks in production.

A vendor can sell you a platform, but (as Arif put it bluntly) if your tool is forcing you to shape your process around its design, that's a problem. You end up with extra steps that exist because the system demands them. Your reporting looks the way the vendor decided it should, not the way your leadership team needs it.

AI coding tools change that equation.

You describe the process.
You describe the logic.
You describe the exceptions.

The AI turns it into a working tool.

And because you're the one directing it, the tool is shaped around how your team actually works, not around how a vendor imagined you might work.

At Meta, the combination of comp expertise and purpose-built tooling was what let a three-person team operate at the scale of a much larger function. That same combination (your knowledge, plus an AI coding tool) is now available to anyone with a laptop and a $20 monthly subscription. The only thing that's changed is who writes the code. The expertise that makes the tool valuable was always yours.

Pick one process that frustrates you. Something manual and repetitive. Don't try to rebuild your entire HR tech stack. Pick one thing.

If I were starting from zero, I'd give myself three weeks:

Week 1: Get familiar.

Watch 4-5 YouTube videos on Claude Code (or Cursor, if you prefer). Search "Claude Code for beginners" and "how to prompt AI coding tools effectively." You are not learning to code. You are learning how to describe what you want clearly enough for the tool to build it. Think of it like briefing a very fast, very literal contractor. The more specific you are about what you need, the better the result.

Week 2: Build your first prototype.

Pick something contained. A market pricing calculator that reads your salary survey CSV and spits out mapped benchmarks. An offer approval checklist that flags when a proposed package sits outside your ranges. A dashboard that formats your comp data the way your CFO actually wants to see it. Describe the process to the tool the way you'd explain it to a new hire. Be specific about inputs, logic, and outputs.

Week 3: Test and improve.

Use it. Find what breaks. Tell the tool what to fix (again, in plain English). This is where your domain expertise earns its keep, because you'll spot the edge cases that a generic tool would miss entirely. A vendor's software doesn't know that your APAC ranges need a different escalation threshold than your US ranges. You do. And now you can build that into the tool yourself.

Arif's advice: "Ship now, improve later. But think ahead."

Your people expertise is your competitive advantage. It always has been. The difference now is that you don't need a people engineering team, a six-figure software budget, or a computer science degree to turn that expertise into a tool that actually works.

The capability that only Meta could afford five years ago now costs $20 a month and a few days of curiosity.

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 news 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
I run FNDN, a global comp consultancy that builds compensation practices that are clear, fair and competitive for startups.

3. Startup People Summit
I run the Startup People Summit, a one day annual event focused on creating the playbook for startup People practices. Grab recordings from past events, or subscribe to the newsletter to join the next event.