Do Not Manage the Outcome. Design the Space in Which It Emerges.

By Maxim Perfiljev · Systems Architect

A company can create unnecessary work precisely because it has become very good at completing work. A leader can preserve a broken process by rescuing it. An expert can reduce a founder's agency by always supplying the next correct answer.

These are not arguments against speed, competence or help. They are arguments for changing the object of intervention.

For a long time, I treated the architectural method as the highest useful level of management: stop issuing individual instructions and build a system that produces the result repeatedly. Recently, after finally stepping away from work long enough to think, I began seeing another level. I call it the spatial method: designing the conditions under which different trajectories remain possible, without prescribing every action or selecting one final architecture in advance.

This is a working hypothesis drawn from my own observations. It is not a universal theorem, and the cases below are not controlled experiments. But the same mechanism appeared in three very different situations.

When faster delivery generates more requests

In a product-development loop, a customer has an idea. We implement it quickly, show the result, and the customer immediately has another idea. We implement that too. Another request arrives.

At the level of an individual task, everything looks excellent. Latency is low. The team is responsive. The customer sees progress. But at the level of the whole loop, faster fulfillment can increase the frequency of request generation. The organization accelerates the very process that creates more work for it.

Not every new request is waste. Customer learning is valuable. The problem is that the system does not distinguish valuable learning from an unbounded sequence of reactions to whatever became visible most recently.

One possible response is to redesign the backlog, slow development or add more approvals. In this case, the important intervention was narrower: separate the speed of engineering from the speed of customer exposure. Introduce distinct availability states: Internal, Beta and Stable. A feature being implemented no longer means it must immediately become visible to the customer.

That changes one boundary condition, not the whole development process. Engineers can still move quickly. The customer still receives useful releases. But the transition from a completed feature to a new external stimulus is no longer automatic.

The practical question becomes: which requests are produced by the way we expose results, rather than by a need that existed independently of our release rhythm?

When the strongest person hides the constraint

In another situation, several development teams depended on one another. A team committed to a delivery and missed the deadline. A strong participant built a temporary workaround. The chief executive saw a system that continued to move. The delay's consequences became difficult to see.

The workaround helped the current delivery. It also preserved a transition that made the next missed commitment easier to absorb: someone fails, someone capable quietly compensates, the organization experiences little visible consequence.

Calling this a discipline problem is incomplete. The system itself had made invisible compensation a normal way to resolve a missing dependency.

The intervention was to remove that automatic transition. The dependent step could begin when the dependency actually existed, rather than when someone had secretly replaced it. A gap was allowed to remain visible.

This did not force the chief executive into one decision. They could change priorities, allocate additional resources, reduce scope or cancel a commitment. The point was to restore explicit choice at the place where the constraint existed.

There is an important limit here. A visible gap is information, not permission to expose customers or colleagues to uncontrolled harm. A critical incident may require immediate compensation. But that compensation should be explicit, owned and recorded, rather than silently presented as normal operation. Observation without a review point or an escalation path becomes neglect.

The question is not whether anyone should ever help. It is whether help preserves knowledge of the underlying problem or erases it.

When there is no single correct answer

The third case concerned a capable founder in an accelerator. Much of their attention went into being a good participant: meeting deadlines, completing homework correctly, satisfying expert expectations and finding the ideal pitch structure.

Those tools were intended to help the founder build a company. They could also become the objective around which the founder organized their choices.

Here, the useful intervention was not another instruction about the correct way to be autonomous. It was removing some falsely absolute conditions. A deadline was not sacred in itself. Homework was a tool, not an obligation that defined success. An expert or tracker could be wrong. The four-minute pitch belonged to the founder. There was no single correct presentation template that guaranteed the right company.

This did not remove all constraints. Other people's time and resources do not wait indefinitely. Commitments still have consequences. What changed was the assumption that someone outside the founder already possessed the one correct trajectory.

There is an uncomfortable moment after that assumption disappears: then what should I do? The familiar response is to fill the space with a new answer. In this case, preserving the space for choice mattered more. I had previously described something similar as managed uncertainty. Now I see it as a change in the conditions through which agency can emerge.

Four different objects of management

The distinction becomes clearer if we separate four questions.

• Imperative: what action should happen next? “Do this.”
• Declarative: what result is required? “Reach this state.”
• Architectural: what system should produce the result repeatedly? “Build this transition structure.”
• Spatial: which trajectories should remain admissible? “Set the conditions within which choices and architectures can emerge.”

