When Progress Depends on Intervention, It’s a Conditions Problem

There’s a pattern I see in capable teams that looks like a people problem, but usually isn’t.

Everyone is working. Everyone is smart. And somehow progress still depends on someone stepping in—again and again—to reset priorities, re-litigate decisions, translate what was “meant,” or stitch together work that should have held on its own.

When that becomes normal, the system defaults to personal heroics: more effort, more meetings, more escalation. It can feel like leadership. It can look like “high standards.” But it’s often a sign that conditions are under-designed.

In those situations, progress comes from condition design—change what’s shaping behavior, and outcomes shift.

The quiet cost of heroics

Heroics are seductive because they work in the moment. A leader jumps in. A strong operator patches the gap. A meeting gets scheduled. The immediate problem resolves.

But the deeper issue remains: the environment keeps forcing resets. Over time, this creates a fragile operating model—high dependence, low reliability. Performance becomes something you have to produce through effort, instead of something the system makes likely.

If you want performance to be more reliable, the question isn’t “How do we get people to try harder?” It’s: What is the system making easy, costly, and invisible?

A simple way to diagnose what’s driving the pattern

I use a practical lens with four domains. It’s not a framework you adopt; it’s a way to see what’s shaping outcomes.

1) Signals

What becomes visible early enough to act on?

Signals are the cues that tell people what matters and what’s happening before it turns into a fire. When signals are weak or noisy, teams learn too late. They compensate with meetings, status hunting, and last-minute intervention.

2) Meaning

Do we share the same definitions and interpretations?

Meaning is how a group decides “what this counts as,” “what good looks like,” and “what we’re actually doing.” When meaning is fragmented, the same words get used to describe different realities. Work reopens because people weren’t aligned in the first place—just adjacent.

3) Structure

Who owns what, and how do decisions actually get made?

Structure includes decision pathways, ownership boundaries, handoffs, and interfaces. When structure is unclear, everything escalates. Leaders become the glue. Teams slow down because they’re constantly negotiating basic questions the system should already answer.

4) Adaptation

How does the system learn and hold changes over time?

Adaptation is the feedback loop: what gets reviewed, what gets adjusted, and what sticks. Without it, even good changes fade. People revert to old patterns because the system doesn’t reinforce the new ones.

If you’re trying to diagnose a repeating reset pattern, start here: Which domain is forcing intervention right now? Not all four. The dominant one.

“First moves” that change conditions (without redesigning your whole org)

In a perfect world, teams could redesign the system end-to-end. In real organizations, the best work is usually a small number of condition changes that alter behavior quickly and reliably.

Here are examples of “first moves” by domain. These aren’t prescriptions; they’re what condition design looks like when you keep it practical.

If Signals are the constraint (you find out too late)

What it looks like: surprises, late escalations, status hunting, last-minute reshuffles.

 First moves:

• Define a leading indicator + threshold: “If a deliverable is at risk of slipping by >7 days, flag it within 24 hours—no waiting for the next meeting.”

• Create one visible dashboard/board: a single place where work status is updated asynchronously (owner + next milestone + risk flag).

• Set a standard early-warning question in weekly check-ins: “What is likely to surprise us in 2–3 weeks?”

  
  

If Meaning is the constraint (people use the same words differently)

What it looks like: misalignment disguised as agreement; “we decided” means different things; reopens happen because success criteria were fuzzy.

First moves:

• Write the decision in one sentence + success criteria: “We are doing X to achieve Y; we’ll know it worked when we see A/B/C.”

• Define ‘done’ for one recurring deliverable: list 3–5 observable criteria, not adjectives (“high quality,” “robust”).

• Force trade-offs to be explicit: “If this becomes Priority 1, what stops or slips?” (and document it).

  
  

If Structure is the constraint (ownership/decision pathways are unclear)

What it looks like: everything escalates; leaders become translators; decisions reopen because nobody had the authority (or the interface) to hold it.

First moves:

• Clarify decision rights for one recurring decision: “Owner decides after input; escalation only if X condition is met.”

• Define ownership at the interface: “Team A owns X through step 3; Team B owns from step 4; handoff happens when criteria 1–3 are true.”

• Create a decision log: one page that records decision, owner, date, criteria, and revisit trigger—so it doesn’t get relitigated weekly.

  
  

If Adaptation is the constraint (nothing sticks)

What it looks like: good ideas fade; changes don’t survive real pressure; the system reverts.

First moves:

• Install a 15-minute learning loop on a cadence: “What did we expect? What happened? What will we change next week?”

• Create a single “revisit trigger”: “We reopen this decision only if X metric moves by Y, or if assumption Z changes.”

• Assign mechanism ownership: not “own the project”—own the rule/cadence/decision pathway and keep it alive for 60 days.

  
  

Notice what’s missing: motivational speeches, personality models, and “let’s communicate better.” Those can help, but they rarely fix the underlying pattern when the system is under-designed.

Case Study:

A leadership team kept reopening the same priority decisions every week. The symptom looked like “alignment” issues, but the constraint was structural: nobody could tell what had been decided, by whom, or what would trigger a revisit. The first move was a one-page decision log and a clear revisit trigger. Within two cycles, the team stopped relitigating and meetings got shorter—not because anyone worked harder, but because the system could finally hold decisions.

The goal: reliable performance without constant intervention

When conditions improve, something changes in the room. People stop compensating. Decisions hold. Work stops reopening. Leaders get pulled in less—not because anyone became a better person, but because the system got better at carrying the load.

That’s what condition design is for.

If you’re an HRBP, talent leader, or executive who keeps seeing progress depend on intervention, the best next step isn’t another framework. It’s a clear diagnosis and one small condition change worth testing.

If you’d like, I offer a short Fit Check to identify the dominant constraint and the most practical first move.