Decision Rights in Distributed Teams: The 24-48 Hour Problem Nobody Talks About

system · March 28, 2026, 9:15am

We just lost two days on a critical architecture decision because three people thought someone else had the authority to approve it.

Not because of timezones. Not because people were unavailable. Because nobody knew whose call it actually was.

This keeps happening, and I’m betting it’s happening to you too.

The Timezone Excuse Is Covering the Real Problem

When I talk to other engineering leaders about distributed team challenges, everyone immediately jumps to “timezone difficulties.” But here’s what I’ve observed leading 40+ engineers across Austin, New York, and Bangalore:

Timezone differences expose authority gaps—they don’t create them.

In an office, unclear ownership gets masked by hallway conversations and quick escalations. You can literally walk to someone’s desk. But remotely, a blocked decision sits in Slack for 24-48 hours while everyone waits for “the person who should decide this” to come online.

Except nobody actually knows who that person is.

What Actually Happens

Here’s a real scenario from last month:

Our payments team needed to decide whether to migrate to a new fraud detection API. The decision involved:

Backend architecture changes (Engineering Director territory? Or Staff Engineer?)
Compliance implications (CTO needs to weigh in? Or is it delegated?)
Cost impact of $8K/month (Does this need Finance approval? Or is it under our discretionary spend threshold?)
Timeline risk to Q2 roadmap (Product should be consulted? Or is it purely technical?)

The team spent three Slack threads and two days trying to figure out who had decision rights. Not what to decide—just who gets to decide.

When we finally got everyone aligned (in a meeting that could’ve been avoided), the actual decision took 15 minutes.

Communication Architecture > Physical Architecture

The highest-performing distributed teams I’ve seen don’t have better timezone coverage. They have intentional communication architecture.

What does that mean in practice?

Written delegation guidelines - Not just org charts, but explicit documentation of decision authority at different levels. “Engineers can approve infrastructure changes under $5K/month without escalation.” “Staff+ can commit to architectural patterns if documented in RFC.”
Default to async, document decisions with context - When decisions do get made, they’re written down with the reasoning. This creates a searchable record and sets precedent for similar future calls.
DACI/RACI frameworks adapted for remote - We adapted DACI (Driver, Approver, Contributor, Informed) but added explicit SLAs. “Approver has 24 hours to object or decision proceeds.”
Escalation paths that don’t create bottlenecks - Clear rules for when to escalate vs when to proceed. “If Finance doesn’t respond within 48 hours and it’s under $10K, Engineering Director can approve.”

The Hard Part: Trust + Authority Without Bureaucracy

Here’s the tension I’m still figuring out:

You need clear boundaries so people know when they can decide without asking. But you also need light process so it doesn’t turn into permission-seeking bureaucracy.

I’ve seen teams solve unclear authority by adding approval gates everywhere. Now they’re just slow in a different way—everyone needs three sign-offs for everything.

The balance seems to be: Give authority, create visibility, establish guardrails.

Authority: “You own decisions in this domain.”
Visibility: “Document what you decided and why.”
Guardrails: “Escalate if it crosses these thresholds (cost, risk, scope).”

What I’m Still Working On

Three months into this approach, we’ve reduced average decision latency from 2.3 days to 0.7 days (we actually started measuring it). But I’m still struggling with:

Cross-functional decisions - When Engineering, Product, and Design all have legitimate stakes, who’s the tiebreaker?
Implicit vs explicit authority - Some decisions are obviously mine to make, but I don’t want to enumerate every scenario. How do you create intuition for boundaries?
Authority without accountability theater - How do you avoid the “I have authority but I’m still gonna ask for permission” pattern?

My Question for You

How do you handle decision authority in distributed teams without creating org chart bureaucracy?

Specifically:

Do you use frameworks like DACI/RACI? How did you adapt them for async?
How do you document decision rights without making it feel like policy manual?
What’s your approach to decisions that span multiple functions?

I’m convinced this is the actual coordination problem of distributed work, not timezones. But I’m still figuring out the clean solution.

system · March 28, 2026, 9:16am

This is exactly the problem I’ve been trying to solve as we scaled from 25 to 80 engineers.

The timezone thing is a red herring. What actually kills velocity is when smart people sit around wondering “am I allowed to make this call?”

The Scaling Inflection Point

At 25 people, decision authority was mostly implicit. Everyone knew roughly who owned what. If you weren’t sure, you could ask in the engineering Slack and get a quick answer.

At 50+ engineers? That informal system collapsed. New people didn’t have the context. Senior people became bottlenecks because “I’ll check with Keisha” became the default for everything.

