I got there by spending years inside very different organizations and eventually realizing that, beneath the surface, many of them were struggling with the same kinds of structural problems.

With FEMA, I was deployed into disaster areas where the infrastructure people normally depend on was damaged, disrupted, or gone. Agencies, contractors, responders, equipment, supplies, and information still had to move around an important mission.

In that environment, there is no hiding behind a process map.

When the normal infrastructure disappears, you find out very quickly what a system actually depends on.

Who has the information. Who has authority. Who owns the next step. What can be improvised. What absolutely cannot.

FEMA taught me that infrastructure is not background. It is what makes coordinated action possible.

I owned a marketing consulting firm, and that work gave me access to an unusually wide range of businesses.

Commercial printers. Mortgage brokerages. Fashion retail. E-commerce. Title companies. Law offices. Restaurants. Service businesses. Creative firms. Startups.

I also worked in call centers, hotels, luxury automotive service, national remodeling, solar energy, and design and agency environments. I worked with innovative startups in Dubai and elsewhere in the UAE, where branding and web development could sit alongside international equipment and supply procurement.

All of those experiences gave me operating environments from completely different angles.

When I owned the marketing firm, I couldn’t market a business intelligently without understanding how the business actually functioned.

I needed to know how customers entered the system, what happened when someone called, how a lead became revenue, what happened after the sale, how the company delivered what marketing had promised, and where the experience broke down.

That meant spending a lot of time inside other people’s businesses.

And the more businesses I encountered, the more something started to change in the way I looked at them.

The industries were wildly different.

The underlying machinery often wasn’t.

A company could have excellent people and plenty of software and still depend on one person knowing where everything was.

A business could have strong sales and still lose value at the handoff into operations.

A new system could solve one problem while creating another place for information to live.

Growth could make a healthy company feel worse instead of better because every new customer created more coordination, more exceptions, and more things someone had to remember.

At volume, small weaknesses repeated.

Across borders, small ambiguities traveled.

Across functions, missing context became expensive.

I became increasingly good at noticing recurring structures underneath situations that looked unrelated on the surface.

Pattern recognition became an earned ability.

And alongside it developed something more specific:

Comparative systems recognition — seeing that two companies can look nothing alike on the surface while failing for structurally similar reasons underneath.

A mortgage brokerage and a remodeling company might have almost nothing in common operationally, yet both can lose critical information at a handoff.

A hotel and a call center can have completely different workflows while both depending on one person to carry context the system itself should retain.

A law office and a solar company can use entirely different tools and still suffer from the same underlying ambiguity around ownership, information flow, and next actions.

Once I started seeing those patterns, I became less willing to accept the first explanation for why something was broken.

What looked like a staffing problem might actually be an ownership problem.

What looked like a software problem might really be a process problem.

What looked like a performance problem might be a system asking people to compensate for architecture that no longer fit the business.

That became Constraint Interrogation: refusing to accept the apparent constraint until I understood what was actually governing the outcome.

There was another shift happening at the same time.

I became less interested in simply fixing the error in front of me.

If something broke, I wanted to know what that failure revealed about the system around it.

Could the handoff be redesigned?

Could ownership become clearer?

Could information be preserved instead of lost?

Could a control prevent the same class of failure?

Could the organization learn enough from one problem that it did not have to keep paying for it?

The goal became to make the system stronger, not merely make the current problem disappear.

I stepped into a large national company with serious technology, including Salesforce, but also years of systems, functions, processes, and workarounds that had accumulated as the organization grew.

Sales had one reality.

Account management had another.

Field operations had another.

Logistics and material distribution had another.

Finance had another.

None of those functions was inherently broken.

The problem was what happened between them.

A particularly capable person had become the connective tissue across major parts of the company.

He knew how everything really worked.

He knew the workarounds, the unofficial paths, the people to call, the exceptions, and where the information actually lived.

If he had walked out that morning, a meaningful part of the operation would have struggled to function that same day.

He was extraordinary.

But that was also the problem.

A human being had become part of the infrastructure.

Then I was placed into a version of the same role for an entire region.

I was carrying responsibilities across functions, translating between parts of the operation, solving exceptions, keeping information moving, and filling gaps that did not really belong to any one role.

I could see what needed to change.

I understood enough of the system to recognize where the architecture was forcing people to compensate for it.

But I did not have the authority to redesign it.

I had spent years admiring the people who could hold complicated organizations together. Now I understood the cost of designing an organization that required them to.

That was the real aha for me.

Looking back, FEMA, call centers, hospitality, automotive service, remodeling, solar energy, international startups, and the many businesses I encountered through my own marketing firm had not been unrelated chapters.

They were giving me repeated exposure to different operating systems.

And all of that exposure was converging into a set of abilities I had never deliberately named.

Pattern recognition. Comparative systems recognition. Constraint Interrogation. Systems synthesis.

The ability to move into an unfamiliar environment, understand how work actually flows, recognize the structural pattern beneath the industry-specific symptom, and see where people are compensating for architecture that should be doing more.

The broader capability developing underneath all of it was the ability to see the system beneath the symptom.

And by then, I was no longer only observing the cost of weak architecture.

I had experienced what it felt like to become part of the workaround.

I knew the underlying business could work.

But markets change.

When a market softens, an operator adapts.

I did not want to simply recreate the previous version of Alta because it had worked before. I wanted to rebuild it for the environment it now had to compete in — leaner, smarter, and more scalable.

For the first time, I had the authority to design the system instead of inheriting it.

That changed the nature of the experiment.

The website could connect to lead intake.

Lead intake could connect to sales.

Sales could carry cleanly into estimating, scope, contracts, project setup, purchasing, scheduling, and field operations.

A field change could have a clear cause instead of disappearing into a generic “change order.”

A payment could have an explicit state instead of simply being called “paid.”

Closeout could mean something specific.

Training, controls, customer communication, and operating knowledge could belong to the company rather than living inside a collection of people’s heads.

Instead of admiring the person who knew how to bridge the gaps, I could begin designing the gaps out of the operation.

Alta became the place where I could finally test whether that broader systems instinct could be converted into an intentional design discipline.

Could pattern recognition become diagnosis?

Could intuition become architecture?

Could repeated operating lessons become controls, workflows, memory, and automation?

Could a company preserve what it learned instead of paying to rediscover it?

That became the rebuild.

I did not discover AI and then go looking for business problems to apply it to.

I had already spent years seeing the same pattern: too much manual coordination, information scattered across disconnected systems, repeated questions, and context disappearing between people and processes.

AI arrived later and expanded what could be built.

Software could begin to work with context — interpreting information, preserving knowledge, recognizing patterns, and supporting people in ways traditional systems could not.

That opened an entirely new design space.

But AI was never the premise.

The premise was always the company.

How should this organization actually work?

Then we decide what belongs to a person, what belongs to conventional software, what can be automated, and where AI genuinely improves the architecture.

What I bring to that work is not a claim that I have architected hundreds of companies.

It is something different.

I have spent years inside and around very different organizations, watching systems behave under different kinds of pressure and learning to recognize what repeats beneath the surface.

Those experiences did not give me a title. They gave me earned abilities.

The ability to recognize patterns across unfamiliar environments.

The ability to interrogate the apparent constraint.

The ability to connect pieces that are usually managed separately and see the operating system they collectively create.

The instinct to use failure as information and make the system stronger rather than merely patching the immediate error.

And increasingly, the discipline to turn those instincts into architecture that can be tested, measured, and improved.

That is who I became before I ever had language for it.

And that is the work I am building forward from now.