The treadmill that never stops

I was six months into my new leadership role when I realised I’d made a terrible mistake. Not in taking the job - in how I was trying to do it.

I was responsible for six development teams, each with their own tech stack: PHP, Java, C#, Node.js, Python, C++, and a smattering of many many more. Every standup or conversation surfaced a framework I’d never heard of. Every architectural discussion referenced patterns I’d only read about in passing. Every security alert demanded I understand vulnerabilities across languages I’d never written professionally in.

I’m not a polyglot. I came up through one stack and got deep in a few related technologies. Now I was supposed to have informed opinions on all of them?

Then a zero-day landed. Every team was affected.

I found myself playing catch-up, spending a Sunday evening trying to understand the details, the number of tabs in my browser was growing exponentially. I don’t remember the time I stopped, but everyone was in bed. I was exhausted, behind on my actual leadership work, and no closer to understanding the full picture. The engineers who were closest to the details clearly knew more than I’d ever learn in a weekend. I was chasing something I’d never catch.

I was trying to maintain my developer-era learning habits in a role that had fundamentally different requirements. Something had to change.

Just-in-case does not scale

When I was a developer, it was my job to understand the new technologies and frameworks, whether for efficiency, security, or pushing the products forward. I had the time, to explore, understand the nuances of the tech and assess its relevance to the stack. As a developer you are the “expert in the room”.

New frameworks, languages and platforms will continually launch, that’s not going to stop. AI is being a disruptor, multiplying this too, it is changing software development fundamentally, not just adding to it. This pace isn’t going to let up anytime soon.

As a developer, I was hanging on the twitter feeds and tech RSS feeds (it was a while back), everything new that came out, I wanted to try, I wanted to have an opinion on, I wanted first-hand exposure and experience of.

As a leader, I was not blessed with the time to go deep and understand, my role demanded a broader context, not deeper understanding. The value add shifts from execution into judgement, and that can be a jarring experience.

Consequently the stakes are higher now, you are a step further away, and any call you make now impacts the whole team. Learning everything just-in-case isn’t sustainable anymore.

However, the reason I was a developer in the first place means the desire to understand and experiment is still there, and this is where the conflict enters. This can lead to unsustainable habits if you don’t adapt, you either find yourself experimenting evenings and weekends and burn out or disengage completely, thus losing technical credibility. Neither of these extremes serves you or your team in the long run.

Just-in-time learning effectively

The shift happened slowly, then all at once.

I stopped trying to learn everything and started learning only what I needed, when I needed it. Not out of some strategic master plan - out of survival.

I started talking to the engineers before making decisions. I learned enough about each technology in the context of our actual problems, not hypothetical ones. The focus shifted from comprehensive understanding to targeted learning, and suddenly, I wasn’t racing anymore.

Building a learning backlog

I run my own JIRA board, and have a “Research column” exactly for this. I gather the tech of interest as I hear about them. Priority on what to dive into is based on

• Applicability to the product/business.
• Market trends.
• The interest from the team.
• Or my own personal curiosity (least priority).

An example that I’ve pushed up the priority list is, of course, AI cli tooling, where it can streamline processes and workflows (side win: just getting it to summarise what’s changed for a commit message). That’s not surprising either, as AI, agents and techniques are plentiful in that column, but also they all seem to be accelerating up the priority list.

Switching from “nice to know” to “need to know NOW”

That works for planned learning. But not everything waits for the backlog. Sometimes the decision gets forced:

• Industry shift that affects your product.
• Team is proposing a new technology.
• Security vulnerability or compliance requirement.
• You need to make an architectural decision.
• Technical debt reaches breaking point.

Fast learning techniques

Adopting Just-in-time learning doesn’t mean you’ve suddenly found a heap of time to do it. Scanning the documentation can tell you enough without delving in too deeply. Alternatively, where needed, building a small PoC helps visualise it with your own context; however it needs to be timeboxed to 1 or 2 hours max, or it can quickly become a time-sink.

Recently, I’ve been using AI-agents to support this fast learning. I have a multi-agent system where specialised research agents gather information, collation agents merge findings, report agents produce a standardised output and a parent agent orchestrates the workflow for me. Within 20 minutes, I have a summary that gives me exactly what I need to be able to have an informed conversation. The research that would have taken me a weekend took next to no time, and I got the “what” and “why” without drowning in the “how”.

Also, don’t forget to talk to the team, this is incredibly valuable, you’re talking to the experts, remember. It’s the team’s job to provide the deep analysis, it’s my job to ask the right questions.

This initial knowledge absorption is critical, but it shouldn’t stop there, it’s now part of your continuous improvement. The new technology that’s just landed now, will play a part in the context of the next tech decision, that will be along shortly.

Making it sustainable

As a leader, I’ve experienced FOMO several times: “everyone else knows about this and I don’t”. Remember those six teams I mentioned? Attempting to understand the deeper nuances of each language would have broken me. And thus caving in to FOMO means you ultimately chase aimless consumption.

Learning through the team also helps establish this culture in the team. They are your multiplier, let them be the deep experts - it’s what they want to be.

Also, as I’ve come to realise, there are some tickets in my research column that I’ll never get to fully know.

Closing thoughts

That Sunday evening I spent trying to understand the zero-day details feels like a different lifetime. I still have moments of FOMO (AI is doing a great job of providing anxiety). But I’ve learnt to pause and assess relevance before diving in. Most of the time, the urgent feeling passes and I realise I don’t actually need to learn that thing right now. I close the tab. I move on with my day.

What I wish I’d been told earlier: You don’t have to know everything. You never did. Even when you were an IC deep in one stack, you didn’t know everything about that stack. The difference now is that the gap between what you know and what exists is more visible. That visibility doesn’t mean you’re falling behind, it means you have broader context.

This isn’t about knowing less. It’s about knowing what matters, when it matters, and who on your team knows more (and there’s always someone). I’m not less technical now than I was as a developer. I’m technical where it counts: understanding trade-offs, asking the right questions, making judgement calls that affect entire teams.

That’s not a compromise. That’s leverage.