Over the last decade, much has changed in the role of engineering management. Through the 2010s into the peak of Covid in 2021, for many, the role began to optimize for one thing. That one thing was moving information around.
Managers translated context upwards from the team and decisions downwards from leadership, honing their craft on smoothing the friction between individuals and their priorities and whims, and dancing around ceremony-heavy ways of working. Sometimes it was easy to forget that we got this job by being good at building stuff in the first place.
Capital-A agile processes like Scrum, when followed religiously, reinforced this managerial pattern with a plethora of planning rituals and retrospectives, making the manager, in effect, a human router. Reports, meetings, status updates: you name it; you move it about.
Now, this way of working was, in fairness, a rational response to an era of ever-expanding orgs, basic tooling, and an expected way of working, and, after all, it was what the job rewarded at many companies.
Yet, as we continue to write about, the situation has changed, with companies now flatter, context more discoverable, tooling far better, and AI assisting you with the majority of grunt work that used to fill your brain and calendar. An opening is appearing for you to do something better with your time.
As such, the industry is no longer asking you to be an information router; it’s asking for you to be someone who can sit deep in the details with the people doing the work, make technical contributions, and move decisions and execution forward at pace. Some managers are effectively being told to do this or else, and, understandably, some are finding that uncomfortable.
However, not all is lost. The good news is that if you’re a manager who used to be an individual contributor (which is likely most of you), you already have what’s being asked for in this new world. The skills that got you promoted in the first place, namely the architectural thinking, instinct for debugging, quality of your judgement, and technical taste, didn’t evaporate when you stopped writing code. They merely went dormant.
The pitch of this article is that engineering management today in the AI age isn’t about upskilling, it’s actually about rediscovery, and the ramp back to your technical best has never been easier with the tools that are now available. Change can be embraced and it can be fun.
Here’s what we’re going to cover:
- Engineering management’s drift into being an information router, and the conditions that made that happen.
- How your engineering judgement is a unique skill that transfers across stacks and domains, and why the pattern-matching you’ve built over years is right there for you to pick up again and put to work.
- What has and hasn’t changed over the last five years, and why the fundamentals you spent a decade honing are still exactly where you left them.
- An example weekly practice that keeps you close to your team’s technical work with AI, and what leaning into your technical skills unlocks for you, practically and emotionally.
If you find this topic interesting, here are some complementary articles from the archive:
- Should managers still code? is the defensive version of this question (“do I have to?”). For framing, models had a significant step change at the end of 2025, and this article built the case that these models could start to bring you closer to the details.
- Use it or lose it explores skill atrophy, notably the risk of AI diminishing your cognitive ability rather than being a thinking partner, which is always worth keeping in mind as we use more AI everywhere all the time.
- Going direct makes the case for ignoring the org chart and engaging directly with the work, which is what flatter orgs now demand. We build on that here.
- The right kind of AI sceptic argues that scepticism about AI without having real first-hand use is wrongly clinging to an identity, and the solution is to get your hands dirty with the tools to form your own judgements.
So, let’s get going.
The drift
Most managers I know didn’t make a single, deliberate decision to step away from the code. It happened gradually, compounded by entering the discipline during a time of major headcount growth in technology. Their first promotion brought a team and more coordination work, and their second brought teams of teams, and, unsurprisingly, even more meetings and distractions. Then, at some point, they would find themselves with a layer of managers between them and the work, and their contribution graph on GitHub for the year was blank.
Oh, and that was me, by the way. My inflection point was working my way up from seed round individual contributor to VP Engineering at Brandwatch, after we grew rapidly off the back of three VC rounds. I ended up owning how we worked, how we hired, and how we expanded as the org scaled, which was challenging and I really enjoyed it.
However, with managerial layers beneath me, getting meaningfully involved, pre-AI, in any one team’s code became harder and harder, and the prevailing principle of the era said that was fine: engineering management was a craft in itself, where delegation was the ultimate virtue, and coding was what you’d graduated from.
It wasn’t all hands off, though; many technical decisions stayed with me, and I was still present in decisions made about architecture, product, and strategic direction. What drifted was being close to the code, because there wasn’t any time in the week that wasn’t already spoken for by people problems and planning problems, and the slices of time that remained were never enough; nor did they feel like they needed to be.
Multiple layers below you did make direct involvement harder, especially in the delegation era, where the industry actively rewarded coordination over code. Hands-on leaders were often seen as a bug! Words like meddling and micromanagement were often thrown around for senior managers that still cared about the code, which is deeply ironic compared to what companies say that they want from leaders today.
So, the question now isn’t how you ended up as a router; it’s what you do with your skills to transform yourself into a desirable leader today.
What you already know
If you’ve been hands-off for some time, you might ask, “What do I still know about writing code today?” Well, it’s more than you probably think.
When I joined Nordhealth from Shopify, I was worried it would take months to feel useful. The stack and the product domain were totally different from what I’d worked on before, so I assumed my past experience would have limited transferability, and it would take a lot of time to ramp up.
However, much of it did transfer, and within a few weeks I was recognising things I’d seen elsewhere, like needing to dramatically increase the speed of shipping, a Code Yellow brewing around nagging uptime issues, the need for database query optimisation due to ORM sins, weird Redis bottlenecks, a lack of circuit breakers in critical parts of the code, and errors and timeouts that had gone unexamined for too long and had become noise. None of this was because I am some kind of genius, I was just pattern matching from problems I’d already encountered at other companies.
Two decades of being close to real systems had built up a library of patterns in my own wet and mushy neural network. It was there all along, as soon as I went looking. And diving into the details in Python isn’t that dissimilar from doing so in Ruby (Shopify) or Java (Brandwatch) or my PhD (C++). After all, it’s all code written by humans for humans, and a lot of the problems being solved at SaaS companies are similar if you squint.
There’s a useful body of research on this phenomenon. Classic studies of chess expertise showed that masters aren’t calculating faster than novices, they’re recognising patterns instead, because years of play had built up a library of structured chunks in their memory. All of the time you have spent building, designing and running systems also builds up these chunks even if you don’t know that they’re there.
This is what Daniel Kahneman called System 1 thinking in Thinking, Fast and Slow: the fast, automatic recognition that comes from accumulated experience. In engineering you experience it in the unease at reading some code and knowing something is off before you can put your finger on what.
Expert intuition, as Kahneman and Klein argued, turns out to be highly trustworthy in the conditions engineering management provides. It is a domain with genuine regularities, and it takes time on the job to learn them.
Call it intuition, call it taste, call it scar tissue if you prefer, but whatever the label, your System 1 wet neural network has been trained on everything you’ve ever shipped, reviewed, and watched break.
This judgement layer, in other words, is a highly durable layer, and it’s already there. When actively getting closer to the details, or when you change roles, you can use it with confidence, and even better, today you can use AI to sharpen it even further.
What’s actually new
Over the last five years there’s been a huge influx of new tooling: not just AI, but frameworks, languages, infrastructure primitives, and observability stacks have all shifted in ways that can make the technical landscape feel unfamiliar, if you’ve been away from the details for a while, or have been at a company with older tools.
What hasn’t changed, though, is the durable layer of the craft: good architecture, protocols, databases, caching, queues, idempotency, backpressure, and so on, all matter just as much now as they will in the future. We still use deploy pipelines, gradual rollout, A/B testing and have on-call, code review, design docs, and RFCs.
If you’ve got a solid grasp of the fundamentals, rebuilding the specifics on top as you actively become more detail oriented is faster than it’s ever been, because AI makes learning, relearning, and exploring and investigating so much easier.
So given that you likely already have great fundamentals, and you also have this amazing new AI tooling for learning and doing, how can you rapidly shift towards a modern hands-on and in-the-details leader, rather than a 2010s information router?
A new practice
So what does re-engagement look like, day to day, if you want to reinvent yourself in your managerial role? The biggest change is that you’re not going to be spending the majority of your time on activities that gather or route information. Instead, you’re going to be spending it as close to shipping as possible: both with your team, and on your own.
Engineering managers can:
- Regularly contribute code or be the lead Directly Responsible Individual (DRI) for one project on their team.
- Pair regularly with engineers on hard problems as they are being worked on, not just review the code they have already produced.
- Co-author (or sole author) architecture RFCs and design docs for their team or domain rather than delegating them entirely.
AI makes the above so much easier than before. Going up the org chart…
Managers of managers can:
- Focus in and dive deep using the methods above into two or three projects every week that are at the most critical junctures or bottlenecks. They should investigate technical issues or blockers themselves to gain first-hand information.
- Be the final sign-off on architecture decisions or design docs in their org, taking accountability for those architectures rather than just approving them.
- On big technical bets, prototype or sketch their own solution first rather than rely on others, using AI to get into the detail of systems they haven’t touched in a while (or ever).
Our weekly rhythm
My own weekly rhythm looks like this, and I think the framework is adaptable for any team (or org) that wants to encourage in-the-details management. It involves a combination of empowering individual engineers, delegating information sharing to those closest to the details, and therefore freeing time to really understand what’s going on, both in the code and in projects themselves.
Linear is our source of truth at the company. We have all DRIs do weekly updates, and those DRIs are individual contributor engineers. Each week I scan the updates, look at what’s usable from dev branches, or via demo recordings, and identify the three to five projects that I feel genuinely need close attention from me.
Those are the projects I go direct on. In practice, that means messaging the DRI to understand what’s in the way, whether it’s feedback, a concern, a blocker, a one-way door, or a prioritisation call, working through the decision with them, and helping them keep moving. Some of these interactions happen asynchronously in Linear or Slack; for others, as leadership we run office hours all through each Wednesday. Here, we book 15 to 30 minute DRI meetings when something needs synchronous time.
We run this as a push-pull system. We as the senior leadership team select DRI meetings using the method described above, and DRIs themselves can get time with us easily via a booking link to those office hours. It does mean that Wednesday can be a meeting gauntlet, but we keep Tuesdays and Thursdays as no-meeting days, so it balances out.
Importantly, since all DRIs are individual contributors, we as leadership get to go right to the source. As well as doing all of the usual management stuff around assisting in deciding priorities and resourcing, we can also all look at designs, demos or the code together so there is absolutely zero information passing required in the whole management chain.
The old router role was about moving context through you, from team to leadership and back again. This practice is the opposite of that. In detail-oriented management, context stops being a thing you forward, and starts being a thing you sit inside. Your job is to be right there working on it with your team, rather than reporting it.
Routing through the chain of command is mostly wasteful communication, since context is often lost at every hop and decisions slow as they travel.
Do deep dives with engineers
At a software company, code is truth. Every problem worth solving eventually turns into code that solves it, and everything downstream (reliability, customer outcomes, revenue) flows from that. How can you always know the truth?
Pair programming is one of the best activities for getting close to the details. Sitting alongside an engineer as they work through a problem gives you a level of technical exposure and feel that no status update or design document can match.
Pair programming isn’t new, of course. But what’s changed is that AI now lets managers contribute meaningfully as the programmer in the pair, not just as the observer. Coding harnesses like Codex and Claude Code, which I use daily, close the gap between what you want to build and the syntax you can’t quite remember how to express.
AI is useful in two ways. Before the pairing session, it’s a thinking tool: you can use it to brainstorm outstanding questions, explore the codebase yourself, and come up with ideas of what to do.
In the session itself, AI becomes a building tool. Rapid prototyping is so easy now, allowing you to pair on a quick implementation to test a hypothesis or stress test a design. When it comes to pair programming itself, getting back into the details as a manager is limited more by your problem solving capabilities rather than your IDE kung fu while someone watches. You could argue pair programming is now effectively trio programming, given that it’s often two people and AI.
I’ve had a ton of fun doing pair programming sessions recently because I can so quickly dip into areas of the codebase I don’t know very well with AI, and contribute meaningfully and quickly in the session as a result.
Get stuck in with incidents
Incidents are one of the best places for a manager to get close to the details. Stressful situations always force you to learn. Practice being much more active during incidents that happen during office hours. Stop what you’re doing, join the call, and offer to share your screen, driving an AI prompt yourself while the team contributes context and validates investigation paths and recommended actions that you work on together with AI.
The prompt itself becomes a shared workspace: you capture the conversation into the incident log, surface hypotheses, and generate candidate next steps as you go.
I did this during a spate of database issues last year, and it helped us identify root causes faster. It turns out AI is excellent at drilling down to obscure MySQL configuration nuances. What mattered more was that it put me in the seat of contributor rather than observer, which is great for learning and far more rewarding.
Investigate a broad cross-cutting problem
Another natural place to get close to the code is when a broad, cross-cutting problem presents itself. Something like a customer saying “why is this part of the app slow?” or an engineer saying “why does the test suite take so long to run?”. These are often broad questions without an obvious owner, spanning multiple services and teams. They’re also an amazing opportunity to get into the details.
The workflow is straightforward. Check out the codebase, deploy it locally, and use AI to explore the problem end to end. Use whichever large model you have access to in order to investigate across the whole codebase, correlate the observed behaviour with the code that produces it, and reason about what’s happening from first principles. See if you can work it out yourself rather than delegating it elsewhere.
You get three things out of this at once: you have a good shot of finding the root cause, you learn a lot about the codebase in the process, and you’re then in a position to have a meaningful discussion with the team about the fix, or to even fix it yourself. Perhaps that area of the app is slow because of 5 lines of very silly code that you’ve just discovered. See it, and fix it.
More broadly, this is exactly the kind of behaviour you want to encourage across your organisation. You want engineers who don’t feel constrained by the boundaries of their own team. Instead, you want a place where everyone freely makes everything better all the time. It’s a way to solve the tragedy of the commons, where cross-cutting problems end up being nobody’s responsibility and never get fixed.
One of our engineers did exactly the above over two quiet days while most of Europe had a public holiday, and we came back to see our test run time reduced by around 30%.
Make it structural
The more layers you have between you and the code, the more your default day pulls away from it. Sometimes, especially in big companies, willpower alone won’t fix that, so you need structure and process that makes you stay close.
At Shopify, the GSD system was an internal project management tool for every single project in the company. Engineering directors were the first required sign-off on each of their team’s projects, which meant that my name was next to every single one of my team’s projects in the department as the accountable engineering owner.
That structural accountability pulled me towards the details in a way that no amount of personal discipline ever did, especially if you have leadership asking you questions about what is being built, how it is designed, or how long it is taking. If you have the chance to design accountability like that into your org, I highly recommend it. It keeps you very sharp.
And ship code!
If code is truth, then the most direct route to being in the details is to write it yourself. Ship small bug fixes, land a minor feature, build a prototype: anything that forces you back into the codebase with a tangible output at the end.
AI has completely changed the game here. The old objections (“that’s too hard to get back into,” “I don’t have the context anymore”) used to be reasonable excuses. They aren’t now. You should get comfortable using AI to press, poke and probe in your codebase as it has never been easier to do so, and you can let agents run in the background while you get interrupted by other things.
Push against any old mental barriers you may still have, and you will surprise yourself with what you can achieve in hands-on time while still being a manager. Will Larson wrote in late 2025 that he’d merged more PRs in six months at Imprint than he had in the prior decade combined, with the observation that “the overhead of writing software at work is substantially lower than it was a few years ago.” It is completely true. Challenge yourself to ship something. Start with something small and get it into production, and soon you’ll likely find it is not just incredibly useful in staying close to the details, but it is both empowering and addictive.
Work is fun again?
Changing how I do my job over the last couple of years, both by actively being in the details, and also heavily using AI, has made work so much more fun for me.
Even though I work for a public company, I feel like a founder CTO, in the details, across the full surface area I’m responsible for, able to switch between one problem and another with AI helping me rebuild context as I go. It’s the closest I’ve felt to being a hands-on engineer again, except I now feel like I have superpowers, and it has happened so quickly.
As such, senior management has become far more interesting and exciting over the last year, and being hands-on is now the main bulk of my job rather than a rare treat I get from time to time, or at the weekend. I can do more, learn more, affect more, and automate or build in ways that I couldn’t previously.
None of that was on the table when the router role was the job. I’m so glad that everything is different now.
Your turn
Here are three things you can try this week:
- Pick one project to go deep on this week. Choose something you know you’ve been distant from, or a project with a big cross-cutting problem like slowness. Use AI to quickly ramp up on the codebase, find issues, and make changes, then fix a bug or close a ticket off the back of it.
- Pair with two or three ICs on your team. If you’re not already pairing regularly, book sessions with two or three engineers this week and get a real feel for what it’s like to be shipping on the front line. What’s the developer experience like, what needs improving, and where are the bottlenecks in tooling or build times?
- Drive the prompt in your next incident. Next time there’s a live issue, volunteer to run the AI-assisted analysis: logs, graphs, hypotheses, and a plan of next steps at each moment. Don’t be the note-taker, be the prompt driver.
Wrapping up
The industry doesn’t need more human routers; it needs leaders who sit in the details with the team and contribute. If you’re a manager who used to be an IC, the foundation is already yours, and the tooling makes it easier than ever to access it.
As hinted at earlier, being in the details is all about being directly exposed to the truth of what’s going on. If you’re not seeing the truth first hand, then there is a risk that you’re missing things, or, even worse, that the truth is being altered to please you instead. That problem is the subject of this month’s paid companion, which is about building truth seeking organizations.
Until next time.