Runtime Regret Podcast

About Runtime Regret Podcast

We explore what happens when technology decisions meet reality. We focus on incentives, silos, leadership behavior, and organizational politics—why plans succeed in meetings but fail at scale, and why accountability disappears at runtime. runtimeregret.substack.com (https://runtimeregret.substack.com?utm_medium=podcast)

Publisher

Runtime Regret

Category

business · technology

Language

en

Explicit

No

First episode

25 Jan 2026

Latest episode

5 Nov 2026

Latest episodes

17 episodes in the feed.

1. 

   5 Nov 2026

   Are Tech Conferences Worth It? When to Go, When to Skip, and How to Pick Your Top 3

   You’re standing in an expo hall. Badge around your neck, a tote bag full of swag, a dozen booths competing for your attention. Somewhere between the third vendor demo and the second free coffee, a question creeps in: am I actually learning anything here? That’s the question I brought to Joe Kennedy on this episode of Runtime Regret, and his answer is refreshingly blunt. The bad conference that turned him into a speaker Around 1999, Joe was designing the internet infrastructure for State Street Global Advisors. His company spent a couple thousand dollars to send him to a big industry conference, and he came back with nothing. The sessions didn’t reflect the real problems engineers were solving, and he scored the speakers accordingly: ones and twos on the feedback cards. Then he wrote the organizers a letter. Their reply? If you’ve got so much to say, come speak at our next one. That’s how someone who was once afraid of public speaking ended up on stage. Most tech conferences are built for vendors, not for you Joe’s core point: many conferences exist so vendors can get potential buyers in a room. The vendor spends big so you’ll show up and they can pitch you. Nothing wrong with that, but it isn’t the same as learning. And let’s be honest, sometimes we go because we need two or three days away from the desk. That’s human. Just don’t confuse a break with professional development. When a tech conference is worth it Joe sees two situations where a conference genuinely pays off. * You get hands-on learning from the people who built the product. Joe once went to a conference specifically because the original engineers behind Chaos Monkey, the Netflix-born tool that deliberately breaks things in live systems, were teaching classes. He was bringing that approach into financial services to build fault-tolerant systems, and those sessions made him better at it. * You’re stuck inside a big organization and need to see the market. If you work at a large bank or healthcare company, it’s easy to lose track of what’s emerging. A well-chosen event shows you which technologies are coming of age and what your peers are actually using. There’s also a separate, perfectly valid reason to go: intentional networking. You’re there to sell, partner, or grow your company. Joe’s take is that this makes sense, but call it what it is. That’s business development, not learning. Joe’s rule: pick your top three Joe gets invited to 20 or 30 conferences a year, and his advice is simple: be choosy. A lot of general-session speakers don’t carry operational responsibility, so their talks rarely help the people doing the actual work. Don’t spend your company’s budget on 20 events. Pick your top three, make sure they’ll teach you something specific, and leave the rest behind. A quick checklist before you register Based on Joe’s advice, ask yourself: * Is there a hands-on session or training with the product team? * Is at least one speaker someone who has actually built or run the thing? * Do you have a specific question you need answered? * If you’re going to network, do you know exactly who you want to meet? * Would you still go if there were no swag and no trip? If you can’t say yes to at least one, skip it and save the budget. Watch the full episode The full conversation with Joe is in the video above. You can also catch Runtime Regret on Spotify and YouTube. Got a question for Joe? Submit it at runtimeregret.com (https://runtimeregret.com). I sort through every one and bring the best to the show. If this just saved you a wasted conference budget, subscribe so the next episode lands in your inbox. This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit runtimeregret.substack.com (https://runtimeregret.substack.com?utm_medium=podcast&utm_campaign=CTA_1)

2. 

   28 Oct 2026

   How Can Engineering Push Back on Unrealistic Timelines Without Being Seen as Blockers?

   “It’ll take longer than that.” If you work in engineering, you’ve said it, and you’ve probably watched the room decide you’re the problem. That’s the question Stephanie sent in for this episode of Runtime Regret: how can engineering teams push back on unrealistic timelines without sounding defensive or uncooperative? Joe Kennedy, who has spent decades running technology and operations teams, says the answer comes down to one word: transparency. Why stakeholders think engineering is slow When the business brings you a list of requirements and a deadline, they usually don’t understand why it takes so long because they can’t see the complexity behind it. To them, it’s “build the feature.” To you, it’s standing up a development environment, getting the right data, validating that data, securing approvals, moving through development and user acceptance testing (UAT), running quality checks and code scans in your CI/CD pipeline, and promoting the release through pre-production into production. Most of that work is invisible. And invisible work looks like stalling. Draw the picture: turn your delivery process into a timeline Joe’s first move is simple. When someone hands you requirements, say “That’s fine,” and then come back with the date it will actually take, along with a schedule that shows why. * Map every step: data, environments, approvals, development, UAT, pipeline checks, pre-prod and production. * Put it on a timeline so stakeholders can see that the coding is only one part of the effort. * Walk them through each callout so the date stops feeling arbitrary. Once people see all the steps laid out, they understand it’s not just the development effort that takes time. It’s everything around it. Show the real cost of a change request The second lesson: when stakeholders change the requirements, use the same picture to show what that change triggers. The change itself might be four hours of work. Orchestrating it might take two or three days, because it has to be re-developed, retested, re-approved and possibly pushed into the next release cycle. When you make that latency visible, people ask fewer questions and stop treating engineering as the blocker. You don’t need to be a diagramming expert Joe recommends PlantUML for building these timeline diagrams, but you don’t even need to learn it. Ask an AI tool like ChatGPT to turn your list of delivery steps into a PlantUML timeline diagram, drop the result into your presentation, and use it to tell the story of what it really takes to ship. Do that consistently, and you’ll have a much easier time explaining deadlines, managing expectations and building trust with your business counterparts. Watch the full episode above. Got a question about engineering leadership, delivery or working with the business? Leave it in the comments or send it in the chat, and Joe may answer it on a future episode of Runtime Regret. This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit runtimeregret.substack.com (https://runtimeregret.substack.com?utm_medium=podcast&utm_campaign=CTA_1)

3. 

   15 Oct 2026

   Accountable for Uptime, But Not the Architecture? How to Manage the Risk

   You’re on the hook for uptime. When the system goes down, people look at you. But you don’t get a vote on the architecture. Sound familiar? That’s the question Ahmed sent in for this episode of Runtime Regret: how do you manage risk when you’re responsible for the outcomes, but not the choices? Joe Kennedy, who has spent 35 years running operating systems, operations and telecommunications, walks through how he thinks about it. First, let go of the idea that you could have prevented everything Systems go down for a lot of reasons: hardware configuration, network problems, power issues, and everything from the hypervisor up through the software stack. Joe’s point is simple. Nobody on the planet understands every part of today’s systems. If you’re telling yourself outages happen because you weren’t in the room, that’s probably not true. It’s a big reason so many teams moved to the cloud in the first place: controlling every lever that can cause an outage is hard. Your real job: find the single points of failure If you own resiliency, you don’t need to design every component. A single application can rely on 60 or 70 pieces: databases, application servers, open source libraries, reporting tools. Your leverage comes from mapping those pieces and calling out the single points of failure. Think about how we treat physical infrastructure. You want two telecom lines coming into a facility and two power grids feeding it. Apply the same thinking to software: * Where are your data centers or cloud regions, and do they have real fault tolerance? * What are the single points of failure between them? * How are they kept in sync, and what happens when that sync breaks? Accountability without authority is a visibility problem You can’t force an architecture decision, but you can make the risk impossible to ignore. Document the single points of failure, explain the business impact of each one, and put it in front of the people who do make the call. That’s how you turn responsibility without control into influence. Watch or listen to the full episode above. Got a question about infrastructure, reliability or tech leadership? Leave it in the comments and we may answer it on a future episode of Runtime Regret. This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit runtimeregret.substack.com (https://runtimeregret.substack.com?utm_medium=podcast&utm_campaign=CTA_1)

4. 

   13 Oct 2026

   Is an Engineering Degree Still Worth It in the Age of AI and Vibe Coding?

   Is an engineering degree still worth it with AI and vibe coding everywhere? A college student named Trevor asked us exactly that (after roasting our car-video audio). In this episode of Runtime Regret, Joe, a computer science grad who builds and ships real apps to the App Store and Google Play, gives his honest take. What we cover: - Why a technology degree beats a lot of other college degrees on career value - Why knowing how things are built from scratch still matters, in tech and beyond - What happens when vibe-coded apps hit the App Store: security rejections, weak architecture, and apps that don't scale - Why AI works best as an assistant to someone who understands software engineering fundamentals like inheritance and polymorphism - The bigger question: do you need the diploma, or just the skills? Got a question about AI, tech careers, or software development? Send it our way and we may answer it on a future episode. This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit runtimeregret.substack.com (https://runtimeregret.substack.com?utm_medium=podcast&utm_campaign=CTA_1)

5. 

   4 Oct 2026

   They Told Me to Build AI Agents. Now I Can’t Find the Off Switch.

   Six months ago the instruction was simple: build AI agents. Automate the busywork. Move faster. So you did. One agent to summarize meetings. One to triage the inbox. One to write the status report, and another to check the first one’s status report. Now there are agents everywhere. They ping you, they ping each other, and somewhere in the pile is a task a human used to do in ten minutes. This is agent sprawl, and almost nobody warned you about it. How it happens Nobody decides to build forty agents. You build one, it works, and the reward is a request for three more. Each one is reasonable on its own. Together they become a second job: watching, fixing, and explaining what the agents did. The signs you’re there * You spend more time reviewing agent output than doing the original work. * Nobody can say who owns which agent, or what it’s allowed to touch. * Two agents do the same thing, slightly differently, and both are “in production.” * Something breaks and the first question is “which one did that?” What helps * Inventory everything. Name, owner, business function, project and cost for every agent. Yes, you can build an agent to do it. * Sort by risk. Flag the agents that could do real damage and watch those first. * Watch them in one place. Is it running, how often, what triggers it, and which agents depend on which. * Evaluate and cut. Does it do its job? Does another agent do it better? Delete the duplicates. * Take back control. Set an approval process, decommission what you can, and quarantine or retire anything rogue. * Keep rationalizing. Every new agent gets checked against what already exists. It’s ongoing, not a one-time cleanup. AI agents aren’t the problem. Building them without a plan for living with them is. In this episode, a friend in tech stops me at a New York street festival with exactly this question, and Joe answers it step by step: how to rein in agents that are already running amok. If this sounds like your week, subscribe. You’re not the only one. This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit runtimeregret.substack.com (https://runtimeregret.substack.com?utm_medium=podcast&utm_campaign=CTA_1)

6. 

   13 Apr 2026

   It's Not a Problem Until It's A Problem

   Companies on tight budgets often treat compliance as something they’ll “get to later” because, in the moment, it feels too expensive and too disconnected from immediate growth. When every dollar is scrutinized, investing in compliance can seem hard to justify compared to hiring, product development, or sales. So it gets pushed down the priority list. The problem is, this decision quietly compounds risk. Compliance doesn’t demand attention—until it does. And when it finally becomes unavoidable—whether due to a stalled deal, regulatory pressure, or an internal issue—it’s no longer a controlled investment. It’s urgent, reactive, and far more expensive than if it had been addressed earlier. That’s why for many companies, compliance isn’t a problem… until it’s too late. This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit runtimeregret.substack.com (https://runtimeregret.substack.com?utm_medium=podcast&utm_campaign=CTA_1)

7. 

   10 Apr 2026

   How Does Engineering Stay Credible and Protect Themselves in Office Politics?

   This is always a tough one for engineers. Joe answers it for those engineers who just want to build stuff. This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit runtimeregret.substack.com (https://runtimeregret.substack.com?utm_medium=podcast&utm_campaign=CTA_1)

8. 

   7 Apr 2026

   How Can An Engineer Navigate Company Politics?

   We’ve all been there. There’s what leadership says we have to do and then it doesn’t line up with reality. Now what? That’s especially hard for engineers because they can’t fluff it and make it look like it’s right on a powerpoint. It either works, or it doesn’t. This week, Joe tackles that tough question from the point of view of an engineering executive. This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit runtimeregret.substack.com (https://runtimeregret.substack.com?utm_medium=podcast&utm_campaign=CTA_1)

9. 

   8 Mar 2026

   When They Hire A Chief Information Officer Who has Never Actually Coded

   In the Runtime Regret episode, Joe talks about something that genuinely confounds him: the recurring pattern of companies hiring a Chief Information Officer who has never actually run engineering or technology systems in the trenches. To Joe, this is one of those organizational decisions that sounds reasonable on paper but breaks down immediately when you look at how technology work really happens. Companies will recruit someone with a polished executive résumé—someone who has managed budgets, sat in board meetings, or overseen “IT strategy”—but who has never personally lived through the chaos of running real systems. They’ve never been responsible for a failing deployment at 2 a.m., never had to debug a cascading outage, and never had to balance reliability, developer velocity, and operational risk at the same time. What bothers Joe most is the disconnect between the expectations placed on the role and the experience the person actually brings. A CIO is often expected to guide architecture decisions, shape infrastructure strategy, and evaluate the tradeoffs between new platforms and legacy systems. But if the person has never operated production systems themselves—never been “in the weeds,” as Joe puts it—they lack the intuition that comes from experience. They may understand the vocabulary of technology leadership, but they don’t always understand the consequences of the decisions they’re making. That gap shows up in subtle but important ways: unrealistic timelines, overconfidence in vendor promises, or strategic initiatives that ignore the operational complexity engineers deal with every day. Joe frames this as part of a broader cultural problem in how organizations think about technology leadership. In many companies, engineering experience is treated as something you grow out of rather than something foundational to leadership. The result is that executives sometimes come from backgrounds closer to finance, consulting, or general management than to software or infrastructure. From Joe’s perspective, that’s like hiring a hospital administrator to run surgery who has never stepped inside an operating room. The leadership might be excellent in terms of communication and organization, but without firsthand exposure to the work itself, it’s difficult to make grounded decisions. Ultimately, Joe isn’t arguing that every CIO needs to be the best engineer in the room. Leadership, after all, involves far more than technical skill alone. What he is pushing back against is the idea that deep operational experience is optional. The most effective technology leaders tend to be people who have spent real time in the systems they’re now responsible for guiding. They understand the constraints engineers face because they’ve faced them themselves. That perspective builds trust with teams and leads to decisions that respect the messy, complicated reality of running modern software systems. Without that grounding, Joe suggests, organizations risk creating a leadership layer that talks about technology but doesn’t truly understand it. This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit runtimeregret.substack.com (https://runtimeregret.substack.com?utm_medium=podcast&utm_campaign=CTA_1)

10. 

    25 Feb 2026

    What's the Reality on Work/Life Balance?

    In this episode of Runtime Regret, Joe responds to a question from Mark—an engineer and director who finds himself pulled in every direction. He’s leading teams, mentoring, making executive decisions, and still trying to stay hands‑on. From the outside, it looks like success. From the inside, it feels like a treadmill. Long hours, family tension, and the quiet fear of falling behind raise a bigger question: how do you build a meaningful career without sacrificing your life in the process? Joe steps back from tactics and addresses something more foundational—the structure of work itself. Corporations, especially public ones, are designed to serve shareholders. They are not built to provide fulfillment, balance, or personal meaning. Once you understand that work is structured around profit and performance, not personal satisfaction, you can stop expecting it to deliver what it was never designed to provide. That realization isn’t cynical; it’s clarifying. This conversation isn’t about quitting or disengaging. It’s about recalibrating expectations. If fulfillment, balance, and happiness aren’t embedded in the design of corporate systems, then they have to be built intentionally outside of them. Because if you keep looking for relief from the treadmill inside the very system that powers it, the regret won’t show up in your promotion—it will show up at runtime. This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit runtimeregret.substack.com (https://runtimeregret.substack.com?utm_medium=podcast&utm_campaign=CTA_1)

11. 

    20 Feb 2026

    How Can Engineering Explain Why What They Do is Not As Easy as Just Slap AI On To This?

    How does an engineer really explain what they do and how to cut through the “just do it with AI” message. And how do you answer the question why do we need engineering? Why can’t we just vibe code it? This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit runtimeregret.substack.com (https://runtimeregret.substack.com?utm_medium=podcast&utm_campaign=CTA_1)

12. 

    17 Feb 2026

    How To Get Engineering to Trust Product Managers When It Comes to Understanding How They Use Their Tools?

    In this episode of Runtime Regret, Joe answers a listener question about how to build trust between engineering and product—especially when product managers want to better understand the DevOps systems and infrastructure tools that keep everything running. Engineers often fear that increased visibility means interference, oversight, or pressure to move faster without regard for risk. What looks like curiosity from product can feel like encroachment to the people carrying operational responsibility. Joe unpacks why this tension is usually about incentives, not personalities. When product is rewarded for velocity and engineering is accountable for stability, trust doesn’t break down because people don’t like each other—it breaks down because the system pulls them in different directions. This episode explores how to align incentives, clarify boundaries, and create shared accountability so education becomes partnership instead of control. Because when trust between product and engineering fails, the consequences don’t show up in planning—they show up at runtime. This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit runtimeregret.substack.com (https://runtimeregret.substack.com?utm_medium=podcast&utm_campaign=CTA_1)

13. 

    3 Feb 2026

    How to Deal With Shadow IT and Keep It From Getting Out of Hand

    In this episode of Runtime Regret, Joe answers a listener question about shadow IT — why it happens, why it keeps coming back, and how to deal with it without slowing the business down. Shadow IT usually isn’t driven by bad intent. It shows up when teams are under pressure to move faster than internal IT, governance, or resourcing allows. Leaders hire outside engineers or agencies to get results, and over time those decisions create hidden systems, unclear ownership, and long‑term risk. Joe breaks down how to think about shadow IT honestly: how to reduce the conditions that cause it, how to respond when it already exists, and how to balance speed with accountability so teams can move fast without creating future regret. If you’re responsible for systems you didn’t choose, work that happened outside official channels, or outcomes without clear ownership, this episode is for you. You don’t see these problems in the plan.You see them at runtime. This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit runtimeregret.substack.com (https://runtimeregret.substack.com?utm_medium=podcast&utm_campaign=CTA_1)

14. 

    25 Jan 2026

    Structure Vs Spin Episode 4

    Our heroes struggle to get funding to clean up the tech debt so that the AI has a clean slate to work off of. They have to outsmart a really slick presentation but they are not out of ideas yet. ..this week on Structure vs Spin - will Flashy AI's sales tactics distract efforts for responsible tech debt cleanup finally started by the architect and his super-smart Product Officer ? Stay Tuned ... This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit runtimeregret.substack.com (https://runtimeregret.substack.com?utm_medium=podcast&utm_campaign=CTA_1)

15. 

    25 Jan 2026

    Structure Vs Spin, Episode 3

    Welcome to Episode 3 of Structure Vs Spin. The bills are getting big and AI is not solving it! What to do? This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit runtimeregret.substack.com (https://runtimeregret.substack.com?utm_medium=podcast&utm_campaign=CTA_1)

16. 

    25 Jan 2026

    Welcome to RunTime Regret!

    We’ve created problems that we are too damn lazy to clean up and now we’re suffering for it. I’ve lived through it all, check out my podcast and lets get going! Check back for episodes soon! This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit runtimeregret.substack.com (https://runtimeregret.substack.com?utm_medium=podcast&utm_campaign=CTA_1)

17. 

    25 Jan 2026

    The Tech Debt is Still Slowing Us Down, But I Thought AI Would Fix Everything?

    You need to visit the guru! He'll know what to do. This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit runtimeregret.substack.com (https://runtimeregret.substack.com?utm_medium=podcast&utm_campaign=CTA_1)

Contact Runtime Regret Podcast

Guest appearances

Does not typically book guests

Based on episode analysis; this does not confirm that the show is currently accepting guests.