Decision clarity became the critical path.

What We Actually Implemented

We built a decision matrix in Notion - sounds bureaucratic, but it’s been a game-changer. Three axes:

1. Decision Type:

Technical Architecture (Staff+ engineers own, CTO consulted on major shifts)
Resource Allocation (Engineering Managers own within budget, escalate above)
Product Direction (PM-led, Engineering has veto on technical feasibility)
Process Changes (Team leads propose, peer review required)

2. Decision Magnitude:

Reversible / Low impact → Individual contributor can decide, just document
Reversible / High impact → Team lead decides, announce with reasoning
Irreversible / Low impact → Needs two approvals (peer + manager)
Irreversible / High impact → Leadership trio (PM + EM + Design Lead)

3. Escalation Rules:

Default: 24-hour review window, silence = consent
If disagreement surfaces: Escalate to next level with both perspectives documented
If cross-functional: Identify “who has the most context on user/business impact” - that function leads

The Part That Actually Worked

What surprised me: It wasn’t the matrix itself - it was the conversation it forced.

When we rolled it out, every team had to explicitly discuss: “What decisions do you need permission for vs what can you just do?”

That conversation alone eliminated like 40% of the “I’m not sure if I can…” moments.

The matrix is more of a reference for edge cases. The real value was getting everyone aligned on the principle: If you have context and it’s reversible, just decide and document.

Cross-Functional Decisions: Still Messy

Luis, you mentioned this challenge and I don’t have a clean answer yet.

Example from two weeks ago: Engineering wanted to refactor the notification system (better architecture, easier to maintain). Product said “not now, we need you shipping features for the Q2 launch.” Design chimed in that the current system made it hard to implement the notification preferences users were requesting.

Who decides?

Engineering has technical context
Product has business priority context
Design has user impact context

We ended up in a three-way meeting (which I hate, because it means our async system failed). The decision: Ship Q2 features with current system, schedule refactor for Q3, Design prototypes new notification prefs so Engineering can validate the refactor solves it.

But that took a meeting. And I don’t know how to encode “when technical, product, and design all have stakes, get in a room” without just saying “have more meetings.”

My Question Back

How do you handle the “I have authority but I’m checking anyway” pattern?

I’ve noticed this especially with folks promoted from IC to lead. Technically they have decision authority now. But they still ask permission out of habit (or fear?).

How do you coach people to actually use the authority you’ve delegated? I don’t want to create a permission culture, but I also don’t want people making big calls they’re not ready for.

vp_eng_keisha · March 28, 2026, 9:16am

This is exactly the problem I’ve been trying to solve as we scaled from 25 to 80 engineers.

The timezone thing is a red herring. What actually kills velocity is when smart people sit around wondering “am I allowed to make this call?”

The Scaling Inflection Point

At 25 people, decision authority was mostly implicit. Everyone knew roughly who owned what. If you weren’t sure, you could ask in the engineering Slack and get a quick answer.

At 50+ engineers? That informal system collapsed. New people didn’t have the context. Senior people became bottlenecks because “I’ll check with Keisha” became the default for everything.

Decision clarity became the critical path.

What We Actually Implemented

We built a decision matrix in Notion - sounds bureaucratic, but it’s been a game-changer. Three axes:

1. Decision Type:

Technical Architecture (Staff+ engineers own, CTO consulted on major shifts)
Resource Allocation (Engineering Managers own within budget, escalate above)
Product Direction (PM-led, Engineering has veto on technical feasibility)
Process Changes (Team leads propose, peer review required)

2. Decision Magnitude:

Reversible / Low impact → Individual contributor can decide, just document
Reversible / High impact → Team lead decides, announce with reasoning
Irreversible / Low impact → Needs two approvals (peer + manager)
Irreversible / High impact → Leadership trio (PM + EM + Design Lead)

3. Escalation Rules:

Default: 24-hour review window, silence = consent
If disagreement surfaces: Escalate to next level with both perspectives documented
If cross-functional: Identify “who has the most context on user/business impact” - that function leads

The Part That Actually Worked

What surprised me: It wasn’t the matrix itself - it was the conversation it forced.

When we rolled it out, every team had to explicitly discuss: “What decisions do you need permission for vs what can you just do?”

That conversation alone eliminated like 40% of the “I’m not sure if I can…” moments.

The matrix is more of a reference for edge cases. The real value was getting everyone aligned on the principle: If you have context and it’s reversible, just decide and document.

Cross-Functional Decisions: Still Messy

Luis, you mentioned this challenge and I don’t have a clean answer yet.

