The Engineering Manager

Recently at Nordhealth we embarked on a re-skin of our entire application: a visual uplift of the whole product to bring it into 2026. These kinds of changes have a big blast radius and are inherently risky, but we championed the individuals to be bold, working across any surfaces that needed an uplift. Generally speaking, it worked: they delivered, and the application now looks better than it has in years. However, because we had changed almost all of the product, we also shipped a big bag of papercuts that annoyed our customers.

The snags were things like tables laying out awkwardly at certain screen sizes, inconsistencies in scrolling and loading behaviour, and in some cases minor buttons and filters that had stopped working properly.

We dealt with a lot of support tickets, fixed a ton of bugs, and now that we’re out of the other side, we’re really happy to have a much better visual foundation to build upon. In this instance, we felt that the only way to make dramatic change happen is to go through some hurdles of pain like this one, because, when holding a long-term view, it is the right thing to do.

However, when stuff goes wrong like this, those with decision making power can turn it into a lesson learned to not try bold things again in the future. Instead, despite a bit of a mess, we continually championed the team, telling them and, importantly, telling the rest of the company that the direction and the intention was good, that they had executed fast, and that they had made the right calls along the way with the information that they had available at the time.

In the post-mortem we asked how we could roll out large-scale CSS refactors more safely, and we came away with a set of improvements to our rollout process and to our ability to better feature flag specific areas of the codebase. We are continuing to work on these now, with effort going towards fixing the process and the system.

Many products suffer from a tragedy of the commons where much-needed improvements never happen because the change requires too much coordination between people and teams. An individual contributor needs to talk to their manager, designer, product owner, some other team’s manager, designer, and product owner, and so on, until nothing ever gets done or improved.

As the industry has changed, our organisations have flattened. Leadership is closer to the details, and someone has to own the outcome, talk to stakeholders, and get the work done without management needing to be part of every decision. The simplest answer I know is named ownership: one person per project, by name, visible to everyone. We’ve been leaning into that at Nordhealth for the past year, and I’d like to explore why I think it’s a very good idea.

Here’s what we’re going to cover:

• Why the solution isn’t more management to coordinate, it’s more individual contributors with power.
• How named ownership works as a practice, and a look at companies that have already been doing this for a long time.
• How to decide which person to name, what they are responsible for, and what leadership needs to empower them to do.
• A weekly rhythm we use that you can use to help implement your own DRI culture.
• A small audit you can run this week to see how far you are away from the above.

If you’d like to dig deeper, here are some complementary articles from the archive:

• Nobody needs a human router covers the changing role of management from the angle of communication.
• Less envelopes, more letters makes the case for managers who contribute directly, rather than focus on the work around the work.
• Being in the details is an older article showing how the managerial job is changing.

Let’s get going.

The new weird world of engineering management

A lot has changed in the world of the engineering manager.

The Great Flattening has compressed the org chart, while AI and collaborative tooling have absorbed a large slice of the translation and coordination work that used to be a core part of the role. Although the severity of this change varies between organisations, the direction is fairly clear: we are in a world with ever-fewer management positions. Therefore, with fewer people to spread accountability across, individual contributors are also taking on more of this responsibility themselves.

In better economic times, roles were far less overlapping. Teams did fewer projects with more people per project. Engineering managers had reasonable numbers of direct reports. Now, managers are expected to be hands-on, and teams are typically running many projects concurrently, with AI helping individual contributors do more. It’s all gotten a bit blurry.

Previously, when every project had a product manager, an engineering manager, a tech lead, and a designer all working on clear pieces, the collaborative nature of the work meant that it was easier to see when something was slipping or getting blocked, and multiple humans would work together to remedy this.

But now, in an increasingly agent-based, solo-owner way of working, projects, and the people that are doing them, are becoming isolated. AI can generate status updates from tickets, but that can make it harder to read between the lines. Add individual contributors who aren’t experienced at operating at this level before, and all of your projects can begin to drift off track without a close watch being given to them.

So, what can we do to restore some control, whilst also empowering those that are doing the work to get stuff done?

Projects belong to people, not teams

