.png)
Why startup People Ops can't be "HR on the side"
Spend a decade in the Kitchener-Waterloo tech scene, home to companies like BlackBerry and Shopify, and you’ll see the People Ops function transform completely. What once meant policies, payroll, and making sure employees knew where the fire exits were has evolved into something far more central.
As this week’s guest on Let’s Table That, Holly Warwick, who leads People Operations at Ground News, explains, the role now sits “at the intersection of everything,” pulling data, sitting in boardroom discussions, and helping founders make decisions with real financial consequences.
We unpack the evolution of People Ops, the biggest mistakes companies make when scaling teams, and why culture and leadership can’t simply be copied from large corporations.
When to hire People Ops (and what profile actually works)
The short answer on timing: hire about six months before you think you need to. Most founders wait until something is actively on fire. Holly described walking into her first day at a startup only to be greeted with, "Oh, by the way, here’s a fire to put out."
The 20-30 employee mark is generally the right trigger point. By then, you have managers managing managers, and the informal systems that held together a ten-person team start breaking down fast. The complexity of people decisions scales faster than headcount does.
But timing is only half the problem. The profile you hire matters just as much. Two failure modes come up again and again. The first is handing HR responsibilities to an office manager who isn't trained for it. It seems like a practical solution; they're already there, they're organized, but it tends to quietly wreck culture. The second failure mode is the opposite mistake: hiring someone with a big-company pedigree and expecting them to transplant their Shopify or Google playbook into a 25-person team. It rarely works. Those systems were built for organizations with dedicated comp teams, layered HR infrastructure, and years of process maturity. Cramming them into an early-stage startup creates confusion and resentment, not structure.
What actually works is someone who understands what stage the company is at and genuinely wants to build alongside it.
Build for your stage: stop importing big-tech processes wholesale
There's a specific kind of chaos that happens when a 20-person startup tries to run like Google. You've seen it. Someone gets their hands on a framework built for thousands of engineers, and suddenly, a scrappy team is being mapped onto levelling structures that make no sense for where they actually are. In Holly’s experience, the team pulled Google's engineering leveling system and forced it onto a small dev team. The developers pushed back almost immediately. Of course they did. The process wasn't built for them, it was built for an org with hundreds of engineers and entire teams dedicated to compensation strategy alone.
The temptation is understandable. Big Tech has figured things out, right? Why not borrow their playbook? The problem is that most of those processes were designed to solve problems at scale, problems a 30-person team simply doesn't have yet.
The better approach is selective borrowing with a forward-looking filter. Take a piece of a process, ask whether it works now, then ask whether it will still hold up in a year without requiring a full rebuild. If it passes both tests, use it. If it doesn't, leave it. Building something lightweight and purposeful beats importing something heavyweight and impressive every time.
Manager quality is the retention and performance multiplier
People don't quit companies, they quit managers. It's a well-worn line, but it holds up, and nowhere is it more consequential than in a startup where the middle layer of management is often brand new, undertrained, and managing people for the first time.
The pattern plays out the same way at company after company. Someone is great at their job, so founders assume they'll be great at managing people who do that same job. That assumption is expensive. As Holly puts it, "I've seen A players stick around through the most chaotic things, the most insane workload of people I've ever met in my whole life. But the second they have a bad manager experience, they're out." Employees will tolerate being underpaid. They'll tolerate an unclear career path. They won't tolerate a bad manager for long.
The compounding problem is what happens when startups over-correct by creating too many management layers too fast. Founders see scale and think: more managers, more structure. But promoting your best individual contributors into management by default comes with a real cost. You lose the critical IC output they were generating, and you gain a reluctant manager who may not have wanted the role in the first place. Walking that back, taking away direct reports, and returning someone to an IC track is awkward and hard to execute cleanly.
The fix isn't complicated, but it does require intention. Value the IC track and the management track equally. Don't treat management as the only path to seniority or recognition. And make sure the people stepping into manager roles actually want to lead people.
Feedback and performance reviews that don't become theatre
Nobody has cracked performance reviews. That's the honest take here. After trying 360s, Lattice, and BambooHR across multiple startups, the clearest lesson is that small teams don't need heavyweight infrastructure; they need feedback that's real, timely, and actually useful to the person receiving it.
At Ground News, the review structure is deliberately lean. Upward and peer feedback follow a simple stop/start/continue format. The self-evaluation and manager's downward review cover three things: what the person accomplished in the last six months, what they need to improve, and, critically, how the manager will actively support that improvement.
The goal is clear: highlight your all-stars and make sure they're well taken care of, then identify underperformers early enough to actually do something about it. Some people underperform but are strong culture fits; there's time and space to bring them up to speed. Others aren't the right match, and the sooner you know that, the better for everyone.
One firm rule: don't make stuff up to fill space. Managers who don't have robust enough feedback for a given period are told not to force it. Vague, invented feedback is worse than silence; it erodes trust and signals that the whole process is just a box-ticking exercise. And once people feel that, you've lost them.
Trust, boundaries, and culture: practical tactics that scale down
One of the hardest lessons in People Ops is learning not to be everyone's best friend. Early in her career, Holly tried taking a more informal approach to being approachable at work. But when a team member shared a concern expecting it to stay private, it created a difficult situation when Holly needed to follow up on it in her role. Without clear boundaries, the moment strained the trust between them.
Her fix was simple: tell people upfront exactly why they'd call her.
She outlined three reasons:
1) You want to vent, talk for 20 minutes, feel better, done.
2) You want direction on how to solve a problem yourself.
3) Or you want her to solve it for you.
Being explicit about which mode you're in removes the ambiguity that erodes trust over time.
The culture side is just as deliberate, and just as human-scaled. At a previous company, she and the founder dressed as Mr. and Mrs. Claus and drove to every employee's house with personalized gifts. She kept a running list of everyone's favorite treats, and when a PM had a rough day, she Uber Eats'd her a specific flavor of Miss Vickie's chips. The entire thing costed a total of elevan dollars, and the impact was disproportionately positive. These aren't scalable programs. They're not meant to be, and that's the point.
The throughline across all of it is the same: build people systems that match your company's actual reality, not a blueprint borrowed from a company ten times your size. Lightweight, intentional, and human beats heavyweight and borrowed every time.
