The Systems Behind the Systems
Where Cloud Architecture Meets Philosophy
Every profession has a tendency to focus on its tools.
Architects talk about buildings. Engineers talk about machines. Software developers debate programming languages. Cloud consultants compare platforms and services.
Those conversations matter. They move our professions forward.
But after almost twenty years working in technology, I’ve become convinced that the most interesting problems have very little to do with the technology itself.
Technology is simply where human systems become visible.
Every major outage tells a story about communication, incentives, assumptions, or organizational structure. Every successful migration is as much about trust as it is about architecture. Every resilient platform reflects not only good engineering, but good decision making.
The technology is rarely the whole story.
Throughout my career I’ve had the opportunity to wear a number of hats.
I’ve worked in consulting, led Site Reliability Engineering teams, designed cloud platforms, responded to critical incidents, automated operational processes, and helped organizations navigate technical change, among other things.
Each role taught me new tools.
More importantly, each role taught me new ways of thinking.
The longer I have worked in technology, the less interested I have become in individual products and the more fascinated I have become by the principles that seemed to appear everywhere.
- Why do some organizations consistently make good decisions while others struggle?
- Why do certain architectures remain flexible while others become brittle?
- Why do some teams improve after failure while others repeat the same mistakes?
Those questions aren’t unique to IT.
They’re questions about systems.
Somewhere along the way, I found myself reading as much philosophy, psychology, history, and organizational theory as I did technical documentation.
I discovered that many of the ideas I relied on every day already had names.
- Parkinson’s Law
- Conway’s Law
- Goodhart’s Law
- Hanlon’s Razor
- Occam’s Razor
- The Pareto Principle
These weren’t just interesting observations. They were practical tools for understanding why organizations behave the way they do.
The more I recognized these patterns, the more I saw them everywhere—not just in cloud architecture, but in businesses, governments, communities, and everyday life.
That’s why this blog exists.
Not to explain how to configure another cloud service.
Not to argue about which technology is best.
There are already plenty of people doing that, and doing it well.
Instead, I want to explore the ideas that exist underneath the technology.
The principles that shape resilient systems.
The mental models that improve decision making.
The leadership lessons hidden inside major incidents.
The philosophy behind architecture.
Sometimes those discussions will be deeply technical.
Other times they may involve history, economics, organizational behavior, or a book I’ve recently finished reading.
If there’s a common thread, it’s this:
Complex systems are everywhere. Technology just happens to be one of the best places to study them.
I’m writing these articles as much for myself as for anyone else.
Consulting has taught me that every project leaves behind lessons worth preserving. Unfortunately, those lessons often disappear once the project ends.
This blog is my attempt to keep learning out loud.
To capture ideas before they’re forgotten.
To connect concepts that don’t usually appear in the same conversation.
And hopefully, to help someone else see a familiar problem from a different perspective.
If you’ve found your way here because you’re interested in cloud architecture, welcome.
If you’re here because you’re interested in leadership, philosophy, systems thinking, or simply understanding why complex things succeed—or fail—you’ll probably feel at home as well.
Thanks for reading.
I hope you’ll join me as we explore the systems behind the systems.