I’ve spent much of my career building systems.
Some processed payments.
Some connected enterprise platforms.
Some supported education.
Some operated in regulated environments where reliability and traceability mattered enormously.
But over time, I became increasingly interested in another system.
The organization itself.
Because I kept seeing an interesting contradiction.
You could assemble intelligent, experienced, highly motivated people and still produce surprisingly poor outcomes.
Decisions moved slowly.
Teams misunderstood one another.
Knowledge disappeared.
Managers became bottlenecks.
Meetings multiplied.
People spent enormous amounts of time trying to discover what somebody else already knew.
The instinctive response was often to look at the people.
Do they need better communication skills?
More accountability?
More meetings?
More collaboration?
More motivation?
Sometimes.
But increasingly, I found myself asking a different question:
What if the people aren’t the primary problem?
The Architecture Around the People
As a software architect, this felt strangely familiar.
When a complex software system behaves badly, we don’t immediately blame the individual components.
We examine how the system is designed.
How does information move?
Where is state stored?
Where are the bottlenecks?
What happens when a component becomes unavailable?
Which dependencies are hidden?
Where does latency accumulate?
Which interfaces are poorly defined?
How does the system recover from failure?
Then I started asking similar questions about organizations.
Where does context live?
How does a decision travel?
What happens when the person carrying critical knowledge goes on holiday?
Why does every difficult decision need the same manager?
How does one team understand what another team needs?
What happens to the reasoning behind a decision six months after the meeting?
The vocabulary was different.
The underlying problems often weren’t.
Remote Work Made the Architecture Visible
The office used to hide many organizational weaknesses.
Need context?
Walk over to someone’s desk.
Unsure what a manager meant?
Ask them in the corridor.
Didn’t document the decision?
Someone who attended the meeting probably remembers.
Need another team?
Someone knows someone.
These informal mechanisms could be remarkably effective.
But they were also hiding architectural debt.
Then work became more distributed.
Suddenly, the shortcuts weren’t always available.
And organizations concluded:
Remote work is the problem.
I came to a different conclusion.
Remote work didn’t necessarily break the organization.
It exposed the organization.
It showed us how much of the operating system depended on proximity.
Communication Isn’t Just Conversation
This also changed how I thought about communication.
Most organizations don’t suffer from a shortage of messages.
We have email.
Slack.
Teams.
Meetings.
Dashboards.
Documents.
Notifications.
Yet people still say:
I didn’t know.
That wasn’t my understanding.
I thought someone else owned it.
We already discussed this.
The problem isn’t necessarily communication volume.
It’s whether meaning travels.
A signal has to move through something like this:
Signal -> Meaning -> Decision -> Action -> Result
A message sent isn’t automatically meaning received.
Meaning understood isn’t automatically a decision.
A decision isn’t automatically action.
And action isn’t automatically a useful result.
Every broken connection creates friction.
Your Best People Can Hide Your Worst Architecture
Another pattern became increasingly clear to me.
Some organizations work because particular people compensate for the architecture.
One engineer remembers everything.
One manager connects every team.
One product leader understands every historical decision.
One operations expert knows what to do when the system fails.
We call these people indispensable.
And they may indeed be exceptional.
But there’s another way to look at it.
If work stops when one person disappears, you’ve discovered a dependency.
Your strongest people may actually be hiding weaknesses in your organizational design.
They remember what wasn’t documented.
They connect what wasn’t integrated.
They clarify what wasn’t made explicit.
They route what wasn’t designed to flow independently.
Their competence keeps the system running.
Until it can’t.
People Are Not Machines
There is an obvious danger in applying software architecture language to organizations.
People are not servers.
They have emotions.
Judgement.
Ambition.
Relationships.
Creativity.
Fatigue.
Trust.
Fear.
Context.
History.
That’s precisely why I think the architecture around them matters.
A poorly designed software system wastes compute.
A poorly designed organization wastes something far more valuable:
Human attention.
People spend their days searching for information.
Recovering context.
Waiting for decisions.
Attending meetings because nobody knows who actually needs to be there.
Interrupting experts because knowledge hasn’t travelled.
Resolving misunderstandings caused by ambiguous interfaces between teams.
The objective isn’t to make humans behave more like machines.
It’s to design systems that respect the fact that human attention is finite.
This Became Signal Architecture
Eventually, these ideas became too connected to remain separate observations.
They formed a model.
And that model became my new book: Signal Architecture: Refactoring the Human Operating System of Distributed Teams.
The book examines organizations through concepts such as signals, human nodes, context, persistence, latency, routing, ownership, trust, and distributed decision-making.
But underneath all of that is a very human argument:
People shouldn’t have to carry the architecture of the organization in their heads. The system should help them.
Important context should survive conversations.
Decisions should survive meetings.
Knowledge should travel beyond experts.
Ownership should be visible.
Managers shouldn’t have to route every signal.
Teams should be able to operate when someone important is unavailable.
And good people should be able to spend more of their attention creating value rather than compensating for organizational friction.
The Question I’m Asking Leaders
I’m not suggesting that organizations can be engineered perfectly.
Human systems are far too complex for that.
But they can be designed more deliberately.
So perhaps one useful question for leaders is:
How much of our performance comes from the design of our system, and how much comes from good people compensating for its weaknesses?
The answer may be uncomfortable.
But it may also reveal some of the most valuable improvements you can make.
Because great organizations aren’t created simply by collecting talented people.
They emerge when talented people operate inside systems that help their judgement, knowledge, and effort travel.
Good people shouldn’t have to compensate for bad systems.
We can design better ones.