From Schematic Drawings to Workflow Diagrams

Most people assume engineering and business are completely different worlds.

I used to think the same.

My early career involved working with machines, equipment, manufacturing processes, logistics operations, and technical environments.

I spent years looking at schematic drawings, technical documentation, process flows, and operational systems.

Everything revolved around understanding how components worked together.

Inputs.

Outputs.

Dependencies.

Failure points.

Bottlenecks.

Optimization.

At some point, something interesting happened.

I became less interested in the drawing itself and more interested in the system behind it.

A schematic drawing is essentially a visual representation of a system.

A machine receives an input, performs a process, and produces an output.

When something goes wrong, engineers ask questions:

• Where is the fault?

• What caused the failure?

• Which component is responsible?

• How can we improve reliability?

The goal is to understand the system.

Years later, I realized businesses operate in a remarkably similar way.

The symbols changed.

The thinking did not.

Instead of pumps, motors, sensors, and valves, I was looking at customers, employees, workflows, suppliers, and operations.

The questions remained the same.

• Where is the bottleneck?

• What is causing the issue?

• Which part of the process is failing?

• How can performance be improved?

A machine can stop because of a faulty sensor.

A business can lose customers because of a faulty process.

Both are systems.

Both have inputs and outputs.

Both can be analyzed.

Both can be improved.

This realization fundamentally changed how I viewed the world around me.

I stopped seeing businesses as isolated entities.

I started seeing systems.

Restaurants became operational systems.

Websites became customer acquisition systems.

Logistics networks became flow systems.

Customer service became communication systems.

Businesses became living systems made up of people, processes, technology, and decisions.

This is where my Huntsman framework began to develop.

Analyst

Understand the system.

Analogist

Recognize patterns between systems.

Anomalist

Discover what others overlooked.

Huntsman

Execute.

Because understanding a problem is valuable.

Discovering an opportunity is valuable.

But execution is what transforms knowledge into results.

Today, when I walk into a restaurant, warehouse, office, or small business, I naturally find myself observing how things work.

Not because I am looking for flaws.

Not because I am trying to criticize.

But because I am genuinely curious.

I enjoy understanding systems.

I enjoy discovering patterns.

I enjoy learning how things work.

And sometimes, that curiosity leads to opportunities for improvement.

Looking back, I never really stopped drawing schematics.

I simply changed the symbols.

The machines became businesses.

The components became people.

The processes became workflows.

The drawings became systems.

And every now and then, I still catch myself looking at a business and thinking:

"Interesting..."