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.