Systems Essays on Federico J. Scariot

Software Is Not an Industry Problem

Sat, 17 Jan 2026 12:30:46 -0300

There is a persistent temptation to treat software development as an industrial activity.

The temptation is understandable. Industries promise predictability. They suggest that, given enough standardization, enough process, and enough enforcement of best practices, outcomes can be made reliable. Define the inputs clearly enough, constrain the process tightly enough, and you should get roughly the same results every time.

This logic works remarkably well when manufacturing physical objects.

It works far less well when building software.

The Myth of Stability

Fri, 30 Jan 2026 12:30:46 -0300

Stability is widely treated as an unquestioned good.

Organizations pursue it. Teams are rewarded for maintaining it. Processes are designed to protect it. Roadmaps, plans, and hierarchies are often justified in its name. Stability promises safety: fewer surprises, clearer expectations, and the sense that tomorrow will resemble today closely enough to be manageable.

Yet in environments shaped by change, this pursuit often produces the opposite of what it intends.

The problem is not that change exists. The problem is that many systems are built around the assumption that it should be exceptional.

Documentation Is a Living System

Sun, 08 Feb 2026 11:00:00 -0300

Documentation is rarely controversial in theory.

Most teams agree it is important. They acknowledge its value for onboarding, continuity, and shared understanding. Few people argue against documentation outright. The disagreement begins only when the work becomes real.

What tends to follow is a familiar pattern. Documentation is created early, often with good intentions. It reflects an initial understanding of the system, the domain, or the plan. Then the system changes. The documentation does not. Over time, it becomes incomplete, misleading, or quietly ignored.

Designing for Change Is Not the Same as Planning for It

Sun, 15 Feb 2026 11:00:00 -0300

“Design for change” and “plan for change” are often used as if they meant the same thing.

In practice, they rarely do.

The difference is easy to miss because both appeal to foresight, responsibility, and preparation. Both suggest maturity. Both imply that uncertainty has been acknowledged and accounted for. But they rest on very different assumptions about when knowledge becomes available—and what kind of knowledge it is.

This distinction matters because much of the friction that appears later in complex systems emerges precisely in places where change was anticipated, discussed, and explicitly planned for.

Free Thinking Has a Cost (And That’s Why It’s Rare)

Sun, 01 Mar 2026 11:00:00 -0300

Free thinking is widely admired in the abstract.

It is associated with creativity, insight, and long-term value. Organizations claim to want it. Leaders praise it. Cultures signal their openness to it. In theory, it is treated as a virtue—something to be encouraged and rewarded.

In practice, free thinking is often tolerated only within narrow boundaries. It is welcomed when it reinforces existing direction, and quietly resisted when it exposes trade-offs that complicate decisions already in motion.

The Moment a Decision Stops Being Cheap

Sat, 21 Mar 2026 18:00:00 -0300

Some decisions feel temporary when they are made. Few remain that way.

At the beginning of a project, most choices appear lightweight. A name, a structure, a boundary, a tool. If it proves inconvenient, it can be changed. The cost seems limited to the effort of revision. Nothing essential appears to depend on it yet.

Early decisions feel cheap not because they are trivial, but because the system around them is still thin. There are few dependencies, few expectations, and little coordination built on top of them. The surrounding structure has not yet adapted. Changing direction would require work, but not disruption.

When Documentation Outlives Understanding

Sat, 04 Apr 2026 00:00:00 -0300

On your first day inside a mature organization, you are often handed documents instead of explanations.

A shared drive. A knowledge base. A folder with reassuring density. “Everything you need is here.”

The volume signals competence. The structure signals order. The existence of so much written material suggests that difficult questions have already been asked and resolved. Each page implies that someone has taken the time to think carefully, to debate tradeoffs, to translate uncertainty into clarity — and to preserve that clarity so it does not have to be rediscovered.

When Alignment Suppresses Signal

