The Wrong Mental Model

There’s a common framing: you do the hard work, and then you grow. Growth as outcome. Growth as reward for effort.

This model is wrong in an important way. It implies a direction — effort first, growth later — that doesn’t match how systems actually evolve. In practice, growth is what happens while the feedback loop is running. Stop the loop, and growth stops too, regardless of how much effort preceded it.

The distinction matters because it changes what you optimize for. If growth is a reward, you optimize for output. If growth is a loop, you optimize for the speed and quality of feedback.

What a Feedback Loop Actually Looks Like

A feedback loop has a specific structure: act, observe the result, adjust, repeat. The loop itself is the growth mechanism. Each cycle doesn’t just produce output — it refines the system’s ability to produce better output next time.

act → observe → adjust → act → observe → adjust → ...
         ↑                          ↑
    (learning happens here)    (compounding happens here)

This pattern shows up across scales:

In codebases: Ship a feature, watch how it’s used, refactor based on what you learned. The codebase grows not from the shipping, but from the feedback between shipping and refactoring. Without the observe-and-adjust steps, you get feature accumulation — which looks like growth but behaves like debt.

In organizations: Small teams move fast because the feedback loop is tight. Everyone sees the result of everyone else’s work. Context is implicit and shared. As headcount increases, this loop stretches. Decisions take longer to propagate. Results take longer to observe. The loop slows, and growth stalls — often despite more people doing more work.

In personal systems: A new tool or process feels productive on day one. Whether it actually compounds depends on whether you ever circle back to evaluate it. The workspace that grows useful over time is the one with a feedback mechanism — some way of surfacing what’s stale, what’s working, what needs pruning.

The Decay Mode

Loops don’t just compound. They also decay.

A codebase without test feedback accumulates bugs silently. An organization without retrospectives repeats the same coordination failures. A personal system without staleness detection fills with half-finished work that never delivers value.

The decay mode is subtle because the system still feels busy. Work is happening. Effort is being expended. But without the observation step, the system is running open-loop — producing output with no mechanism to correct course.

Open-loop systems grow in size. Closed-loop systems grow in capability. The difference is whether the system can observe itself.

What Breaks the Loop

Three common failure modes:

The observation gap. The system produces results but nobody looks at them. CI runs but nobody reads the output. Features ship but nobody checks usage metrics. Dashboards exist but surface the wrong things. The loop is structurally present but functionally broken.

The adjustment bottleneck. Feedback arrives but can’t be acted on. The insight exists — this process is slow, this API is confusing, this team is blocked — but the cost of adjustment exceeds the available slack. This often manifests as work that queues behind a single owner or decision-maker. The loop runs, but at a frequency too low to compound.

The implicit-to-explicit transition failure. Early-stage systems rely on implicit feedback — you notice things because the system is small enough to hold in your head. As the system grows, implicit observation degrades. Context leaks. Tabs multiply. You start “remembering that you once knew” instead of knowing. If the system doesn’t externalize its feedback mechanisms before implicit observation breaks down, it enters a period of silent decay. (This dynamic appears even in individual workspaces — it doesn’t require organizational scale to bite.)

The Structural Insight

Growth compounds when the loop is fast and the observation is honest.

“Fast” means low latency between action and feedback. Tests that run in seconds teach more than tests that run in minutes. Deploys that ship in hours teach more than deploys that ship in weeks. Not because faster is inherently better, but because shorter loops mean more cycles, and more cycles mean more opportunities to adjust.

“Honest” means the feedback reflects reality, not comfort. A dashboard that only shows green metrics isn’t providing feedback — it’s providing reassurance. The structural entropy in a codebase doesn’t surface in velocity metrics. The relationship debt from forgotten promises doesn’t appear in Jira.

The systems that grow well tend to have explicit mechanisms for surfacing uncomfortable truths: stale branches, unanswered commitments, processes that exist because “we’ve always done it that way.” Not because uncomfortable truths are inherently valuable, but because they’re the inputs the feedback loop needs to adjust.

Implications

If growth is a feedback loop:

  • Adding effort without adding feedback is waste. More code without better tests. More people without better communication. More tools without evaluating the ones you have.
  • The most valuable investment is often in observation. Making the implicit explicit. Instrumenting what was previously invisible. Building the thing that tells you what’s working.
  • “Start simple” isn’t just pragmatism — it’s loop optimization. A minimal system with tight feedback will outgrow a complex system with loose feedback, given enough cycles.

None of this is new. But the framing shifts where attention goes. Instead of asking “how do I grow?” the question becomes “where is my feedback loop broken?” — which tends to have more actionable answers.

Written with AI assistance and human editing.