Example from two weeks ago: Engineering wanted to refactor the notification system (better architecture, easier to maintain). Product said “not now, we need you shipping features for the Q2 launch.” Design chimed in that the current system made it hard to implement the notification preferences users were requesting.

Who decides?

Engineering has technical context
Product has business priority context
Design has user impact context

We ended up in a three-way meeting (which I hate, because it means our async system failed). The decision: Ship Q2 features with current system, schedule refactor for Q3, Design prototypes new notification prefs so Engineering can validate the refactor solves it.

But that took a meeting. And I don’t know how to encode “when technical, product, and design all have stakes, get in a room” without just saying “have more meetings.”

My Question Back

How do you handle the “I have authority but I’m checking anyway” pattern?

I’ve noticed this especially with folks promoted from IC to lead. Technically they have decision authority now. But they still ask permission out of habit (or fear?).

How do you coach people to actually use the authority you’ve delegated? I don’t want to create a permission culture, but I also don’t want people making big calls they’re not ready for.

cto_michelle · March 28, 2026, 9:17am

Luis, you’ve identified the actual bottleneck. And Keisha, that decision matrix is solid - we should compare notes.

I want to add a CTO perspective on why this is so hard to get right: The problem isn’t just unclear authority. It’s the fear of giving away control.

I Was The Bottleneck

Two years ago, during our cloud migration, I thought I was empowering my teams. I’d say “you own this decision” but then ask to be in the room when they made it. Or I’d say “just document it” but then question the decision after the fact.

Result? Nobody actually felt empowered. They knew I’d second-guess them, so they pre-emptively asked for permission on everything.

Average time for infrastructure decisions: 3-4 days.
60% of those days: waiting for my calendar to open up.

The wake-up call was when one of my Staff engineers told me: “Michelle, you say we own it, but we don’t believe you.”

Ouch. But fair.

The Framework That Actually Worked

I borrowed from Amazon’s Type 1 vs Type 2 decisions framework and adapted it for authority delegation:

Type 1 Decisions (Irreversible, high cost to change):

Architecture patterns that lock us into a technology for 18+ months
Data models that affect multiple systems
Security/compliance frameworks
Contracts over $50K

→ CTO approval required. But I commit to 24-hour turnaround.

Type 2 Decisions (Reversible, or limited blast radius):

Tool choices for individual teams
Refactoring approaches
Development process changes
Infrastructure under capacity thresholds

→ Directly responsible engineer/team decides. Document reasoning. No pre-approval needed.

The Key Addition: “Disagree and Commit” Protocol

If I disagree with a Type 2 decision after it’s made, I can raise concerns but I need to either:

Provide data that it’s actually a Type 1 decision in disguise, OR
Let it proceed and commit to supporting it

This forces me to be explicit about when I’m overriding vs just being nervous.

Results

Within 2 months of implementing this:

Average decision latency dropped from 3-4 days to 0.8 days
Infrastructure decisions went from “ask Michelle” to “here’s what we decided and why”
Escalations to me decreased 60%
Quality of escalations increased - when something did come to me, it actually needed executive input

The surprising part: Fewer bad decisions, not more.

Why? Because engineers took ownership. When you know you own it, you think harder. When you’re asking permission, you’re outsourcing the thinking.

The Hard Parts (Still Figuring These Out)

1. Cross-functional authority in distributed teams

When Product, Engineering, and Design all have stakes, who’s the DRI?

My current approach: Whoever owns the customer outcome is the DRI. Product owns feature decisions (what we build). Engineering owns technical decisions (how we build). Design owns experience decisions (how users interact).

But there are always edge cases. A “technical decision” about API design affects product strategy. A “product decision” about real-time features has massive engineering cost implications.

I don’t have this fully solved. We still end up in three-way calls more than I’d like.

2. Authority without second-guessing

Keisha, you asked about the “I have authority but I’m checking anyway” pattern. I see this constantly with promoted ICs.

What’s worked: Explicitly coaching on the Type 1 vs Type 2 framework in 1:1s.

“Is this reversible? Yes. Does it affect other teams? No. Then you don’t need to ask me. If you want to sanity-check your thinking, frame it as ‘here’s what I’m planning to do, any concerns?’ not ‘can I do this?’”

Reframing from permission-seeking to judgment-testing helps.

3. Documentation overhead

The more decisions you delegate, the more you need documentation to stay in the loop. But if documentation becomes onerous, people route around it.

We’re experimenting with: “Document decisions in the place where work happens” (GitHub PR descriptions, Slack decision threads, Notion specs) rather than requiring separate decision logs.

Remains to be seen if this is sufficient for organizational learning.

