Did someone forward this email to you? Sign up here to get the next edition.
Friends,
So if you’re like me, you probably feel perennially behind when it comes to AI. This piece pretty much summed up how behind I feel. All. The. Damn. Time.
So last weekend I spent about 8 hours playing with Claude code for the first time ever.
It feels kind of cathartic to say that (and a bit embarrassing if I’m honest, because if modern social media is to be believed, everyone else is already an expert). But up until this point, I’d never moved past the empty Code screen.
I also feel like in that short period of time, I went through all the early stages of the Dunning-Kruger effect:
Frustrated with the setup and how unfriendly it felt to just get going.
Giddy with excitement that I could build stuff just by talking about it.
The valley of despair, as I realised that I’m the constraint, not the tool.
And landed somewhere along the slope of enlightenment, as I started to level up my product management skills (with the aid of AI of course) to be more effective at how I prompt the tool.
And I can’t lie. Having played with it a bit, two things emerged for me:
You can go from useless (know nothing) to somewhat competent in a relatively short period of time. There is no barrier besides persistence.
This is going to fundamentally change our function (I know, I know, everyone is saying this). But this post did a good job of capturing how and why.
So if you’re feeling behind on AI, just know that you’re not alone, but that there’s also nothing holding you back from getting started.
Speaking of which — lot’s of people talk about AI, but is it helpful if I talk about AI too?
Let me know what kinds of things keep you up at night when it comes to this. It is here for the long-term, so we may as well get comfortable with it.
Enjoy! ✌️
LATEST EDITIONS
In case you’re new here (or just missed it) here’s the past three editions of the FNDN Series:
IN PARTNERSHIP WITH PYN
Your career framework is gathering dust
Most competency frameworks take weeks to build. Then managers look at them and think: "What am I supposed to do with this?"
The team at Pyn has been talking to People leaders about what actually slows them down. One problem kept coming up: competency frameworks that managers don't know how to use.
So they built a free tool that fixes it.
Paste your framework, pick a level transition, and get a manager-ready coaching guide in under 30 seconds. No login, no pitch.
They're building practical AI tools for People teams and giving this one away (with more coming).
Know a startup Head of People looking for answers 🙋 why not forward this to them for some instant karma? ✨
This company’s compensation cycle takes five minutes
This edition is based on the latest episode of the FNDN Series podcast, with Rowan Savage.
Rowan Savage is a serial entrepreneur and tech founder with a strong belief that the way you win is by attracting the best talent, putting the right team together, retaining them over the long term, aligning them on the mission and then unleashing them to do their thing. Rowan is the COO at Scannable, and former CTO/Co-Founder of Runn, where he embedded many of these ideas at the core of Runn’s culture, including; transparent pay, asynchronous remote work, worldwide hiring, flexible working hours and let’s not forget; a 4 day work week.
If you're like me, the next few sentences will sum up how most compensation cycles run (trigger warning).
I have spent weeks running comp cycles.
Building the spreadsheet.
Pulling market data.
Coaching managers through calibration.
Aligning leadership on budget.
And that is only the front end.
Once decisions are made, you are fielding questions from employees who don’t understand how the number was reached, managing appeals from people who feel short-changed, and handling negotiations (often with their managers) as a result of it.
The process eats weeks on the way in and weeks on the way out. And for many companies, it happens twice per year!
When I spoke to Rowan Savage, he told me how he built an approach to compensation that resulted in comp cycles that take five minutes per person, per year.
The problem with most comp cycles is not execution. It's design.
He has no HR background. Never managed people before starting the company. And yet he built a pay system that, across six years, produced zero pay grievances, zero negotiations, and a comp cycle that is essentially an automated email.
His starting point was not a comp philosophy document or a benchmarking platform. It was a question:
"If I want to hire the best engineers I have ever worked with (people at Atlassian, Canva, GitHub), what needs to be true about pay for them to say yes to working with me, and then never think about it again?"
Most of us inherit a comp framework and try to optimise it. I have inherited frameworks with eight salary bands per level, discretionary manager adjustments, and three rounds of calibration, and my instinct was always to make the process run smoother rather than question whether we needed the process at all.
Rowan built one from scratch with a different goal: make pay so clear and predictable that it disappears as a topic of conversation entirely. A 2024 Aeqium survey of 60 companies found that HR teams spend an average of 6.5 weeks just preparing for a comp cycle, that’s before a single decision has been made or communicated.
He made three design choices to get there.
Design choice 1: One number. Published. No negotiation
Runn published exact salaries on their careers page. Not a band. Not a range. A single dollar figure per level. And next to it, a note: this is not a negotiation.
That one decision removed every pay conversation from the hiring process.
Candidates either looked at the number and applied, or they didn’t.
No back-and-forth, no anchoring games, no situation where one person negotiated harder and ended up $15k ahead of a colleague in the same role.
Internally, it killed the "why do they earn more than me?" question before it could start. Everyone at the same level could see they were paid the same. There was nothing to decode, nothing to speculate about, and nothing to appeal.
This is where most companies get tripped up with transparency. They publish a band, thinking that counts. But a band of $130k to $160k just moves the negotiation indoors. People still want to know where they sit within it and why.
A single number removes that entirely.
Transparency was also a recruitment tool. Rowan was hiring during the pandemic, competing for engineers who assumed a small startup could not afford them. Publishing the number upfront stopped top talent from self-selecting out before they even read the job ad.
Design choice 2: Same pay across every role at the same level
A senior engineer at Runn earned the same as a senior marketer. Same as a senior customer success person. Same as a senior people and culture lead. Regardless of job family, regardless of what the market rate for that function would be elsewhere.
It started almost by accident.
When Runn was ready to hire their first non-engineering role (a marketing hire), the question was simply: what do we pay them? Rowan's answer: just pay them the same as engineers. The logic was that they would attract exceptional marketing talent because the pay would be well above market for that function.
As they kept hiring across other functions, the same question kept coming up, and the same logic kept holding: if this person is important enough to hire instead of another engineer, and we see them as equally valuable, why would we pay them less?
What was meant to be a temporary solution lasted seven years. It removed the need to benchmark every role individually, eliminated cross-functional pay tension, and made admin straightforward. One pay table. Six levels. Done.
Think about what that does to a comp cycle. No benchmarking 40 roles across four data sources. No debates about whether your product managers should be priced against tech companies or consulting firms. One table, updated once, applied to everyone.
Rowan is upfront that he would not necessarily recommend it for every company. His reasoning is hard to argue with though: if you are telling your team that every function matters equally, your pay structure should reflect that. When it does not, people notice.
Could you do this at your company? Probably not in its purest form. But the principle is worth sitting with: how many of the distinctions in your pay structure actually reflect real differences in value, and how many are inherited from the way things were set up?
Design choice 3: Automatic raises, decoupled from performance
A lot of companies aspire to separate performance from pay. This one actually did it.
Every year, employees received two guaranteed pay rises. One pegged to market conditions (keeping salaries in the top 15% of employers). The other pegged to tenure (recognising the increasing value of institutional knowledge).
No manager input, no performance rating, no calibration meeting.
This is the decision that made the comp cycle take five minutes. Someone's anniversary comes up. An email goes out with their new number and a personalised note recognising their contribution. That is the process.
If the mechanism for delivering a pay rise is a pre-set formula and an automated email, you have freed up weeks of work that can go toward things that actually need human judgment, like; career development or redesigning your levels as the company scales.
The real power was what it did to retention.
Because employees could see their pay trajectory in advance, competitors could not just match their current salary. They had to match the guaranteed raise coming in six months, plus the next one after that, plus the promotion pathway that was already visible.
The bar for a compelling counter-offer got meaningfully higher.
This is the part that surprised me most. Most retention strategies focus on making people feel valued in the moment. This one gave people a reason to stay that was mathematical.
An employee considering a move could calculate the dollar cost of leaving, because their future earnings at Runn were already visible.
And because pay was separated from performance, Rowan could have honest conversations about someone's output without it feeling like a threat. People were more open about struggling. They were not gaming a review cycle for a better rating.
The accountability was still there (same conditions, same expectations, same standard for everyone) but it lived in a separate conversation from compensation.
Three results we're all chasing
Runn's engineering team recorded a +100 employee Net Promoter Score (on a scale of -100 to +100, the industry average for tech companies in New Zealand sits around zero).
100% retention in the engineering team over seven years. And across that period, pay did not come up as a source of friction once.
Not because they overpaid. Because they designed pay to be predictable, transparent, and boring. And boring, it turns out, is exactly what you want your comp system to be (well, easily understood anyway).
If your comp cycle takes weeks and still leaves people frustrated, the answer probably isn’t a better process. It might be fewer decisions. Rowan made three. They took his comp cycle from weeks to minutes, and his team never once asked to negotiate.
What does your comp cycle look like end to end? Reply and tell me. I'm genuinely curious how long it takes and where the pain sits for you.
This article covers the comp design side of my conversation with Rowan, but we also got into how he hired, how he ran performance without tying it to pay, and why his engineering team hit a +100 eNPS. The full episode is now live.
Where to find Rowan
LinkedIn: Follow Rowan here
Rowan built and runs: TechEvents NZ

If you enjoyed this post or know someone who may find it useful, please share it with them and encourage them to subscribe.
SMALL BITES
A roundup of the most interesting news from the week:
[Christine van Hoffen] Startup Guide to Global Mobility (deep guide)
That’s all from me this week.
Sure, this is technically the end of the newsletter, but we don’t have to end here! I’d love this to be a two-way chat, so let me know what you found helpful, any successes you’re seeing, or any questions you have about startup compensation.
Until next 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.





