Most developers think building the product is the hardest part. 

It isn’t.

It is finding customers, earning trust, and knowing what not to build.

Adam McCrea is the founder and developer of Judoscale, a third-party SaaS autoscaler that grew from an internal side project into a sustainable business supporting multiple hosting platforms. 

Adam makes the case that AI has made writing code easier without making it any easier to understand, maintain, or sell software: the real advantage still comes from years spent deep in one problem. We also get into how Judoscale grew through the Heroku Marketplace years before Adam knew much about marketing, and why bootstrappers need to protect their intellectual property from day one.

Highlights

(00:00) The platform-risk lesson that opens the show

(01:42) What Judoscale does

(02:14) Running Judoscale as a team of two and a half

(03:48) Adam's 20-year path from Rails developer to founder

(04:45) Building Judoscale's first version as a side project

(08:09) The IP ownership scare with TinySeed and his old employer

(11:43) Why launching in the Heroku Marketplace beat any marketing plan

(15:50) Spreading platform risk beyond Heroku

(19:50) Why "AI means everyone builds their own SaaS" is overblown

(25:45) How AI actually speeds up Judoscale's dev work

(31:00) Talking to anti-AI kids about the future of work

(35:12) Chris’ 3 takeaways, where to find Adam and Judoscale

Connect with Adam on LinkedIn
Connect with Chris on LinkedIn

Check out Axiomatic on LinkedIn

Most engineering teams think AI closes gaps. It just makes the existing ones move faster.

John Nunemaker co-founded Box Out Sports and Very Good Software (Fireside), and created the open source gems HTTParty and Flipper, tools quietly running inside a huge share of Ruby applications, including this show's own.

John put it plainly: "Everyone who has taste, those are the people I'm seeing explode with AI the most."

We get into why John gave up on focus years ago and gets more done because of it, the scaling crisis that accidentally created Flipper, and why knowing what to build has always mattered more than writing the code.

Highlights

(00:00) Why taste is the real AI advantage 
(01:15) John's companies and twenty years of HTTParty and Flipper
(04:13) Why John gave up on focus and still gets more done 
(09:10) How big Box Out Sports actually is 
(13:54) The two ways AI changed how Box Out builds 
(16:43) The scaling crisis at Words With Friends that created Flipper 
(19:27) Turning an open source project into a real feature flag business 
(22:17) Why feature flags change how you build, not just what you ship
(27:46) What's next for Flipper: multivariate flags and safer runtime control 
(30:48) Using AI to triage pull requests and chase CVEs on HTTParty 
(38:48) Why people with taste are the ones exploding with AI 
(40:33) Teaching his son to build multiplayer games with AI

Connect with John on LinkedIn
Connect with Chris on LinkedIn

Check out Axiomatic on LinkedIn

What's the one number that actually proves your engineering team is healthy? Most leaders want something as clean as a sales quota. Most engineering leaders know it isn't that simple.

Miles Sterrett, Director of Engineering at CareerPlug, an HR platform for franchise businesses built on a codebase pushing 14 years old, built his own answer after hearing that question one too many times.

He and Chris get into the two metrics that actually matter (throughput, and a weighted bug backlog he calls "bug pain score"), the one rule that keeps both from being gamed - measure the team, never the individual - and how AI has roughly doubled his team's output without dropping quality.

Highlights

(00:00) The question every engineering leader eventually gets asked

(01:31) Inside CareerPlug's franchise HR platform

(03:45) How a squad-based team is structured around product trios

(06:07) The CEO ambush that started Miles's search for "the number"

(07:50) A quick primer on DORA metrics

(09:21) Splitting engineering health into throughput and stability

(12:45) Building "bug pain score" to track quality without the noise

(15:50) What happens to bug counts when AI doubles your throughput

(24:00) The metric-gaming story hiding inside a "productivity" tool

(26:38) Why measuring individuals backfires, and what makes you valuable once you're senior

(36:31) The internal AI tool that turned a 4-hour ritual into 4 minutes

(39:41) Where to find Miles online

Connect with Miles on LinkedIn
Connect with Chris on LinkedIn

Check out Axiomatic on LinkedIn

When code is cheap, the hard part isn't building - it's deciding what's worth building, and trusting yourself to recover when something breaks.

Sam Smith leads product and engineering at Motion, where a team of three-and-a-half people ships compliance software for college athletics. AI didn't make his job easier; it moved the bottleneck. The constraint used to be how fast you could write code. Now you can build almost anything in a week, which makes restraint, not speed, the skill that separates good engineering orgs from chaotic ones.

