The Engineering Manager

A little over a year ago, I wrote an article called Going direct. This reflected a cultural change in management style that had happened over the last few years, where everyone should be encouraged to communicate openly to anybody and everybody without passing messages through the management chain.

However, making decisions is still important enough to have some process in place that can utilise the management chain for ensuring that they happen effectively, especially when people and teams disagree.

In that article, I mentioned that formal escalation is still the right move when there are one-way door decisions, which are choices that are difficult to reverse or that carry significant risk if they go wrong. I wanted to expand upon that concept in this article in order to do it justice: it deserves it!

Having your team be able to distinguish between one-way doors and two-way doors can dramatically increase the velocity of your team and also prevent them from making mistakes. This language was popularised by Jeff Bezos, and it can explain why some teams are able to move so quickly without breaking the things that matter, whilst other, more bureaucratic teams grind to a halt waiting for several layers of sign-off.

In this article, we’ll cover the framework, existing failure modes, and the hidden gotchas, and work towards having your teams understand it in everything that they do.

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

• Going direct was the article where I first mentioned one-way doors.
• One bottleneck at a time mentioned that slow leadership sign-off on decisions can become an organisation’s bottleneck.
• Slow down to speed up argued that some work needs deliberate slowness, and the skill is knowing which.
• Invert, always invert explores thinking through failure modes before committing.

Okay, let’s do it.

The origins of the framework

Although I’m sure that the idea has been around for far, far longer, the popularisation of the framework in the tech world was through Jeff Bezos.

In his 2015 letter to Amazon shareholders, he described two types of decisions. Type 1 decisions are consequential and irreversible. These are one-way doors, and once you walk through them you can’t go back, so they should be made slowly and carefully with consultation. On the other hand, Type 2 decisions are changeable and reversible; they are two-way doors that can be made at speed by individuals or small groups.

Engineering life is full of both. Choosing your primary database, committing to a public API, signing a multi-year vendor contract, or deleting customer data are one-way doors that should be considered very carefully. On the other hand, changing your release cadence, enabling a feature flag, or changing the colour of a button in your UI are two-way doors where the cost of being wrong is negligible, and the change is easy to reverse.

Bezos’s successor, Andy Jassy, revisited the idea in his 2021 shareholder letter, writing that moving fast requires, among other things, “allowing teams to make two-way door decisions themselves”. The key idea here is that you want to push two-way door decisions as far down the org chart as possible, which frees up leadership time to ensure that one-way door decisions are being made correctly.

Failure mode: one-way dooring everything

The interesting warning in Bezos’s writing wasn’t that companies make these one-way door decisions badly, but instead that, as they grew, they would treat far too many decisions as one-way doors and therefore grind to a halt. In reality, most of these decisions are two-way doors and could be made very quickly by the people closest to the work. The result, in his words, is “slowness, unthoughtful risk aversion, failure to experiment sufficiently, and consequently diminished invention.”

If you’ve worked for a slow company, then you’ll recognise the symptoms here. For example: a team member wants to expense a $99 course that will upskill them so they can be more impactful, but it takes two months to sign off. A team wants to try a different way of tracking their work, but it requires approval from somebody high up who never gets back to them. A simple code change sits in a review queue for three weeks while reviewers bikeshed in an infinite loop around how exactly the code should look. None of these choices are particularly irreversible or important, yet each is treated with scrutiny and slowness as though it were.

When an environment is like this, with time, people stop proposing changes at all. That’s because when every decision is treated like a one-way door and requires consensus and scrutiny, it trains staff to wait for someone senior to decide rather than deciding for themselves. That clearly isn’t good for autonomy. I mentioned this permission culture in Going direct, and it rarely comes from an individual saying that it needs to be this way; instead, it comes from accumulated cultural precedent. People are scared to just get stuff done.

Interestingly, Warren Buffett (as so often seems to be the case) made the same observation in his 2009 letter, stating that he would “rather suffer the visible costs of a few bad decisions than incur the many invisible costs” of decisions made too slowly, or not at all, because of a stifling bureaucracy. When people are afraid to fail, they often don’t try risky or uncertain things, and that means that people are not living up to their potential, and nor is your company.

If you’re treating everything as a one-way door, then it will quickly mean that your company’s bottleneck will become decision speed. I wrote about this in One bottleneck at a time. The solution is to ensure people understand that they can make two-way door decisions at will and that anything escalated to leadership gets an answer within a tight turnaround, such as 24 hours. Leadership should hold themselves accountable to that.

