The One Question I Ask Before Every Hire
If you can’t answer it, you probably don’t need that role yet.
👋 Hey, I’m Katie.
I’ve led recruiting teams everywhere from Fortune 500s to IPO to messy, high-growth startups. Along the way, one pattern has been consistent: the way we hire is broken.
That’s why I started Talent in Beta. Think of it as a sandbox where I share experiments, frameworks, and (sometimes spicy) takes on building teams differently.
What to expect here:
Posts on problem-based hiring (like this one)
How to enable your early teams to recruit successfully before you bring in an in-house recruiter — through better systems, tools, and self-serve hiring infrastructure
Real questions I get about headcount, org design, and those “needed this yesterday” roles
Experiments with AI + modern recruiting stacks (and how to actually use them without the hype)
Field notes — candid takes on what works (and doesn’t) when scaling in chaos.
I’ll post 2–3x a month. Short enough to read in one coffee, sharp enough to save you from a bad hire.
If you’re a founder, operator, or talent geek who cares about building better teams, subscribe and join me.
Stop Hiring for Resumes. Start Hiring for Problems.
The moment I get a request for a new role, I’m skeptical.
Here’s why: any startup in hyper-growth can fall into the trap of trusting new leaders to know exactly what kind of team they need to build. Sometimes those leaders bring in “their people” from previous companies. Sometimes they lean too hard on referrals. On paper, it looks safe — someone they know, someone who has performed before.
But here’s the problem:
A high performer at Company X doesn’t guarantee high performance at your company. Different stage. Different customer. Different problems.
These leaders are often still new to your product and your customers. How could they possibly know what the role actually requires?
Founders are taught to think in first principles. Otherwise, why are you even building? So why not bring that same rigor to talent?
Hiring is the single most expensive bet you’ll make. Get it wrong early, and it can drag your bottom line — or your culture — into a spiral you don’t recover from.
Traditional Thinking vs. Problem-Based Thinking
Let’s take a common scenario: hiring your first AE (Account Executive).
Traditional approach:
“We need someone who has already sold enterprise SaaS and has a Rolodex of logos they can bring in.”
Problem-based approach:
“Our founder-led sales are closing, but nothing is repeatable. Deals stall out after the first call because we don’t have a consistent process. We need someone who can build structure from scratch and teach us how to scale outbound.”
See the difference? You’ve gone from chasing a big-network seller → to finding an operator who can design process and turn messy founder hustle into a machine. Those are completely different profiles.
Same goes for product:
Traditional approach:
“Let’s hire a PM from FAANG.”
Problem-based approach:
“We keep missing customer needs in v1 launches. We need someone who can translate founder vision into shippable specs and run lightweight user research with our early customers.”
Again — totally different operator profiles.
The Framework
When a hiring manager asks me to open a req, my first question is simple:
“What problems will this person solve in their first 6–12 months?”
If they can’t answer that, I push back on why we’re even talking about headcount.
Once we know the problems → we define what success looks like → then work backwards:
Which skills/experiences are actually required to solve those problems?
How do we design an interview process to assess those skills?
Who on the team is best equipped to evaluate them?
Follow this path, and nine times out of ten, you won’t be hiring the “profile” you originally thought you needed.
Why This Matters
I’ve seen firsthand the impact a wrong hire can make. The ripple effects aren’t just financial — they shape your culture, your decision-making speed, and your customers’ trust.
Problem-based hiring isn’t about slowing down. It’s about solving the right problem the first time, instead of cleaning up the mess later.
So next time you think you need a new role, pause. Ask yourself:
👉 What problem is this person here to solve?
If you can’t answer it, you might not need that hire yet.
What’s Next
This is the first in a series on problem-based hiring. Coming up:
How I pressure-test “needed this yesterday” roles
Why defining problems first saves you from bad headcount calls
How one bad hire can quietly tank your bottom line
P.S. If you’ve ever been handed a “must-hire” role that made zero sense, you’ll probably enjoy the next few posts. Subscribe and save yourself some future cleanup.




Love this! Curious if this is part of your approach to a Role Alignment Meeting (Kick-off/intake)? Do you leverage a set of questions including this starter question to develop a hiring scorecard and reframe the JD to be more fit-for-purpose?