These levels are not a ladder on which instructions become obsolete. A production incident may require a direct instruction. A contractual delivery requires a clear result. A repeatable operation requires architecture. The spatial lens is useful when interventions at those levels keep recreating the problem.

In schematic notation, an imperative intervention selects an action u(t). A declarative intervention specifies a desired terminal set G. An architectural intervention shapes the transition rule F. A spatial intervention shapes a set Ω of trajectories that satisfy boundary conditions B.

The notation is a thinking aid, not a proof of optimality. The substantive question is: what conditions make useful trajectories easier, harmful trajectories harder, and meaningful choice still possible?

The feature-visibility gate changes which external transitions are available. Removing silent compensation changes how a failed dependency can be resolved. Removing a supposedly correct accelerator script changes who owns the next choice. Different settings; the same shift from selecting the move to changing the conditions of movement.

Complexity does not require equally complex intervention

The Mandelbrot set is a useful analogy. Starting with z₀ = 0, one repeatedly applies zₙ₊₁ = zₙ² + c. The set consists of parameter values c for which the orbit remains bounded. A simple rule and a boundary criterion produce a remarkably complex structure.

That does not prove anything about organizations. People are not complex numbers, and a company does not obey one deterministic recurrence. The analogy makes a narrower point: complexity in the emerging structure does not necessarily require equal complexity in the intervention.

A feature-availability condition can be binary, while its consequences travel through a large chain of customer requests, team priorities and management decisions. The leverage lies in the boundary's position in the loop, not in how elaborate the boundary looks.

Empty space is a state, not an absence of management

If several architectures remain possible, implementing one immediately removes some of the others. Sometimes that is exactly what progress requires. Sometimes a premature choice costs more than preserving uncertainty for a little longer.

Not building a workaround yet, not immediately implementing a new request, not supplying a founder's answer, or not exposing a completed feature can therefore be an active design decision.

The word “yet” matters. Useful empty space has a purpose, observable consequences and a point at which the decision is revisited. It is not an invitation to avoid responsibility indefinitely. It is also not a technique for creating uncertainty that other people cannot interpret. Boundaries should be understandable to the people affected by them.

I am interested in the difference between a pause that restores choice and a pause that merely transfers hidden costs to someone else.

Finding a market without selecting every customer in advance

The same lens changes how I think about market discovery. An imperative approach says: contact one hundred chief executives. A declarative approach says: acquire five customers. An architectural approach says: build a funnel that repeatedly acquires customers.

A spatial approach asks whether the problem is recognizable enough for a relevant person to identify themselves in it, before we fully prescribe the customer segment, sales trajectory or product shape.

For example: why does a faster company sometimes create more work for itself? Which processes exist only because someone constantly compensates for a malfunctioning system?

Publishing a clear question can create conditions for problem recognition. Reactions may then reveal where the mechanism matters, who pays for it, and what intervention is worth building. That is not a claim that a market has already been validated. This essay itself is an experiment in making the problem visible, not evidence of demand.

Value may come from work that stops being generated

I see three potential sources of value: unnecessary work that is no longer generated; errors that are no longer masked; management attention that is released from continuous compensation.

One can summarize this qualitatively as: avoided work + exposed errors + released management attention. It is not a financial calculation. Revealing an error is not automatically a saving; the organization still has to act on what it learns. A boundary can also suppress useful experimentation. Both effects must be observed.

Still, the model changes what we look for. We stop measuring improvement only by how many tasks a system completes and start asking why those tasks exist.

What this might mean for AI

Much of the current ambition around AI is to complete more human work: write, analyze, code, coordinate. I think another valuable direction is possible: identify unwanted organizational feedback loops and help people change the conditions that generate unnecessary work.

That is a hypothesis about a possible direction, not a claim that AES already autonomously redesigns companies. Diagnosing a loop does not grant an agent the right to change it. Such interventions affect commitments and people; they require evidence, explicit authority, reversible experiments where possible and an accountable decision-maker.

The interesting goal would not be “let AI do everything we currently do.” It would also be “discover which activities a better-designed organization would not need to generate.”

Start with one bounded question

What processes in your system exist right now only because you fill every gap too quickly with your own decisions?

Choose one reversible situation. Name the transition you normally complete automatically. Make its cost and consequences visible. Agree on the boundary, the observation period and the conditions for intervention. Then examine what the system does when you do not immediately supply the missing piece.

Do not manage only the action or the outcome. Sometimes the more useful object is the space in which the next action, architecture and outcome become possible.

This is an authorial working model based on my reflections and anonymized observations, not a verified causal evaluation. The original reasoning was supplied by the author for this publication.