The solution is for every project to belong to one individual contributor, instead of attaching the work to the team or the manager above it. The Fizzbuzz team no longer owns the four projects they are running. Instead, the owners are Alice, Bob, Charlie and Donna.

Some of the earlier references to this practice from Jobs-era Apple, where they used to ensure action item was recorded next to the name of one Directly Responsible Individual (DRI). That person is responsible for getting something done, even if it requires a team of 100 to do so.

Amazon followed a similar direction. In Working Backwards, Colin Bryar and Bill Carr described how the two-pizza team rule wasn’t enough to ensure success. It also required a named leader in order to guarantee that whichever initiatives or projects the team was doing actually got done.

In Amazon vocabulary, this was called the “Single-Threaded Leader”, the most senior person assigned full-time to one initiative, with no competing responsibilities. That person was accountable for delivery end to end. The model also nested, with smaller single-threaded teams or people owning sub-projects.

As Dave Limp, Amazon’s SVP of Devices, famously put it, “The best way to fail at inventing something is by making it somebody’s part-time job.” Eagle-eyed readers will remember last month’s article on focus.

Similarly, at Stripe, Gergely Orosz reported that “who wants to DRI that?” is used in meetings to assign immediate ownership, and that the DRI is always an engineer. That is the same approach we have been using recently at Nordhealth.

Having DRIs doesn’t fix coordination or guarantee the outcome; however it makes it 100% clear who is responsible for getting it done, and 100% easy to talk to that person directly to ensure things are going well and are moving in the right direction. Remember, nobody needs a human router.

ICs = DRIs

DRIs should always be the IC doing the work, not the engineering manager, tech lead, or most senior person above them. A DRI should have their hands on the keyboard and their head in the codebase. If you have to ask a question to your DRI about why search results come back in a certain order, your DRI should be able to show you the code and also change it if needed. It is that simple.

When all communication about a project has to pass through a manager, product manager, or designer, you waste cycles. A summary might be massaged in a way that makes it more pleasing to you, or relay your questions or feedback downwards in a form that loses fidelity. By the time the communication loop closes, every party typically leaves dissatisfied. Truth-seeking conversations begin by engaging with the person who has the answers, and that person is always the IC.

Stereotypical management practices like “shielding the team” are bugs that need fixed. Either leadership needs to get better at not being assholes or stupid (or both), or individuals need to be coached into becoming more rounded engineers that can take full ownership of what they are working on, and have ample communication flow from it.

So do engineers need to do more?

Essentially, yes. Having ICs be DRIs is an increase in the scope of what the job is. It means one person has to build the thing, communicate with senior stakeholders, and make the trade-off decisions that get it across the line. In a non-DRI model, the engineer usually handled the first while the engineering manager or product manager handled the other two.

Typically, a senior engineer should be able to take on a DRI role as it stands, albeit with a little practice. A more junior engineer will need coaching to grow into it. If you are going to implement this, it helps to bake the DRI responsibility into your levelling framework with clear responsibilities so that, for example, senior engineers know what is expected of them when they do it.

Being a DRI on projects is a fantastic stretch opportunity for non-senior engineers who want growth opportunities, and I find that it allows progression up the IC ladder to have additional paths rather than just becoming a machine that inputs lots of tickets and outputs lots of code.

If you are switching to a DRI culture, you’ll need to go through an initial period where you help coach everyone through the change. For example, a common one is some DRIs don’t expose enough information for others to understand what’s going on. The solution here is to find those that are doing it best and share repeatedly, loudly, and widely what good looks like, encoding those practices into processes and templates if needed. With time, everyone will get better.

The additional communication required is often the demand engineers are least experienced with. Many engineers, even senior ones, have never had to write (or generally share) the meaning and impact of their work regularly, as their manager or product manager would do this for the team instead. Surfacing the good and the bad of what they’re doing in public is new for a lot of people, so help them with it, and always interact and support them whenever there is annoying news being shared, like projects slipping.

The path to senior engineer is steeper in an organisation that runs on DRIs. However, this is something that I personally am happy with. I believe that it is an increasingly core skill where more of the programming work is being done with AI.

Ensuring failure is celebrated

