Ben Curtis is co-founder of Honeybadger, the exception monitoring service web app developers have been quietly relying on for 14 years, now expanded into cron monitoring, uptime checks, and log based insights, all run by four full-time people.

We get into why closing the productivity gap didn't mean shipping more, the tiered approval system that lets small changes ship fast while sensitive code always gets a human's eyes, and the eight year old 30-hour workweek goal that's still the real scoreboard for whether any of this AI-driven speed is actually working.

Highlights

(00:00) AI made this team three to five times faster

(01:30) Fourteen years building Honeybadger

(02:54) How AI changed error tracking

(06:05) Staying simple while competitors add complexity

(10:03) How four people run Honeybadger

(11:08) Main Quest, Side Quest, and how work gets planned

(13:33) When AI triples your PRs and buries your team

(18:33) Why Honeybadger stays calm on purpose

(23:49) The 30-hour workweek that isn't always hit

(24:53) Who watches the watchmen at Honeybadger

(28:27) Using AI to kill alert noise

(34:33) Why a human still has to hit merge

Connect with Ben on LinkedIn
Check out his podcast FounderQuest
Connect with Chris on LinkedIn

Check out Axiomatic on LinkedIn

Benedikt Deicke is Technical Co-Founder of Userlist, an email marketing automation platform for SaaS companies built and run by an engineering team of three.

We get into why Userlist pre-sold the product before building a UI, how sales demos became customer interviews, why the team eventually stopped relying on a traditional feature roadmap, and how the way a company makes money shapes the software it builds, from sticking with Ember to deciding which background jobs actually need to be fast.

Highlights

(00:00) Why focus and slow, steady building matter
(01:21) Who Benedikt is and what Userlist does
(02:43) Userlist's stack: Rails, Ember, and Sidekiq under the hood
(03:32) How a 3-person engineering team covers so much ground
(05:41) Pre-selling before writing code and running demos as customer interviews
(09:59) Why "minimum viable" keeps getting harder as tools get easier
(12:35) Staying connected to customers as the company grows
(18:11) Bootstrapped roots, small funding rounds, and burnout going full-time
(21:42) Why customer feedback is the real prioritization tool
(23:53) How funding source shapes architecture and roadmap
(30:02) Monitoring and auto-scaling Sidekiq with AppSignal and Judoscale

Connect with Benedikt on LinkedIn
Connect with Benedikt on his website
Check out his podcast Slow and Steady
Connect with Chris on LinkedIn

Check out Axiomatic on LinkedIn

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

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

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

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

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

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

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.