There is a massive flaw in how most engineering organizations treat artificial intelligence: engineering leaders can't isolate AI's contribution because it's baked into baseline velocity. The prevailing advice for enterprise AI adoption is straightforward: treat an AI agent like a new hire. In the engineering space, this isn't just a convenient metaphor. It's a pretty accurate financial model. When you deploy a coding assistant or an autonomous agent, you are making a direct trade-off. You are e

In software development, momentum is everything. When a team is in the flow, complex problems get solved, features ship, and products evolve. But speed is rarely bottlenecked by how fast engineers can type or how quickly code compiles. More often than not, development speed dies in the calendar. Too often, teams are brought to a grinding halt simply trying to get a meeting together. In my experience, this calendar-induced drag manifests in two distinct ways—one is easy to fix, and the other requ

In modern software engineering, "servant leadership" is widely accepted as the gold standard for management. Over the years, this industry has learned that our primary job as leaders is to invert the pyramid: unblock the team, foster autonomy, and get out of the way. But for technical leaders, this idea introduces a unique and uncomfortable friction. While you want nothing more than to empower your developers, at the end of the day you are still the one accountable for the health, stability, and

Starting a new role is always full of learning about new people, processes, and systems, but it also often comes with a familiar, daunting challenge: the blank page. Recently, I stepped into a new position, and my first task is to define the strategy and long-term goals for a new area of focus. In the past, this phase of the job meant a lot of siloed research, scheduling fragmented syncs with busy stakeholders, wrestling with initial frameworks, writing drafts of the vision and goals, and sharin

About ten years ago, I wrote a pair of blog posts ( here and here ) on the early days of the microservices boom. The industry was rushing toward distributed systems like they were the answer to everything. My argument then: distributed systems offer real power, but the monolith has a tax too, and jumping to distributed systems too early introduces a massive operational burden you probably aren't ready to pay. A decade later, the pendulum is swinging back. We're seeing a wave of high-profile "un-

Every engineering org I talk to right now is celebrating the same number: velocity. AI writes code faster, PRs merge faster, tickets close faster. Everyone's thrilled. I think we're celebrating the wrong thing, and it's going to bite us. Here's the uncomfortable truth nobody wants to say out loud: velocity does not equal direction. Generating a massive volume of code doesn't mean your team is moving toward the right business outcome. It doesn't mean you're building something stable or maintainab

There's a line near the end of the Pixar movie Ratatouille that I keep coming back to lately. The food critic Anton Ego, after eating Remy's ratatouille, sits down and writes his review. He says that Gusteau's motto, "Anyone Can Cook," was always misunderstood. It doesn't mean everyone can be a great chef. It means a great chef can come from anywhere. I've believed that about software for a long time. Long before AI could write a for loop. I've spent years encouraging people without a technical

A CTO I worked with years ago used to tell a story about 30 monkeys in a room. Bananas are hanging from the ceiling. Every time a monkey goes for the bananas, all of them get blasted with freezing water. Eventually, they stop going for the bananas. Then you start swapping in new monkeys, one at a time. A new monkey walks in, spots the bananas, and goes for them. The others immediately stop him, even though they've never been sprayed themselves. Keep going until every original monkey is gone. Now

I've spent the last three posts describing Logic Entombment as an architecture problem. Technically, it is. But the reason it persists, the reason organizations keep deferring the work, isn't technical. It's financial. More specifically, it's that the cost is invisible until it isn't. I wrote a few weeks ago about the hidden headcount in your AI bill, the idea that companies that replaced junior engineers with AI are now quietly hiring those engineers back to manage the AI, and that the labor co

My last post talked about the problems that Logic Entombment poses for AI; now, let's talk about how we can start to fix them. One thing I've noticed in every conversation about modernizing legacy systems is that the prescription arrives before the diagnosis. Someone reads about Domain-Driven Design or microservices, gets excited, and immediately wants to rearchitect everything. I've been guilty of this myself. The problem is that "rearchitect everything" is a multi-year program that requires su