In this conversation, Sam and Chris Vannoy get into what actually changes when building gets easy: why "just because you can doesn't mean you should" is now a discipline you have to practice on purpose, how to slow down in planning so AI can let you move fast in execution, and why the goal shifts from preventing every bug to finding and fixing it before a customer ever picks up the phone. They dig into the safety systems that make speed survivable - feature flags, comprehensive test suites as living specs, error logging, and the trust those systems rebuild between engineering and the rest of the business.

If you lead an engineering team, build product, or write code for a living, this one names the tension you're sitting in right now.

Highlights

(00:00) Intro
(01:15) Meet Sam Smith
(03:13) Building in a market that changes weekly
(04:13) The discipline of "no, but maybe later"
(07:51) Just because you can doesn't mean you should 
(09:02) Slowing down to speed up 
(11:59) Feature flags as the trapeze net 
(17:45) Test suites as a living spec 
(20:16) AI as an accelerant 
(22:06) Recovery over prevention 
(24:27) Earning back trust 
(27:30) Guessing right 
(32:13) Farther and faster with fewer people 
(37:03) Working in Claude Code 
(39:14) Wrap-up

Connect with Sam on LinkedIn
Connect with Chris on LinkedIn

Check out Axiomatic on LinkedIn

Your job was never to write software.

Matt Brown, CTO at Opendate, has spent his career moving between 50-person startups and orgs the size of Salesforce, and what he's learned is that engineering value has always lived somewhere other than the code itself. AI just made that impossible to ignore.

In this episode, Matt and Chris get into how influence and political capital work in inverse proportion to headcount, why constraints make engineers better rather than more limited, and what the job actually becomes once the machine is writing the code.

Highlights

(00:00) AI opinions change every two weeks
(01:06) Matt Brown's career: 50-person startup to Salesforce
(03:52) Why influence shrinks as org size grows
(09:28) The real cost of AI tooling
(12:09) How business model shapes engineering decisions
(15:31) Context vs. constraints: humans vs. AI
(17:32) Nice to have is a must-have
(26:33) Your job was never to write software
(28:56) The junior engineer pipeline problem
(33:39) Shifting quality left
(34:41) The future of engineering jobs isn't shrinking, it's changing

Connect with Matt Brown on LinkedIn
Connect with Chris on LinkedIn

Check out Axiomatic on LinkedIn

You've added the retros. The sprint gates. The review cycles. And somewhere along the way, your team stopped shipping and started managing the process you built to help them ship.

Patrick Byrne, VP of Engineering at Dribbble, has spent over a decade running a top-1,000 site on a majestic Rails monolith with a lean team of six. He's lived every one of those cycles of process expansion and contraction too.

Here's what he figured out:

• Process creep is invisible until it isn't. Build teams safe enough to say so before it's too late.
• Green builds can't catch what you didn't think to test. Ship small, monitor hard, recover fast.
• The code you're proudest of is probably what your team dreads touching. Boring code is a production virtue, not a compromise.

Highlights:
 
(00:00) Intro & Dribbble overview

(02:14) Engineering team size & the Rails monolith

(03:27) From sprints to continuous delivery

(06:39) Stripping back process without losing rigor

(10:14) QA, edge cases & the limits of testing

(11:18) Error tracking with Honeybadger

(13:22) Accepting bugs as inevitable

(14:30) Getting engineers into product decisions earlier

(17:05) From clever code to boring code

(22:55) Balancing coding and people management

(26:30) Hiring for ownership

(30:50) "Tell me when you took down production"

(33:25) Dribbble's pivot to marketplace

(35:55) Platform health & containerization

(40:27) Where to find Patrick

Connect with Patrick on LinkedIn
Connect with Chris on LinkedIn

Software engineering is getting weirder by the week. AI is reshaping how teams work, org structures are straining under the pressure, and the old playbooks don't quite fit anymore.

The Hallway Track is a podcast for engineering leaders who are in the middle of all of it - CTOs, VPs, and managers at real companies, figuring it out in real time.

Every other week, I’ll be sitting down with the people actually doing the work: engineering leaders navigating acquisitions, rebuilding broken processes, connecting their teams to the business, and experimenting their way forward, without copying what some FAANG company did five years ago.

No keynote wisdom or recycled frameworks. Just honest conversations about what's changing, what's breaking, and what's actually working today.

Because the best lessons in software engineering don't happen on a stage. They happen in the hallway.