The DRI does the work, communicates about it in public, and is the decision maker too. Occasionally, stuff will go wrong, like in the opening of this article. Managers have to make sure that when it does, DRIs get the support they need to put it right and also are empowered to keep making bold decisions in the future.

Writing at Etsy about blameless post-mortems, John Allspaw warned that an engineer who expects a reprimand is “disincentivized to give the details necessary to get an understanding of the mechanism, pathology, and operation of the failure”. The same logic applies to a DRI who expects the next failure to end with their name on a naughty list. They will subsequently hide information in updates and quietly make conservative calls to stay out of the line of fire in the future, and the whole notion of empowered individuals disappears.

You have to protect people visibly when something goes wrong, often enough that everyone has seen it. If you always make a positive example out of failure, others will feel safe to be bold too.

Build a weekly rhythm

At Nordhealth, we have built a weekly rhythm around our DRI model.

• Every DRI posts a written update in Linear each week.
• Leadership reads every update.
• DRIs and leaders can book a standing Wednesday office hours slot with each other.

And that’s it.

Starting with the update: it doesn’t need to be elaborate; it needs to be accurate and consistent, and a good one covers:

• Current status, with dates and scope. On track, at risk, or off track, plus an explicit flag whenever the target date or the scope has moved since last time.
• Progress and what’s next. What has been done this week, and what the DRI is doing next in the coming week.
• Risks, blockers, and asks. What’s worrying them, what’s blocked, and what they need from others at this moment in time.
• A link to the work itself. A demo, a pull request, or a staging link, so the reader can look or use the real thing if possible.

AI can now draft much of this from the project state, so the writing takes less time. The important bit is that the DRI writes it and you read it.

Reading every update is essential. You see dates changing, scope creeping, and you learn how each DRI writes when things are fine versus when they aren’t.

We typically have about 30 projects running at any one time, and Linear nudges everyone to post on Friday, so I scan them from the feed throughout the day. Reading the lot takes somewhere between half an hour and an hour, depending on how much detail people have gone into. I find that at any one time there are four to six projects we want to be very close to, which is where the weekly office hours come in.

These generate pulls and pushes. A pull is where leadership want to know more, and a push is where a DRI needs explicit help.

I typically contact (“pull”) the DRI if I see any of the following things:

• A project is blocked for reasons outside of their control
• I don’t understand the content of their update (this is a good coaching moment)
• I disagree with something (e.g. direction, technical decision, etc.)

A “push” is where the DRI actively contacts leadership.

In order to make this easier, we have Wednesday office hours: bookable slots all day with myself, our product VP, and the CEO. We encourage DRIs to come to us with anything, no matter how small. Booking a slot doesn’t mean that something has gone wrong. It could be anything from:

• Working through a two-way door decision
• Looking at different designs and trying to choose one
• Helping decide which scope is in or out of the project
• Showing us a demo to get feedback
• Or just having a chat.

We don’t require any special ceremony or pre-reads, but they’re encouraged if they help the meeting go well.

Ideally, leaders should book meetings with their DRIs as readily as DRIs book them in return. The model should be a trusted two-way collaboration over time, rather than a one-directional summons. We keep most of our day free every single Wednesday so that we are available for our team.

We’ve found that when we started the DRI model there were lots of big interventions as many snags in projects worked their way to the surface. Over time, and with more direct communication between leaders and DRIs, there is little left hiding.

Your turn

Pick three projects going on in your team or department. For each one, answer these questions:

Who is the DRI? Can you say a name, or are you saying “the team”? If it is the team, you might want to consider having a DRI instead.

Is it the right person? If you currently have named individuals assigned to projects, are they actually the right person to be a DRI? Could they show you the code if you have a question, or would they need to go and ask other people and get back to you?

Are you encouraging a DRI culture? Look at the last time something went sideways. Did the post-mortem produce a fix to the system, or did it leave people feeling exposed? Think about how you can celebrate failure more so that bold DRIs can make big progress on your product.

Do you have a rhythm? If not, could you put one into place?

Wrapping up

The idea behind DRIs is simple. Name the IC closest to the work, back them when things go wrong, and be super close to everything that is going on in their projects.

Imagine what it would be like if your whole team or department was full of engineers who could be DRIs. It’s worth trying to get there.

Until next time.

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.