Experiments Don’t Just Build Skills. They Build Perspective

One of the biggest advantages I’ve gained in my life didn’t come from a certification, a university degree, or a particular job.

It came from running experiments.

When people hear the word experiment, they often think about testing a new technology or writing a proof of concept.

To me, experimentation has always meant something much broader. It’s the deliberate act of stepping into uncertainty to learn something new.

Over the years, I’ve realized that the greatest return from an experiment isn’t the thing you set out to build.

It’s the person you become while building it.

It Started with a Slow Laptop

Like many people in technology, I didn’t start with an expensive workstation or a sophisticated home lab.

My first “lab” was a modest 4-core laptop with 8 GB of RAM running Windows 10 from a mechanical hard drive. It struggled with virtualization, constantly overheated, and tested my patience every day.

Looking back, I’m grateful for those limitations.

That machine gave me a place to ask questions.

What happens if I build this?

Can I automate that?

Why does this break?

Can I make it work anyway?

I wasn’t trying to build a career.

I was simply curious.

That curiosity slowly became a habit.

The Experiments Got Bigger

As my career progressed, so did the scale of the experiments.

The projects evolved from home labs to cloud infrastructure, cybersecurity research, AI, teaching, automation, publishing, and eventually launching a book.

Naturally, the cost increased.

Some experiments required hardware.

Some required cloud resources.

Others required months of evenings and weekends.

If you looked only at the financial investment, some of these projects probably wouldn’t make sense.

But that’s because most people measure experiments incorrectly.

The Return Isn’t What You Think

Recently, we published a book.

Yes, it required an investment.

Fortunately, because we built much of the capability in-house instead of outsourcing everything, the cost was significantly lower than it otherwise would have been.

But if I evaluated that project purely by book sales, I’d be asking the wrong question.

One of the experiments we ran had nothing to do with writing the book itself.

When it came time to launch it, we could have followed the conventional playbook: announce the release, publish a few social media posts, and hope people found it.

Instead, we decided to experiment.

We turned the launch into a song.

None of us knew whether it would work. There wasn’t a blueprint to follow, and success wasn’t guaranteed. It was simply an idea we thought was worth testing.

What happened next surprised me.

Within days, messages started arriving from France, Dubai, London, and across the United States. Most weren’t asking about the book. They were asking about the song that introduced them to it.

A single creative experiment connected us with people from different countries, industries, and backgrounds who otherwise might never have encountered our work.

The lesson wasn’t that “songs sell books.”

The lesson was that experiments create opportunities you can’t predict.

That project also taught us about branding, marketing, project management, content strategy, audience psychology, operations, and AI-assisted workflows. Some of the AI research that emerged during the project has since evolved into tools that can be applied to red team engagements.

None of those outcomes were part of the original plan.

Every meaningful experiment leaves behind something more valuable than the thing you originally set out to build.

That’s where the real ROI lives.

The Biggest Trap in Technology

One thing I’ve noticed throughout my career is that many of us especially in technology develop a very narrow view of the world.

Engineers become exceptional engineers.

Security professionals become exceptional security professionals.

Marketers become exceptional marketers.

Finance professionals become exceptional finance professionals.

There’s nothing wrong with specialization.

In fact, the world needs specialists.

But real-world problems don’t arrive neatly packaged inside department boundaries.

A technical decision affects business.

A security recommendation affects operations.

A product feature changes customer behavior.

A marketing campaign depends on psychology.

A budgeting decision influences engineering priorities.

The real world is messy.

The most valuable people I’ve met aren’t necessarily the ones who know the most about one subject.

They’re the ones who can connect multiple disciplines.

An engineer who understands psychology designs products people naturally enjoy using.

A cybersecurity professional who understands business communicates risk in a way executives can act upon.

A marketer who understands finance allocates budgets more effectively.

An operations leader who understands software development builds processes that enable engineers instead of slowing them down.

Depth creates expertise.

Breadth creates leverage.

The combination of both creates exceptional problem solvers.

Learning to Speak More Than One Language

One unexpected outcome of years of experimentation is that conversations have become easier.

Not because I know everything I don’t.

But because I’ve learned enough about different disciplines to build bridges between them.

A few days ago, I was troubleshooting a Linux kernel panic and happened to mention it to someone whose background was in psychology.

They smiled and said,

“Nathaniel, I don’t understand anything you’re talking about.”

Instead of explaining memory management, kernel space, boot sequences, and stack traces, I tried something different.

I asked them to imagine someone who had experienced a deeply traumatic event.

That event fundamentally changed how they processed the world. Their normal patterns of thinking broke down. They struggled to function the way they once had.

A therapist’s role is to understand what happened, help stabilize the person, and gradually guide them toward recovery.

Then I told her that, conceptually, a kernel panic isn’t entirely different.

The operating system has encountered a failure so severe that it cannot safely continue. The objective isn’t simply to restart the machine it’s to understand why the failure occurred, restore stability, and prevent it from happening again.

She immediately understood.

Not because she suddenly knew operating systems.

But because we found a shared mental model.

That conversation stayed with me.

It reminded me that expertise isn’t just about knowing your own field.

It’s about understanding someone else’s well enough to connect the two.

Experiments Change the Way You Think

Every meaningful experiment eventually forces you outside your comfort zone.

A technical project eventually requires communication.

Communication introduces psychology.

Psychology introduces design.

Design introduces branding.

Branding introduces marketing.

Marketing introduces finance.

Finance influences strategy.

Before long, what started as “just a technical project” has quietly become an education in half a dozen disciplines.

I don’t think I’m a better therapist than someone who has spent years helping people through trauma.

Nor do I think I’m a better kernel engineer than someone who spends every day debugging operating systems.

That’s not the point.

The point is understanding enough about different domains to recognize patterns between them.

Because once you start seeing those patterns, you stop solving isolated technical problems.

You start solving systems.

Some systems are made of software.

Some are made of people.

Some are made of incentives.

Some are made of organizations.

Some are made of relationships.

The more systems I study, the more I realize they often behave in surprisingly similar ways.

The Hardest Skill to Measure

Perhaps the biggest outcome of years of experimentation isn’t technical knowledge at all.

It’s judgment.

Over time, I’ve become better at recognizing opportunities.

Better at deciding where to allocate time and capital.

Better at estimating risk.

Better at walking away from ideas that look exciting but have little long-term value.

People often call this intuition.

I don’t think it is.

I think it’s pattern recognition built from hundreds of experiments across different domains.

Every experiment leaves behind data.

Some leave behind technical knowledge.

Some leave behind relationships.

Some leave behind business insight.

Some leave behind failures you’ll never repeat.

Eventually those lessons compound.

The decisions become clearer—not because the world has become simpler, but because you’ve seen enough of it to recognize familiar patterns.

Looking Back

If someone looked at my career from the outside, it might seem scattered.

Cybersecurity.

Cloud.

AI.

Teaching.

Research.

Publishing.

Infrastructure.

Business.

At first glance, they don’t appear connected.

To me, they are all part of the same pursuit.

Understanding systems.

Every experiment has simply been another way of studying how complex systems work whether those systems are computers, businesses, people, or organizations.

Run More Experiments

If there’s one idea I’d leave you with, it’s this:

Run more experiments.

Not reckless ones.

Deliberate ones.

Build something you’ve never built.

Write something you’ve never written.

Teach something you’ve never taught.

Launch something that might fail.

Learn something completely outside your field.

The value of an experiment isn’t determined solely by whether it succeeds.

It’s determined by what it teaches you.

Because every experiment expands your perspective.

And in a world where the biggest problems sit at the intersection of multiple disciplines, perspective may be one of the most valuable assets you can build.