What happens when a career built around living systems suddenly has to invent its own gravity I once described my relationship with work as a super-gravitational pull to the system. That phrase explained something I had been struggling to describe. I have worked a lot.
Sometimes an unreasonable amount. But “likes working” is not a very good explanation for why. The thing that held my attention was not the existence of a job. It was the system.
A living operation generates problems continuously. A trailer is late. A dock backs up. A process fails.
A person needs coaching. A piece of equipment changes state. A departure is approaching. A building is sending too much.
Another building cannot absorb it. Somebody asks a question whose answer requires understanding five things that happened earlier. The system pulls you in. Every answer changes the next question.
That was my black hole. Then I left. The surprising problem was not simply losing a job. I lost the gravitational field.
THE SYSTEM WAS WAITING EVERY MORNING
For years, I did not have to invent meaningful work. It was already there. Amazon was an enormous machine that continuously produced puzzles. The scale made that inevitable.
People. Buildings. Packages. Equipment.
Transportation. Software. Customers. Deadlines.
Forecasts. Exceptions. Every one of those could change the state of the others. You could walk into the operation and find something worth understanding.
That matters for a particular kind of brain. A to-do list says: Here are twelve unrelated obligations. A living system says:
Here is a state. Something is wrong. Find out why. Those feel completely different. The second one pulls. The first one pushes.
I did my best work when the problem itself created the momentum. That is what I mean by a black hole. Not chaos. Not compulsive busyness.
Immersion.
THE REWARD LOOP WAS THE SOLUTION
The easiest story would be that the reward was money or title. It wasn't. Those things matter. I am not romantic enough to pretend they do not. But they were not the thing that kept me absorbed.
The reward was solving a system that mattered. Sometimes the feedback was immediate. A dock clears. A departure makes it.
A process starts flowing. A person understands the job. Sometimes it arrived months later. Someone says the thing you built changed how they work.
Sometimes the reward was almost private. You look at the operation and know that the cadence is right. The flow is healthy. The pressure is where it belongs.
The system is behaving. That is satisfying in a way that is difficult to reproduce with a list of administrative tasks. The work answers back.
WHEN THE BLACK HOLE DISAPPEARS
Leaving a large operating environment creates an unexpected inversion. Inside the company, the system exists before you arrive. Outside, you have to create the system that will eventually create the work. That is an entirely different task.
I went from operating inside mature infrastructure to simultaneously becoming: system architect, IT department, web developer,
designer, marketer, operations manager, content writer,
project manager, quality assurance, and technical support. Those are all legitimate parts of building a business.
They do not create the same gravitational experience. Instead of waking up to a living system that needs to be understood, you wake up to a collection of components that do not yet form a system. Domain. Website.
Email. Files. Cloud accounts. Development tools.
AI assistants. Hosting. Sales. Products.
Documentation. Everything needs an owner. The owner is you. That is not immersion.
At first, it is assembly.
I KNOW THE SYSTEMS, NOT THE BUTTONS
One sentence from that transition captured the problem: I know the systems but not where the buttons are. Inside a mature enterprise environment, I was applying operational judgment inside infrastructure other people had already built. I did not have to personally design the laptop configuration before I could reason about regional flow.
I did not have to debug cloud synchronization before I could optimize a dock. I did not have to decide which development environment should contain the tool before I could understand what the tool needed to do. The infrastructure disappeared into the background. That is what good infrastructure does.
Then I moved into an environment where the infrastructure itself became the problem. Windows. Accounts. OneDrive.
iCloud. Indexing. Autosave. Editors.
AI agents. Hosting. File paths. Permissions.
Now I was spending cognitive energy on the buttons. For somebody whose useful skill is reasoning about the system, that is a brutal trade.
THE TOOL HAS TO BECOME BORING
This experience changed how I think about tooling. The best tool is not necessarily the one with the most features. It is the one you trust enough to forget about. That is a high standard.
If every time you sit down you have to ask whether the file will still be there tomorrow, the tool has entered the work. If you have to remember which cloud account owns which folder, the tool has entered the work. If indexing creates duplicate structures, the tool has entered the work. If an assistant changes the architecture while trying to help, the tool has entered the work.
Now attention that should be available for the problem is being consumed by the environment. Trust beats features. The tool should become boring. Then the system can become interesting.
IMMERSION IS NOT THE SAME AS FOCUS
Productivity culture talks constantly about focus. Thirty-minute blocks. Pomodoro timers. Task lists.
Priorities. Those can be useful. They do not describe the state I am talking about. Immersion is different.
Focus is an instruction. Immersion is gravity. When I am immersed, I do not need to persuade myself to return to the problem. The problem keeps unfolding.
One answer exposes another condition. One constraint reveals the next. The work creates continuity. That is why a living system can hold attention differently than a pile of tasks.
It has state. It remembers where you were. It has consequences. It changes when you touch it.
That is closer to operating a machine than completing a checklist.
THE DANGER OF RECREATING CHAOS INSTEAD OF GRAVITY
There is a trap here. If you miss the intensity of a complex operating environment, it is possible to recreate complexity and mistake it for immersion. More tools. More projects.
More models. More tabs. More products. More ideas.
More files. Now there is certainly enough happening. But activity does not automatically create gravity. It can create noise.
The black hole was never valuable because it was chaotic. It was valuable because the problems were connected. A late trailer affected the dock. The dock affected a CPT.
The CPT affected the network. The network affected another building. The problem had architecture. Random complexity does not have that quality.
It fragments attention instead of concentrating it. That distinction matters enormously when building a business from scratch. The goal is not to create enough chaos to feel busy again. The goal is to create a system coherent enough to pull you forward.
ONE LIVING SYSTEM
At one point the better question became: How do I create another black hole? Maybe it is one website. One client.
One product. One nonprofit. The exact object matters less than the architecture. It has to be real enough to generate feedback.
A website with actual visitors tells you something. A client with an actual workflow creates constraints. A software product with an actual user produces exceptions. A business with actual customers creates state.
Now the system can answer back. That is when work stops feeling like pushing a boulder through a list and begins feeling like operating something. The danger is trying to create ten living systems simultaneously. Ten systems do not create ten times the immersion.
They may prevent any one of them from becoming coherent enough to generate it.
THE ENVIRONMENT SHOULD ASK FOR ONE THING
This connects to something I learned while designing software agents. I like agents to have one job. Not because a model is incapable of doing several things. Because role clarity reduces conflict.
The same principle applies to the human environment. My brain can think about ten connected variables. That is useful. My environment should not force me to negotiate ten unrelated tool problems at the same time.
There is a difference between complexity inside the system and complexity around the system. I like the first. I hate the second. A regional fulfillment network can be enormously complex and still be intellectually coherent.
A desktop with duplicate folders, conflicting cloud identities and tools that unexpectedly change state can be comparatively small and cognitively miserable. Complexity is not the enemy. Unstructured complexity is.
THE SYSTEM HAS TO BECOME TRUSTWORTHY BEFORE IT BECOMES ABSORBING
When infrastructure is unstable, immersion becomes dangerous. You can spend six hours inside a project and discover that the environment did not preserve the state you thought you created. That destroys the feedback loop. The work no longer answers back reliably.
Instead of: I changed this and the system changed accordingly, you get: I changed this and I am no longer sure which version exists.
That is poison to systems thinking. Cause and effect depend on state. If state cannot be trusted, learning becomes expensive. That is why rebuilding trustworthy infrastructure became more important than adding more capability.
Known-good baseline. Clear file structure. Controlled authority. Reliable backups.
Understandable deployment. One source of truth. Those things can feel boring compared with product development. They create the conditions in which product development can become absorbing again.
BUILDING THE MACHINE IS DIFFERENT FROM OPERATING IT
This may be the central challenge of leaving a mature organization to start something new. Operating and building are not the same activity. The operator enters an existing machine and improves its behavior. The founder has to create enough of the machine before there is meaningful behavior to improve.
That means tolerating a period where the feedback loop is weak. You are building the conveyor before there are packages on it. You are defining the routes before there is volume. You are writing the website before there are visitors.
You are creating the sales process before there are customers moving through it. It can feel dead compared with operations. Then the first real thing enters. A visitor.
A lead. A customer. A transaction. An exception.
Now the machine starts becoming alive. The work changes. The black hole begins to form.
THE GOAL IS NOT TO GO BACK
I do not think the answer is to recreate my old job. The old system was powerful because it already had enormous scale, infrastructure and consequence. A new system will not begin there. It has to earn its gravity.
The opportunity is to build something whose operating principles are intentional from the beginning. Something where the tools serve the work. Where authority is clear. Where information has a place.
Where software reduces clerical friction. Where people handle judgment. Where the product produces useful evidence. Where the system becomes more valuable as it operates.
That is a different black hole. One I own.
THE LIVING SYSTEM PULLS
There is a sentence from the conversation that stayed with me: A living system pulls you forward instead of a to-do list pushing you from behind. That is the whole thing. I do not need more tasks.
There will never be a shortage of tasks. I need coherence. A system whose problems matter. A system that changes when I improve it.
A system that creates new questions because the previous question was answered. A system that can become trustworthy enough to disappear beneath the work. For years, I walked into that environment every morning. Now I have to build it.
That is harder than I expected. It may also be the most interesting system I have had to engineer.