I Don't Keep Up.
I'm Lean.

It's one of the most loaded questions in any technical interview, any annual review, any hallway conversation with a senior engineer:

"Are you keeping up with everything that's happening in the field?"

The implied correct answer is yes. The honest answer, for me, is no — and I stopped apologizing for that about a decade ago when I found a better frame for it. Not laziness. Not complacency. Lean manufacturing.

The analogy isn't casual. In Lean manufacturing, the goal is to eliminate waste — any activity that consumes resources without creating value for the end product. Just-in-time (JIT) production takes it further: materials arrive exactly when they're needed, not before. No warehouse full of parts that might be used someday. No stockpile of inventory tying up capital.

My brain works the same way. It has finite capacity. Every hour spent absorbing a trend I'll never apply is an hour not spent going deeper on something I actually use. Every tool I learn "just in case" is cognitive overhead I carry until I eventually forget it anyway.

That's not a bug in my approach. It's the whole point.

The Lean concept that maps most cleanly to learning is the distinction between push and pull systems. In a push system, production is driven by forecasts — you make things in anticipation of demand. In a pull system, production is triggered by actual demand — you make what's needed, when it's needed.

Most "keep up with trends" culture is a push model. The industry produces content, courses, newsletters, and conference talks, and the expectation is that you absorb as much as possible on the assumption that something will eventually be useful. It's just-in-case learning.

I run a pull model. Learning gets triggered by a real signal — a problem I'm trying to solve, a skill gap between me and a current goal, a technology my team is actually adopting. That signal pulls knowledge in. Until the signal exists, the capacity stays available for something that does need it.

The system isn't about knowing less. It's about knowing what you know more deeply, and being honest about the difference between knowledge you've actually used and information you've accumulated.

There's a professional culture in software that treats breadth of awareness as a proxy for competence. The person who's read every new framework announcement, followed every release, attended every conference — they seem like they're on top of it. And maybe they are. But "seems like" is doing a lot of work in that sentence.

The real question is return on investment. How much of what you've consumed has meaningfully improved your work? For most of us, in most roles, the honest answer is: a fraction of it. The rest was interesting but not valuable — and interesting-but-not-valuable is exactly what Lean is designed to eliminate.

I'm not arguing everyone should use my system. Some roles genuinely require broad awareness — developer advocates, architects scoping a new platform, anyone whose job is literally to evaluate trends. For those people, the signal is real and the learning is appropriate.

But for most of us, the pressure to "keep up" is ambient and social, not role-specific and functional. Naming that clearly — and choosing a deliberate system instead — is what Lean looks like applied to yourself.

And yes — if keeping up with trends has genuinely paid off for you, I'm glad to hear it. That's a real signal too. Different systems work for different people. The mistake is running someone else's system without questioning whether it's the right one for you.