Working in Theory versus Working on Real Problems

Ask someone leading an agile transformation what they did this week. The answer is usually about the model: refining the framework, aligning the roles, consolidating the repositories, presenting to the steering committee. Almost never: “a team was blocked, I unblocked it.”

That answer tells you everything. There are two jobs in enterprise agile, and most people are doing the wrong one. Designing for hypothetical future teams is working in theory. Removing friction a real team hit on Tuesday is working on real problems. Only one of them improves delivery.

What working in theory looks like

The work is designing around guesses about the future. How teams think they ought to collaborate. How a risk might get caught. What a team formed next quarter would need. None of it is in contact with the actual work, and it doesn’t need to be, because the currency of theory work is coherence.

A theoretical solution is proven when it holds together. The model has no contradictions, the roles don’t overlap, the process covers the scenarios anyone could name in the meeting. Nobody checks it against what actually happens, because that’s not how the work is graded.

The other defining feature: the designers rarely have to live inside the systems they build. They present the plan, get it approved, and move on to the next one. If the process collapses in year two they’re on a different contract, and the design never hears anything back except a document review.

The insurance problem

Most of this process was never designed against a problem that happened. It’s designed just in case.

“Just in case” is risk insurance, paid in everyone else’s time. A gate to catch a failure mode nobody has observed. A form to survive an audit that hasn’t occurred. A sync meeting to align a team that doesn’t exist yet. Each addition feels responsible to the person adding it: what if we didn’t have this and something went wrong?

The trap is that a just-in-case process can’t be falsified. Nobody can prove the risk wouldn’t have materialized, so the process can never be shown to be waste, which means the system only ever grows.

Every item is rational for the designer and irrational for the organization. One more checkpoint costs the designer nothing and costs every future team a little, forever. Multiply across quarters of additions and the organization ends up heavier than any of its real problems require. Heavy organizations move slowly, and then the leaders wonder why. Ask why a process exists. “In case” is a complete answer in these places.

The coal mine that proved it

History already ran this experiment, and sociotechnical systems research was founded on the result.

In 1951, Eric Trist and Ken Bamforth published their study of what happened when British mines mechanized. The old hand-got method was technically primitive: a self-selected pair of miners, responsible for the whole task, digging coal however their judgment said to. The longwall method was modern: conveyor-fed mass production, seven specialized roles, a rigid three-shift cycle. On paper the longwall was unmistakably better. Bigger equipment, tighter division of labor, more coal per man-hour.

It performed worse. Output fell. And the way it fell apart is the tell. The social structure the hand-got method had supported didn’t survive the redesign. Workers were scattered along a hundreds-of-yards face, never seeing the whole job. The filling shift sat outside the cycle, isolated, unreliable, and resented. No one had authority matching their responsibility, so no one took responsibility. What Trist and Bamforth called group defences emerged: reactive individualism, mutual scapegoating between shifts, absenteeism that “compensated” for a job design that gave people nothing to be proud of. The social system didn’t adapt to the technical design. It absorbed the impact and passed the cost back as lost production.

The designers’ mistake was a theory error, not an engineering one. They’d designed the technical system in isolation, for an imagined worker with no social system, no judgment, and no reactions. The real miners were there the whole time, and the mine paid for the fiction.

The lesson generalizes to any operating model, process framework, or reorg designed the same way. Change the technical half in isolation and the social half doesn’t cooperate. It resists, quietly, in whatever currency it has: absenteeism then, shadow spreadsheets and ceremony-skipping now.

Design with people, not for people

“Work in theory” and “design for people” are the same failure. When the people doing the work aren’t in the room where the system is designed, everything the designers know about the work is a guess. They default to the imagined worker: compliant, interchangeable, unbothered. The design can’t help but come out looking like the mine.

Designing with people puts someone who does the real job inside the loop, to shape the design beforehand rather than approve it afterward. The difference shows up quickly. With-input designs arrive pre-loaded with the constraints reality keeps: who actually negotiates the dependency, where the quality really gets checked, which step everyone quietly skips and why. Theory designs stay clean because the questions that would dirty them never get asked.

There’s a second dividend. Teams don’t sabotage systems they helped design. The hand-got miners fought a system that took away their judgment, their group, and their pride, and offered them a slot in exchange. A process the team shaped has owners; a process imposed on them has only targets.

What working on real problems looks like

Real problems are concrete: a dependency that actually blocks delivery, a handoff that keeps dropping quality, a collaboration pattern that doesn’t survive two time zones, a bottleneck that moved when you found it. You can point at them. And they grade your solutions for you: did lead time improve, did throughput improve, did predictability improve.

Real problems push back. A wrong solution produces a visible bad outcome, quickly, to the person who made it, which is the whole difference from theory work. Reality gets the final word instead of a review board.

And because it was built against something real, a real fix carries its own expiry date. When the constraint changes, the fix gets dropped. Nobody files an SOP for a problem that no longer exists. The system stays lean because every piece of process is still paying rent against an active problem, with nobody running a cost-cutting program.

Two things worth taking away

1. Coherence is not evidence. A model that holds together on paper has passed the easiest test there is. The hard test is what happens when it meets a team on a Tuesday.
2. “Just in case” is why you’re heavy. Process added as insurance can never be proven wrong, so it can never be removed. Organizations don’t collapse under their weights because of one bad decision; they accumulate, one reasonable safeguard at a time.

Design against problems that exist, not scenarios you can imagine. The imaginary ones are unlimited, and every one you accommodate makes the real work slower.