Geeks Who Lead Podcast

The episode contains some genuinely useful practitioner detail - the 80-person calibration room scaling problem, the day-one review skeleton approach, and counterfactual impact measurement for infra/security roles - but the 35 minutes are diluted with conversational filler, setup questions, and fairly standard HR framing. The insight-to-noise ratio is moderate.

“we would start that day one, the moment I delivered them their new performance review. I would write a skeleton of what their next performance review is going to look like”

“if we hadn't patched this security breach and we'd had it, it was a remote code exploit, if it'd been executed on, that would have cost us X amount of time, X amount of dollars”

The collaborative review-skeleton-on-day-one practice is a genuinely fresh operational idea not commonly discussed, and the counterfactual framing for infrastructure impact is useful. However, the overarching framework - impact, growth, partnership - is intuitive rather than contrarian, and the content leans on conventional calibration and 360 feedback concepts throughout.

“I would write a skeleton of what their next performance review is going to look like and say, here's the projects I think are going to come on your plate”

“we adjusted the definition of impact where it did not just have to be revenue or clicks, but that it could be documented successful progress towards an overarching yearly or multi yearly long term goal”

RC Johnson is a legitimate practitioner who spent seven years as a Senior Director of Engineering at Indeed, personally owning and redesigning the performance management process across a 4,000-person product-engineering org. He is not a career podcaster or pure thought-leader, though he sits below C-suite level and the episode lacks any external validation of outcomes.

“I had seven years at Indeed...the engineering team I think was around 400...that grew to over 2000 or 2500 engineering and over 4000 people across product, technology and engineering”

“I had been leading a small working group that focused on engineering performance management”

The episode delivers a reasonable set of concrete numbers - headcount growth from 400 to 2,500, rooms of 80, 10 - 30% bonus range, 2 - 3 week cycle time, managers spending up to 8 hours per person - and includes a vivid named anecdote (CSS color change driving several million dollars). However, there are no hard outcome metrics on whether the redesigned system improved calibration consistency, retention, or promotion accuracy.

“a fairly junior engineer was able to drive several million dollars more in revenue just by finding that a call to action was blue instead of orange”

“that impact score, for us was generated for what bonus they were going to get, whether it was going to be, you know, 10% all the way up through like 30%”

The host asks one substantive challenge - the infrastructure/Kubernetes engineer who can't show revenue impact - which generates the episode's most interesting response. But most questions are open-ended softballs ('what was the third flywheel?'), and the host never pushes on outcomes: did retention improve, did calibration variance actually decrease, what did engineers think of the system? The IC 'Christmas game' joke is emblematic of the mostly unchallengeable tone.

“What happens when somebody's doing a rewrite that you genuinely need...Should I, should I? I'm not going to work on that team. I'm only going to work on the team that I can do six character changes to make seven figure bonuses”

“I feel like that's sometimes the hard one. Whether it's the person who's just, you know, there's that one person on your team that doesn't seem super productive”