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 always a tough one for engineers. Joe answers it for those engineers who just want to build stuff.

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.

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.

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.

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?

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.

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.

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 ...

Welcome to Episode 3 of Structure Vs Spin. The bills are getting big and AI is not solving it! What to do?