Ineffective Iterations

Part of

Dynamic Work Modes

Key Points

Ambiguous work organized serially through email. Leads to slow, expensive feedback loops and constant back-and-forth.

The Problem: No direct collaboration, feedback loops run asynchronously (mostly email).

The Solution: Recognize ambiguous work → shift it to Studio Mode.

Details

Ineffective Iterations is an anti-pattern that occurs when ambiguous, uncertain work is organized like Factory Mode – serially, without direct collaboration. This leads to slow, expensive feedback loops.

How Does Ineffective Iteration Emerge?

Typical Scenario:

Complex request comes in (e.g., new product request, design problem)
Person A processes their part
Hands off to Person B
Person B sees problem → writes email to Person A
Person A responds after delay
Person B has new questions → email again
Loops go back and forth multiple times
At the end: Weeks for something that could have been clarified in 1-2 hours

Symptoms of Ineffective Iteration

Endless email chains without resolution
Multiple feedback loops of the same task
High wait times between steps
Quality suffers, still "not right"
Participants feel frustrated and misunderstood
Work takes much longer than expected

Why Does This Happen?

For ambiguous work, asynchronous communication is ineffective:

Email/text are less precise than face-to-face
Misunderstandings multiply over several rounds
Context switching costs time (who still cares about this?)
Feedback takes long, momentum is lost

The Paradox: You want to be "efficient" through serial work, but make it much less efficient.

Practical Examples

Mistake: Design Request Runs Through Ticketing System

Problem: Designer and requester don't speak directly
Multiple rounds: "What do you mean by...?" → email ping-pong
Solution: Studio Mode: Direct meeting designer+requester, clarify in 30 min

Mistake: Procurement with Ambiguous Orders via Email Exchange

Problem: New, complex requests handled serially
Feedback loops: "Can you give more details?" x5
Solution: Studio Mode: Daily team meeting for complex cases

Mistake: Software Development with Waterfall for Uncertain Requirements

Problem: Requirements phase takes months, still unclear
Feedback loops: After development, requirement was wrong
Solution: Studio Mode: Agile with frequent customer checks

The Solution: Quickly Switch to Collaboration

Recognition Signs for Ambiguous Work:

Does the task keep coming back?
Many "one more question..."-messages?
People saying "I didn't understand it that way"?
Are there multiple possible interpretations?
Impossible beforehand to know exactly what needs to be done?

If yes → Studio Mode!

Practical Measures:

Recognize ambiguous requests early
Put involved people directly together (synchronous, face-to-face if possible)
Clarify in one meeting what would otherwise take 5 email rounds
Document the result
Back to Factory Mode for implementation

Ineffective Iterations in Dynamic Work Design

Ineffective Iterations is the opposite of good Dynamic Work Design. It occurs when you don't properly distinguish between well-defined and ambiguous tasks.

Better: Shift ambiguous work immediately to Studio Mode, not sequentially plan it.

This pattern is one of the two "poles" of the Axis of Frustration (the other pole being Wasted Attention).

Common Mistakes

Using waterfall for uncertain projects
Processing complex requests without direct exchange
"We'll clarify that later" → leads to rework
Asynchronous communication for ambiguous problems

Better: Quickly switch to synchronous collaboration

More about this

Dynamic Work Design was developed by Nelson P. Repenning and Donald C. Kieffer at MIT Sloan. Start with the foundational article "A New Approach to Designing Work" (2018) and watch "Unlock Your Organization's Full Potential with Dynamic Work Design" by Don Kieffer to see practical applications.