One-way doors masquerading as two-way doors

I found that sometimes even experienced teams can be caught off guard by decisions that feel like two-way doors but, in fact, are not. They show up in subtle ways, such as assuming that a commitment that you’ve made to a customer can just be moved, or perhaps that the data model that you’ve initially gone with can be changed in the future in a non-breaking way (when, in fact, it cannot). These are the places where you need to be really careful.

These situations can be hard to solve because the risk is in what you didn’t think about, rather than what you did. Also, the reversibility of a decision may depend entirely on where you’re standing in the organisation. A decision could be two-way for your team but actually one-way for the organisation. For example, your team could change what they’re working on, but there could have been months of work in marketing that then goes to waste. Or perhaps you build something into the codebase but then decide to delete it later, only to find that other teams have already built on top of it. The question to ask yourself is not just about whether a door can be reversed, but what the side-effects could be, and who would have to do the reversing.

The word “reversible” therefore needs more scrutiny. Code can be reverted with a commit, but an API has users once it becomes public. You should always look at the cost of walking back through the door in practice, not just whether it can be reversed technically. A good method to use here is one that we’ve written about before, which is inversion. Think about what the worst thing is that could go wrong if you were to reverse this particular decision.

You could argue that one-way doors that masquerade as two-way doors are some of the most costly decisions to get wrong because the decision is made quickly and confidently with no consensus, but the permanence of that decision is discovered later, usually the hard way.

Learning to classify

The skill to build, therefore, in yourself and in your team, is learning to classify between one-way doors and two-way doors. For any decision that you need to make that could be of some consequence, ask what happens if you get it wrong and need to reverse it.

When answering this question, if there is no consequence or a consequence that can be stopped, then you’re likely dealing with a two-way door, and the decision should be made quickly by the people closest to the work. If the answer is irreversible, incurs significant cost, or has any kind of permanent side effect, then it’s a one-way door, and it deserves deliberate, careful treatment. I described one useful “pre-mortem” technique previously in Slow down to speed up: what are the absolute worst scenarios that could happen if we did this?

It’s also possible for two-way doors to get even faster. In his 2016 letter, Bezos noted that most decisions should be made with around 70% of the information that you need, because waiting for 90% is usually slower than deciding and then iterating if you need to. The skill to train is getting good at noticing and reversing bad calls quickly, because then being wrong costs far less than being slow.

Rolling this out to an organisation is all about empowerment. You, as the leader of the team or the organisation, need to publish guidelines about what one-way and two-way doors are, including clear examples of each and who, in each case, makes the decision. You can also use this opportunity to teach teams to create decision logs, which are an incredibly useful artefact for recording what you’ve decided over time so that you can always go back and look in the future. This isn’t just talking about architecture decision records, but even decisions about which cohorts of customers are going to get a feature first, or a priority call that’s been made about the team’s backlog. Getting in the habit of recording these in a central place can also build the muscle of treating each decision atomically.

Even if you find yourself in an organisation that hasn’t taught everybody how to use this framework, that doesn’t stop you using it for yourself and making it really clear about what you’re doing. For example, if you need a decision from your own leadership, then you can use the framework as you’re asking: “This is a two-way door, and here’s how we reverse the decision if it goes wrong. We recommend that we proceed on Friday unless you think we should stop and discuss instead.”

Building on this, if you are facing a lot of resistance about making a decision, then you can explicitly ask the other party exactly what the one-way door is that is preventing you from going faster. That can be a very productive way of challenging slowness because, quite often, it can cause the mindset of the person who is challenging you to change.

Your turn

As always, I like to leave you with a short exercise to try out this week.

• Find the last five decisions that your team made that you felt were consequential. Pull them from Slack threads, meeting notes, or review queues.
• Classify them as one-way or two-way doors. How many of each were there? How many of each do you think you have in general over a given month or quarter?
• Test each one for reversibility. Ask what would have happened if each had been wrong and needed reversing. Did you classify any of them incorrectly?

Wrapping up

If you want your organisation to move quickly, then you can remove decision bottlenecks by understanding the difference between one-way doors and two-way doors. One-way doors need careful consideration, and two-way doors need speed. The skill is knowing which is which and being able to apply that logic successfully again and again.

Although the model is simple, it’s surprising how much time people can spend bikeshedding over decisions that could be immediately reversed. Always ask yourself whether you’re dealing with a one-way door or a two-way door, and always ask the same of others if they’re slowing you down. Sometimes they might not be thinking clearly.

Until next time.

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.