On Systems
Most problems that look technical are actually operational. The software becomes secondary. The people become the infrastructure.
Lately I've been spending a lot of time thinking about systems.
Not software systems, at least not exclusively. Organizational systems. Learning systems. Training systems. Businesses. Teams. Workflows. The invisible structures that determine how things actually get done.
The more I learn, the more I notice the same pattern repeating itself.
Most technical problems are actually operational
A company doesn't need a better dashboard. It needs a way for information to move through the organization without getting lost.
A team doesn't need AI. It needs a process that doesn't depend on a single person remembering everything.
A business doesn't need another platform. It needs fewer places where work disappears into spreadsheets, emails, and tribal knowledge.
I've become increasingly interested in the gap between how organizations think they operate and how they actually operate.
On paper, most businesses are simple. There are procedures. Roles. Software. Responsibilities.
In reality, work happens through workarounds.
Someone knows a shortcut. Someone manually reconciles data every Friday. Someone remembers which report is wrong. Someone answers the same question ten times a week because the answer exists somewhere, but nobody can find it.
Over time, these small adaptations become the real system. The software becomes secondary. The people become the infrastructure.
The hidden layer
What fascinates me is that every organization eventually develops this hidden layer. A collection of unwritten rules, exceptions, habits, and institutional memory that keeps everything moving.
When those people leave, the organization discovers how much of its operation was never actually documented.
This is one reason I've become interested in knowledge systems, simulations, training environments, and AI-assisted tools. Not because the technology is impressive, but because they all deal with the same underlying problem:
How do we preserve understanding? How do we help people make better decisions? How do we reduce unnecessary friction? How do we build systems that remain useful as organizations grow?
Simulation and the same principle
I think a lot about simulation for the same reason.
A simulator is ultimately an attempt to understand reality well enough to model it. Whether it's a military training environment, a business workflow, or a game, you're trying to identify the rules that govern a system and make them visible.
The same principle applies to organizations.
Before improving a process, you need to understand it. Before automating a workflow, you need to observe it. Before introducing AI, you need to know what problem you're actually solving.
The wrong first questions
I've noticed that many conversations about technology start with solutions.
What software should we buy? What model should we use? What tool should we integrate?
Those are usually the wrong first questions.
The more useful question is: what work are people actually doing?
Most opportunities reveal themselves after that. Not in strategy meetings. Not in architecture diagrams. In the ordinary repetition of daily work.
The report generated every morning. The information entered three different times. The question asked every week. The approval that always gets delayed. The spreadsheet everyone depends on but nobody trusts.
Those details tell you where the system is struggling.
What I'm actually looking for
The longer I work on projects, the less interested I become in technology for its own sake.
I'm more interested in why systems succeed, why they fail, and why some organizations seem able to adapt while others accumulate complexity until every change becomes difficult.
Good systems rarely feel impressive. They feel obvious.
The right information appears when it's needed. The process makes sense. The tool supports the work instead of fighting it. People stop thinking about the system and focus on the problem they're trying to solve.
That's the kind of work I find myself drawn toward. Not building technology because technology is interesting. Building systems that help people understand, decide, learn, and operate more effectively.
Most of the questions I'm exploring eventually lead back to that same idea.
The technology changes. The industries change. The tools change. The underlying problem remains remarkably consistent.
How do we build systems that help people do meaningful work with less friction?