When Systems Become Self-Soothing

There's a particular kind of productivity that doesn't feel productive at all. It feels necessary. Urgent, even. Someone mentions a friction in the deploy pipeline, and within hours the team is evaluating three new tools. A retrospective surfaces a vague complaint about "context switching," and the response is a new Notion template, a revised standup format, and a Slack bot that nobody asked for.

The instinct is genuine. Something feels wrong, so you fix something. You optimize. You automate. You build a system around the discomfort until the discomfort has a process, a dashboard, and a recurring calendar event.

And for a while, it works — or at least it feels like it does. The motion itself is soothing. You're doing something. You're improving. You're in control.

But then the new tool needs configuration. The template needs documentation. The bot needs maintenance. And the original friction? It's still there, somewhere underneath the layers of solutions you've built on top of it.

"We weren't really solving the problem. We were managing our anxiety about the problem."

That sentence landed in one of my retrospectives a few years ago, and it hasn't left me since. Because once you notice the pattern, you start seeing it everywhere.

The optimization reflex

Engineers are builders by training and instinct. When something hurts, we reach for tools. When something is slow, we automate it. When something feels unclear, we add structure.

Most of the time, this instinct serves us well. It's how we reduce toil, improve reliability, and make systems more humane over time.

But there's a specific kind of optimization that isn't really about improvement. It's about relief. The goal isn't to make the system better — it's to make the discomfort go away. And those two things, which look identical from the outside, lead to very different places.

Relief-driven optimization tends to be reactive, often disproportionate, and surprisingly hard to stop. You can recognize it by its urgency — the feeling that we need to fix this now, before anyone has clearly articulated what "this" is. It often targets symptoms rather than causes. And it usually generates more work than it resolves.

This is the pattern I want to name: the optimization reflex — the impulse to build a system around discomfort instead of sitting with it long enough to understand it.

Pascal's quiet room

Blaise Pascal, writing in seventeenth-century France, put it more bluntly than most modern productivity authors ever will:

All of humanity's problems stem from man's inability to sit quietly in a room alone.

He wasn't talking about meditation or digital detox. He was describing something deeper — the way human beings flee from stillness because stillness forces us to face what we're actually feeling. Doubt. Uncertainty. The fear that maybe we're not doing the right thing, or doing enough, or doing it fast enough.

Pascal noticed that we don't run from discomfort by doing nothing — we run from it by doing more. We fill the space with activity, with plans, with systems, with motion that looks like purpose.

In engineering, that flight from stillness has a very specific shape: tooling, automation, process redesign, productivity frameworks. Not because these things are bad — they're often essential. But because they can also become the mechanism through which we avoid the harder question: what is the actual problem here, and does it require a system — or a conversation?

Pascal's insight isn't anti-productivity. It's anti-avoidance — not as a moral judgment, but as a practical discipline of pausing before you build. And the distinction matters.

The anxiety-to-automation pipeline

Once you start looking, the pattern shows up in predictable places.

A team misses a deadline, and the response is a new tracking system — not a conversation about whether the scope was realistic. A junior engineer makes a mistake in production, and the response is three new linting rules — not a review of whether the team's onboarding actually sets people up to succeed. Psychological safety erodes, and instead of addressing it directly, someone proposes a "culture survey tool."

The pipeline looks like this:

1. Discomfort surfaces — something feels wrong, slow, or fragile.

2. Diagnosis is skipped — the feeling itself is treated as sufficient evidence.

3. Optimization begins — a tool, process, or system is introduced to manage the symptom.

4. Short-term relief — the activity of building feels productive and calming.

5. Long-term drift — the root issue persists, now buried under a layer of infrastructure.

This isn't laziness or bad judgment. It's human. The discomfort is real, and building something in response is a natural way to reassert control — a version of what the previous post in this series called focusing on inputs. The problem is when the input you're choosing is the wrong one.

What optimization is hiding

Underneath the reflex, there's usually something simpler and harder to address:

• A disagreement that nobody wants to have.

• A decision that hasn't been made because making it would create conflict.

• A sense that the team is moving fast in a direction nobody fully believes in.

• A leader who is managing their own anxiety by adding structure for others.

These are human problems, not systems problems. And they don't respond well to automation. You can add all the Jira workflows you want — they won't resolve a breakdown in trust between Engineering and Product. You can build the most elegant CI pipeline in the world — it won't fix the fact that your team doesn't feel safe to examine their own assumptions.

The cost of the optimization reflex isn't just wasted effort. It's misdirection. It gives the team the feeling that something is being done, while the actual source of friction stays untouched. And over time, the layers of compensatory systems make the real problem harder to find and harder to name.

A practical tool: the Stillness Check

Before reaching for a new tool, process, or system, run through five quiet questions. Not as a formal ceremony — more as a habit of pausing before the reflex kicks in.

1. What is the discomfort here — and when did it start? Trace it back. Was there a specific moment, or has it been accumulating?

2. Am I trying to improve the system, or manage my own anxiety about the system? Be honest. Both are valid — but they lead to different actions.

3. Could a conversation address this faster than a tool? If the answer is yes, start there. Tools can come later.

4. What would happen if we did nothing for one week? Sometimes the discomfort resolves itself. Sometimes it clarifies into something specific. Both are useful.

5. Is this optimization solving the cause, or protecting us from the symptom? If it's the symptom, you'll be back here in three months with a different tool.

The point isn't to never optimize. It's to make the pause a part of the process — to let the stillness in before the building begins.

How this connects to the series

The first post in this series was about finitude — saying no to protect what matters. The second was about agency — focusing on the inputs you actually control. The third was about clarity — examining assumptions before committing to building.

This fourth lens is about stillness — the discipline of pausing when the impulse to optimize is loudest. Pascal would argue that the impulse itself is worth examining, because it often carries more information than the solution it's reaching for.

Together, these lenses form a cumulative practice: notice what you're saying yes to, control what you can, question what you're assuming, and — before you build the next system — sit with the discomfort long enough to understand what it's actually telling you.

Final thoughts

Pascal's quiet room isn't about doing less. It's about doing the right thing — which sometimes means waiting until you understand the problem before you build the solution.

The next time a retrospective ends with "we need a better tool for this," try pausing for just a moment. Ask what the tool would be solving. Ask whether the problem is a systems problem or a people problem. Ask whether the urge to optimize is coming from clarity — or from the quiet need to feel like you're making progress.

Not every discomfort needs a system. Sometimes the most productive thing you can do is sit in the room — the quiet one, with no dashboard and no automation — and listen to what the silence is actually telling you.