Disclaimer: no, this post has nothing in common with the Deutsche Demokratische Republik, but I’ve found the coincidence of acronyms hilarious, so I couldn’t resist the reference in the header image. So don’t worry, no commies were harmed in the making of this article.

Amazon ain’t perfect - they have their own plethora of flaws and organizational plagues, but when it comes to operational efficiency, they are world-class. They have a truly data-driven culture, the scale (of data), the discipline (based on objective mechanisms) of execution, and the ruthlessness of an organization that doesn’t think twice to replace its sub-optimal “cogs”. That helps them identify and fix systemic errors and continuously (re-) transform themselves - it’s a unique organizational ability, beyond the reach of many.

Why do I mention that? Some lessons they’ve obtained and share may be very valuable for everyone else (with a proper dose of critical thinking applied). We’ve all heard about their flywheels, working backwards, bar raisers, single-threaded leaders, etc. Some time ago (in summer 2025), their CTO, Werner Vogels, wrote a few short posts on something else that piqued my curiosity: Decision Deletion Rate (I’ll refer to it as DDR from now on).

Btw. this concept, as its name explicitly states, concerns decision-making. That seems to be a very popular theme at Amazon (1- & 2-way door decisions, tenets backing up decisions, “ownership” as the leadership principle no 2, etc.), not without a reason. Werner has brought it up in the context of Gen AI (how it can help), but my intention is to stay more generic (& less salesy ...).

What is DDR (specifically)?

Anyway, back to the topic - what is DDR?

DDR is how much you manage to reduce the number of high-judgment calls made by people. In order to maximize “just-doing” instead of never-endingly getting bogged down in a decision-making mode.

Why so? Because it’s the decision-making that slows us down. Decisions introduce an “intervention tax” - temporarily switching context, looking for a decisive body, collecting the context, bloating with communication (consulting, informing, investigating options, narrowing down the choice, ...), etc.

That is expensive (as it involves many people in different roles), time-consuming (even in passive mode, e.g., when waiting for feedback), and the more uncertainty it introduces (the scale of “change”), the more it depletes people's tolerance for change.

Needless to say, if you don’t have a proper decision-making framework, things get even more chaotic and exhausting - some decisions are ineffective (not adhered to), duplicated, re-iterated endlessly, etc. Waste, waste and even more waste.

Whose problem is that?

Just to be clear - this affects every level of abstraction/hierarchy in the organization.

  1. Overflow of decisions at higher (managerial) levels may indicate a lack of organizational focus, poorly defined (or nonexistent) processes, excessive micromanagement, an incorrect organizational structure, and so on.
  2. ... but lower level ("trenches") struggle with too many decisions as well, especially when:
    • There are issues with shared (across teams/groups) parts of the work: conventions, ground rules, work routines, white/black lists, guardrails.
    • There's no clear architecture vision - where are we heading? How do we imagine the TO-BE state of this system/component? How should this change fit the (organizational/engineering) strategy?

Here are some examples, to make it easier to relate to.

Managerial decisions that could be avoided:

  • “XYZ came and asked for a raise as he hadn’t had one for K years. What should I do?” (Remuneration updates should be a periodic process with clear general rules applicable to all.)
  • “ABC asked for a full week on vacation starting Nth of Foobember. Is it OK to let him go?” (Team members should agree on the vacation among themselves to guarantee adequate support coverage and secure existing commitments.)
  • “An idea for an urgent project ABC drops in - what can we do to sneak it in?” (The planning process should be flexible enough to allow both important and urgent work.)

IC decisions that are a waste of time:

  • “Which web framework should I use to set up this new API endpoint? Which deployment option should I pick? How to set up observability?” (these all should be >95% standardized & codified as ready-to-use templates)
  • “How do we set up pagination in our list views? What about filtering or sorting? Should this be an extension of the existing endpoint or a new one?” (conventions and standards should be documented and verifiable with spec-based tools)
  • “What should I work on next? How important is this bug when compared to my current work? What should I do to have this deployed today? Whose approval do I have to get for the production release?” (These are all basic concerns covered by modern development processes)

And to make sure we’re on the same page: I’m not saying (neither is Amazon/Werner) that the decisions shouldn't be made at all. The idea is to eliminate as much human decision-making as necessary (but not more!), where and when:

  • It does not add extra value (opportunity!) / make a positive difference (enhance/improve existing mechanisms).
  • It can be automated / replaced by a mechanism.
  • The scope of the decision can be reduced / limited (to reduce the decision cost).

Fall of the Berlin Wall

But the DDR isn’t just about looking backwards (eliminating the decisions we’re already making, unnecessarily). The true mastery of DDR is about something one level higher up:

DDR is organizational efficiency in NOT LETTING more and more decisions be added as the organization grows, products get developed, business expands, etc.

This is a golden recipe for effective scaling: proactively & deliberately build your work environment (& its products) so the number of daily decisions doesn't grow (even linear growth in relation to scale of your business is probably not acceptable).

OK, easier said than done. What can we (& our organizations) do to actually reduce the number of decisions made? Fortunately, there are many tools to help with that:

  1. principles and tenets (so the decisions that are backed up with them are no-brainers for everyone)
  2. strategies (because they should come with their own leading principles/tenets)
  3. templates & samples (to copy from/reference instead of re-inventing things)
  4. automation (to embed decision in the mechanism & reduce cognitive load), e.g., automated guardrails
  5. writing culture (to promote objective reasoning and transparent knowledge sharing)
  6. strong decision-related mental models (like aforementioned 1/2-way decisions or Colin Powell’s 40-70 rule)
  7. strong ownership culture with clear authority boundaries (decide for yourself and bear the full consequences of those decisions)
  8. omakase (use cookiecutter prescriptions that may not be perfect, but are definitely good enough)
  9. last but not least - Generative AI - that can make decisions for you, based on evergreen, up-to-date specs (like claude.md)

Bonus. How to calculate DDR?

There’s no “official” (or standardised) formula (yet). But here are a few options that come to mind:

  • Separately register the time spent in “decision-making mode” (DMM) - in tools like Harvest or Rize.
  • Categorize “decision-making” meetings & calculate the ratio of DMM to all meetings.
  • Add a dedicated “On hold until decision is made” status for your work items, calculate the passive time (in this status) & assess how it affects cycle/lead times.
  • Keep logs of decisions made (+ some basic metadata: decision identified timestamp, decision made timestamp, decision range/scope, decision type, decision maker, etc.), and track trends.
  • Make sure the decisions made end as tasks (work items) that people can report burnt time on - that may be tricky to maintain mid- and long-term.
  • Measure the number of escalations (but that may have many side effects)
Share this post