Leadership Garden
Every few months someone on one of my teams asks me how I keep up. It usually comes the week a new model drops, or the week a reorg gets announced, and lately those have been the same week. I don’t keep up. I stopped trying a while ago.
What I tell them instead is to get really good at navigating change. (The version I say out loud has a swear word in it.) In practice that means reacting less, learning principles instead of tools, and shipping more than you read. This is for engineers and engineering leaders who feel like they lose ground every time the ground moves.
I think most of them are tracking the wrong number. They count how current they are: which launch threads they’ve read, which agent framework they tried last weekend, whether they recognized the thing someone mentioned in standup that everyone nodded at. Knowing about a change feels like adapting to it. Those are two separate skills, and the people I’ve seen handle change well are mostly good at the second one.
React less
A Reddit post in r/AI_Agents stuck with me last year. An AI engineer described taking in close to twelve hours of AI content a day: lectures, papers, newsletters, podcasts on the train. Most of the post was in capital letters. He still couldn’t keep up, and judging by the replies, nobody else could either.
Leaders do a quieter version of the same thing. A reorg gets announced and a manager rewrites the team roadmap that afternoon, before anyone knows what the reorg means for that team. A VP mentions a metric in an all-hands, and by Friday two teams have dashboards for it. I’ve done both. Each reaction looked responsible at the time.
The cost shows up a quarter later. A team whose roadmap changes every two weeks learns that roadmaps are suggestions and stops arguing about them, which is worse than arguing. Your team sets its alarm level by yours. Most of those announcements didn’t change what anyone should do on Monday, and the ones that did were still there two weeks later, easier to read.
The filter I use is a single question: what does this change about a decision in front of me this month? Usually the honest answer is nothing, so I note it and move on. Sometimes it’s “I don’t know yet”, and then I wait until I do. Only an answer that names a specific decision gets action.
“Keep up or get left behind” is the pitch behind most of the AI courses being sold right now, and it has a grain of truth. If your company moves clouds or your biggest customer leaves, you don’t get to wait it out. Nobody needed a newsletter to notice either of those, though. The changes that demand speed are almost always the ones you can’t miss.
Master principles, not tools
I’ve written production code in Python, Ruby, OCaml, Clojure, C#, Go, Rust, TypeScript, PHP, Java, and Haskell. Today I’d need a reference open for half of them. What carried over between them was everything that wasn’t syntax: how to model state, where to draw a boundary, how a failure travels through a system, why the boring option usually wins.
Tools have always expired. What’s new is how fast. Sean Goedecke pointed out in August that “make working changes to large codebases” was on his list of things models couldn’t do at the start of 2026, and had dropped off it by the time he wrote the post. If your edge is knowing the gaps in this quarter’s tools, your edge has a shelf life of about a quarter.
Goedecke would push back on part of this. His short-term advice is to squeeze every advantage out of the tools, and he’s right that refusing them is a losing position. I’d go one step further. Fluency in this month’s agent doesn’t compound. The two durable skills he names, knowing your own system deeply and explaining it clearly, don’t live inside any tool, and they’re exactly what makes the next tool cheap to pick up.
Principles are also what make reacting less safe. If you understand why a queue decouples a producer from its consumers, a new streaming product is a variation you can judge in an afternoon. If all you know is the old product’s config file, every release is a new world, and you’re back to reading everything.
The same holds one level up. Every reorg I’ve been through felt new, and none of them changed what people needed from me during it: to know who decides what, and to hear the truth from someone when the answer is bad. Knowing that, I can skip the change-management framework and spend the hour writing to my team instead.
Ship more than you read
Reading is the comfortable way to feel current. You can do it on the couch and it never fails. It also gives you plenty to say in meetings, which is the trap. I’ve sat in rooms where everyone could describe the new thing fluently and nobody had used it past the demo. This is also what you can see in most AI hype Youtube videos.
Most of what I actually know about coding agents I learned on weekends, building things nobody asked for: a process supervisor in Rust, a self-hosted analytics tool that does what Plausible does, and a weather app that pulls several forecasts and shows where they disagree. None of these will make money, and that was never the point. Each one hit walls no launch post mentions. I learned how often I’d throw the agent’s output away, and how often my own taste was the only thing between the codebase and a pile of defensive code nobody needed.
My rough rule is an hour of building for every hour of reading about a change. When I let that ratio slip, I can talk about the change well and make decisions about it badly.
For a leader, shipping doesn’t always mean code. It means a decision written down, or a pilot with an end date. It can be as small as one change to how the team works that you can point at a month later. When a reorg lands, the manager who sends a one-page note on day two, covering what changes for the team and what doesn’t, is navigating it. The manager who forwards the announcement with “more details soon” is still reading about it.
Pick fewer changes
Change will keep arriving faster than anyone can read about it. That’s the one forecast in this post I’m sure of, and it stopped bothering me once I stopped trying to absorb all of it. Pick fewer changes. Understand the ones you pick well enough that the lesson carries to the next one, then prove it with something you built.
Everything else is staying informed. Being informed was never the job.