Hiring for Potential, Not Just Pedigree

In this episode of The Tech Trek, Brendan Grove, CTO and co-founder at PrizeOut, shares how his non-traditional background shaped his leadership style and hiring philosophy. Brendan dives into how being curious, humble, and pattern-aware has helped him scale teams and solve complex problems. He also unpacks how hiring for core traits like learning velocity and ownership can outperform chasing resumes full of surface-level skills. We also discuss tech debt, decision-making frameworks, and the role of engineering excellence in business success.

Whether you're a startup founder, engineering leader, or aspiring technologist, this episode is a reminder that greatness often lies beyond the obvious checklist.

🔑 Key Takeaways:

Hire for Curiosity and Ownership: Brendan values engineers who "give a shit" more than those who just ace technical interviews. Passion, curiosity, and ability to learn fast are force multipliers.

Non-Traditional Backgrounds Offer Valuable Perspective: Brendan's journey from mechanical engineering to CTO helped him build pattern recognition and a strong product-building instinct.

Balance Autonomy and Accountability: Great leaders don’t need to be the expert—they need to empower others while knowing when to step in.

Tech Debt Isn’t the Enemy—Stagnation Is: Tech debt becomes a problem only when it slows you down or introduces risk. Code should be easy to change without fear.

⏱️ Timestamped Highlights:

00:32 – What PrizeOut Does

01:13 – Brendan’s Path from Mechanical Engineering to Tech

02:59 – Humility and Curiosity as Tools for Problem Solving

04:41 – Delegating While Still Leading

06:46 – What Brendan Looks for When Hiring Engineers

09:24 – Hiring Junior vs. Senior: A Strategic Approach to Ramp-Up

11:56 – Giving Raw Talent a Chance: A Success Story

15:08 – Code Quality vs. Business Value: Finding the Right Balance

17:47 – Tech Debt: When It Matters and How to Approach It

💬 Quote:

"You should be able to make small changes without being scared. If you can't, it's not a testing problem—it's a code problem."