Engineering-Leadership

There’s a habit I can’t turn off. Whenever I’m working on something — whether it’s organizing a project, structuring a team, or just figuring out how to approach a problem — my brain immediately goes to: what’s the optimal shape for this? What information needs to flow, and between whom? Where are the boundaries?

It’s the kind of thinking that Matthew Skelton and Manuel Pais gave a name and a framework to with Team Topologies. If you haven’t read it, the short version is that it offers a set of mental models for how engineering teams should be structured — and not around org charts, but around the flow of value. How teams communicate, where cognitive load sits, what interaction modes make sense for a given type of work. It fundamentally changed how I think about engineering organizations, and honestly, it’s one of those frameworks that keeps paying dividends years after you first encounter it.

I’m writing this because I’ve made the mistake myself. I assumed everything should be an agent. If there was a problem to solve, my first instinct was, let’s build an agent for that. It took running headfirst into the tradeoffs — performance, debugging headaches, and unnecessary complexity — for me to realize that not everything benefits from being agentic.

And honestly, this isn’t a new struggle. We’ve seen the same pattern with AI more broadly: reaching for it to solve problems that are often handled better with simpler, more traditional approaches. Now, agents and agentic systems are following the same trajectory — being turned to as the “solution” even when they’re not the right fit. Or at least not the immediate.