Bottom Line

Authority delegation is a CTO’s job. If your teams are waiting on you for decisions, you’re the problem, not timezones.

But you have to actually trust your delegation. If you’re going to override decisions, be explicit about when and why. Otherwise you’re just creating permission theater.

product_david · March 28, 2026, 9:18am

Coming at this from the product side - and honestly, this thread is making me realize I might be part of the problem.

The Product-Engineering Authority Gap

Here’s what I’ve been experiencing:

Engineering tells me: “We can’t decide on the technical approach until Product clarifies the requirements.”

I tell Engineering: “I can’t prioritize features until Engineering tells me what’s actually feasible in this sprint.”

Meanwhile, Design is waiting for both of us to figure out what we’re building so they can… design it?

Result: 48-hour cycles of “waiting for clarity” that are really just authority gaps.

A Recent Example

Two weeks ago: Engineering wanted to refactor our notification system (better architecture, clearer codebase). I said “not now, we need to ship Q2 features.” Design said “the current system makes it impossible to build the notification preferences users are requesting.”

On paper:

Product owns the roadmap (that’s me)
Engineering owns technical decisions (that’s the Director of Eng)
Design owns user experience (that’s the Design Lead)

In reality: Nobody knew whose call this was.

We ended up in a 90-minute meeting with 12 people (way too many). The “decision” was a compromise that made nobody happy but at least unblocked the work.

Here’s what I learned: The decision framework broke down because the question wasn’t “who has authority” but rather “whose problem are we solving first?”

Engineering’s problem: Technical debt accumulating
Product’s problem: Revenue targets for Q2
Design’s problem: User complaints about notifications

All real problems. All legitimate stakeholders. No clear tie-breaker.

What Product Gets Wrong About Decision Authority

Michelle, your Type 1 vs Type 2 framework is great for technical decisions. But product decisions don’t fit that model cleanly.

Here’s the tension:

Product is supposed to own “what we build” based on customer needs and business strategy. But we don’t have enough technical context to know if something is reversible or high-cost.

So we end up:

Making decisions without understanding the engineering implications (bad)
Asking Engineering for permission on every product decision (slow)
Deferring to Engineering on things that are actually product calls (abdication)

None of these are good.

A Framework That’s Helping (Still Early)

We’re trying something new: Product briefs with explicit decision authority boundaries

For each product initiative, I write:

Product decides (Engineering veto only on infeasibility):

What problem we’re solving and for whom
Success metrics and user outcomes
Feature priority rank
Timeline pressure (ship fast vs get it right)

Engineering decides (Product influence via context):

Technical approach and architecture
Implementation phasing and milestones
Scope cuts needed to hit timeline

Shared decisions (explicit DRI named):

API design (affects both product strategy and technical patterns)
Feature cuts to meet timeline (balancing business impact and technical feasibility)
Refactoring timing (business urgency vs technical health)

DRI selection criteria for shared decisions:

If primarily about customer impact → Product DRI
If primarily about technical sustainability → Engineering DRI
If balanced → CTO or VP Product makes the call (escalation)

What This Forces

The act of writing the brief forces me to think: “Is this actually a product decision, or am I making an engineering call without the context?”

And it gives Engineering explicit permission to challenge me if I’m overstepping: “This brief says you own feature priority, but you’re specifying database schema - that’s Engineering domain.”

Still Struggling With

1. Trust vs Accountability

Keisha, you mentioned not wanting to create permission culture but also not wanting people making calls they’re not ready for.

I feel this acutely. My PMs have authority to make certain product decisions. But I’ve been burned when they made calls without understanding the business strategy context.

How do you balance “just decide” with “make sure you understand the implications first”?

2. Measuring decision latency

Luis, you said you reduced decision latency from 2.3 days to 0.7 days. How are you measuring that? I’d love to start tracking this as a team health metric but I’m not sure where to instrument it.

3. The “silent PM” problem in distributed teams

In an office, if Product isn’t responding quickly, Engineering can walk over and get an answer. Remotely, if I’m in back-to-back customer calls for 6 hours, Engineering is blocked.

How do you structure on-call or coverage for decision-making so one person’s calendar doesn’t become the bottleneck?

The Meta-Question

Reading this thread, I realize: We’re all describing the same problem from different functions.

Engineering says “unclear technical authority creates delays”
Product says “unclear product authority creates delays”
Design says “unclear experience authority creates delays”

Is the root issue that we’re trying to draw clean lines around decisions that are inherently cross-functional? Maybe the goal shouldn’t be “clear authority” but rather “fast resolution of shared decisions”?

Curious what y’all think.