The Hidden Rules of Technology
The Hidden Rules of Technology: Eponymous Laws Every IT Consultant Should Know
Every few years, technology reinvents itself.
Mainframes gave way to servers. Servers became virtual machines. Virtual machines became containers. Containers became serverless platforms. Today’s buzzword is tomorrow’s legacy technology.
Yet after nearly two decades in IT, I’ve noticed something surprising: while the technology changes constantly, the patterns surrounding it rarely do.
When I first started in IT, I was an intern at my college. I focused on Cisco routers, Bash scripting, and troubleshooting Windows operating systems. Like many people entering the field, I believed success would come from mastering tools. Learn the platform. Learn the language. Learn the framework. Profit!
Over time, I discovered something more valuable.
The best architects, engineers, and consultants I’ve worked with aren’t defined by the technologies they know. They’re guided by a collection of timeless observations about how systems, organizations, and people behave. They recognize patterns before everyone else does.
Many of those observations have names attached to them. They’re known as eponymous laws—principles named after the people who first articulated them, or at least those most commonly associated with them.
None of these laws are absolute truths. They’re mental models. Some are more than a century old. Others came from software engineering. Nearly all of them describe patterns that I’ve watched unfold across cloud migrations, platform engineering, organizational transformations, and consulting engagements.
This post introduces a handful of the principles I find myself referencing most often. Several deserve articles of their own, and I suspect they’ll appear again in future posts.
Parkinson’s Law: Work Expands to Fill the Time Available
Parkinson’s Law: Work expands so as to fill the time available for its completion.
I’ve watched this play out countless times during cloud migrations.
A team given six months to migrate an application somehow finds six months of work. Give that same team six weeks, and suddenly priorities become crystal clear. Nice-to-have features disappear. Decisions happen faster. Stakeholders become more responsive.
This isn’t an argument for impossible deadlines. It’s a reminder that constraints create focus.
Agile and sprint planning work, in part, because they intentionally constrain work into fixed periods. Those constraints force teams to prioritize what actually delivers value instead of endlessly refining what is already good enough.
As consultants, our job isn’t to help organizations do more. It’s to help them identify the minimum work necessary to achieve meaningful outcomes.
Conway’s Law: Organizations Design Systems That Mirror Their Communication Structures
Conway’s Law: Organizations design systems that mirror their communication structures.
This may be the most important law in modern cloud architecture.
When I encounter a complicated architecture, I often find an equally complicated organizational structure behind it. Teams with overlapping responsibilities create overlapping services. Departments that rarely communicate produce systems that integrate poorly.
I’ve seen organizations spend months redesigning architectures when what really needed redesigning was communication.
Too often we try to solve organizational problems with technology.
Sometimes the best architecture discussion starts with an org chart.
Goodhart’s Law: When a Measure Becomes the Target
Goodhart’s Law: When a measure becomes a target, it ceases to be a good measure.
Every consultant eventually encounters this.
A support team is measured by tickets closed, so tickets get closed while customer issues remain unresolved.
An engineering team is measured by deployment frequency, so deployments increase without improving reliability.
A cloud team is measured by cost reduction, so innovation slows because nobody wants to spend money.
Metrics matter.
But metrics should inform decisions—not become the objective themselves.
The best metrics illuminate reality. The worst metrics distort behavior.
Hanlon’s Razor: Assume Good Intent
This may be my personal favorite.
Anyone who’s worked with me for more than a few meetings has probably heard me say, “Assume good intent.”
Hanlon’s Razor is commonly stated as:
Never attribute to malice that which can be adequately explained by incompetence.
I think “assume good intent” captures the spirit without focusing on the word incompetence.
Consulting often places us in the middle of organizational tension. Projects miss deadlines. Documentation is outdated. Stakeholders seem disengaged. Systems fail.
It’s easy to conclude that someone simply doesn’t care.
More often, people are overloaded. They’re making decisions with incomplete information. They’re balancing competing priorities. Sometimes what appears to be a poor decision today was actually the best decision that could be made at the time.
I’ve also learned that what looks like resistance is sometimes exhaustion. After multiple failed attempts to improve something, people naturally become skeptical of the next “new initiative.”
Assuming good intent doesn’t mean accepting poor outcomes.
It means beginning the conversation with curiosity instead of blame.
In my experience, that’s where better consulting begins.
Brooks’ Law: Adding People to a Late Project Makes It Later
Brooks’ Law: Adding manpower to a late software project makes it later.
When projects begin slipping, organizations often respond by adding more people.
It’s an understandable reaction—but it’s rarely the solution.
Every new team member adds communication paths, onboarding time, and coordination overhead before they add productivity.
I’ve watched smaller, highly aligned cloud teams outperform much larger organizations simply because everyone understood the mission and communicated effectively.
The better solution is creating feedback loops early.
Frequent demonstrations. Sprint reviews. Regular stakeholder conversations. Honest retrospectives.
Identify problems while they’re still small enough to solve.
And when that’s no longer possible, remove obstacles instead of adding complexity.
In my experience, the obstacles discovered late in a project are often the same ones that existed from the very beginning.
Chesterton’s Fence: Understand Why It Exists Before You Remove It
One of the most valuable consulting principles didn’t originate in technology.
Chesterton’s Fence is based on the idea that if you encounter a fence, you should first understand why it was built before deciding to tear it down.
Technology is full of fences.
- An unusual approval process.
- A strange naming convention.
- An extra security review.
- A deployment step that nobody can explain.
Consultants are hired to improve things, and the temptation is to assume that anything old must be wrong.
I’ve certainly been guilty of that.
Over time I’ve learned that legacy systems often contain hard-earned lessons. Processes that appear unnecessary today may have been created to solve problems everyone else has forgotten.
Sometimes those fences should absolutely come down.
But before removing one, understand what it’s protecting.
The Real Value of Eponymous Laws
None of these laws are formulas.
They don’t replace expertise, experience, or thoughtful analysis.
Their value lies in helping us recognize recurring patterns.
Technology evolves at an incredible pace.
Cloud platforms change.
Programming languages change.
Architectures change.
People, organizations, incentives, and communication change much more slowly.
The longer I work in consulting, the more I believe success depends less on mastering the latest technology and more on recognizing the timeless patterns that shape how people build and operate systems.
The next time you find yourself walking into a difficult project, don’t start by asking what technology is involved.
Start by asking which law you’re about to watch unfold.
The tools may change.
The laws rarely do.