Sat, 18 Apr 2026 00:00:00 -0300

Large organizations invest significant effort in alignment.

Teams align around plans. Leaders align around strategy. Organizations align priorities, messaging, and execution.

Alignment reduces friction and allows groups to move in the same direction without constant renegotiation. Without it, coordination slows and progress fragments.

In its early stages, alignment clarifies intent and allows decisions to propagate through a system. Disagreement still exists, but it appears as part of the work itself. Questions surface, assumptions are tested, and uncertainty remains visible.

When Workarounds Become the System

Sat, 02 May 2026 00:00:00 -0300

Most workarounds begin under pressure.

A dependency fails. A process blocks progress. Some system feature that normally works no longer does.

Something needs to move forward, and the system — as designed — does not accommodate the situation that has appeared. Waiting for a structural correction would delay the work. So someone introduces an adjustment.

A script gets added. Someone inserts a manual step. A rule is bypassed, or a component is forced into a state it was never designed to hold.

How Systems Protect Themselves From Correction

Sat, 16 May 2026 00:00:00 -0300

Healthy systems expect to be wrong.

Plans change, designs evolve, and assumptions fail.

Correction is not an interruption of the system’s work. It is part of the work itself.

Early in a project or organization, this is usually visible. Ideas are tested quickly. Decisions are revisited without much ceremony. A flawed approach can be replaced without much disruption because little has yet been built around it.

Correction feels inexpensive because the surrounding structure is still thin, and change affects only a small portion of the system.

Systems Grow by Accumulation

Fri, 29 May 2026 00:00:00 -0300

Mature systems often appear deliberately designed.

Their structures suggest intention: processes arranged in sequence, layers organized around recognizable boundaries, policies referencing one another with the quiet authority of precedent. From a distance, the system seems coherent, as if someone once stood back, surveyed the whole, and arranged its parts accordingly.

In practice, design is only part of the story.

Most complex structures emerge gradually. They take shape through a succession of small decisions made under local constraints — each reasonable at the moment it is made, each solving a problem that seemed immediate enough to justify action.

Coordination Becomes the Work

Sat, 13 Jun 2026 00:00:00 -0300

In the early stages of a system, most effort goes directly into production.

Features are built. Decisions are made quickly. Questions are answered in conversation rather than process. Work moves with relatively little coordination because the system around it is still thin.

People often remember this phase as unusually productive.

What tends to be remembered less clearly is why.

Small systems are not necessarily simpler because the work itself is easy. They are simpler because the number of active dependencies remains limited. Most participants can still maintain a reasonably complete mental model of the surrounding structure. Decisions propagate across short distances. Communication remains local. Adjustments can happen without requiring large-scale synchronization.

Systems Adapt Around Their Constraints

Sat, 04 Jul 2026 00:00:00 -0300

Most systems do not eliminate their constraints as quickly as they discover them.

A dependency is too expensive to replace. A process is too embedded to remove. A team is too central to bypass. A regulation, organizational habit, legacy boundary, or inherited structure imposes a limit that everyone can recognize, but nobody can immediately resolve. So the system adapts.

At first, this adaptation is practical. Work still needs to continue. The constraint may be real, but it cannot be allowed to stop everything around it. People adjust. Processes bend. Responsibilities shift. Expectations move. Coordination patterns emerge around the limitation. The constraint remains, but the system finds a way to keep moving.

Systems Respond to the Signals They Receive

Sat, 25 Jul 2026 00:00:00 -0300

Systems are often described as if they respond to reality.

A market shifts. A metric declines. A deadline slips. A customer complains. The system notices, adjusts, and continues.

From a distance, the relationship appears direct: something changes, the system detects it, and behavior follows.

But systems rarely respond to reality itself.

They respond to signals.

Reality must first become visible. It must appear somewhere: in a metric, a report, a dashboard, a complaint, an incident, a budget variance, a missed deadline, or a recurring escalation that someone has the authority to notice.