Organizations spend enormous amounts of time trying to hire great people.
We search for high performers. We assess technical competence, leadership potential, cultural fit, and communication skills. Then, when we finally assemble a talented team, we expect performance to follow.
But there is a problem.
Great people do not automatically create great organizations.
I have worked with and led engineering teams across different industries, countries, and organizational structures over the past two decades. One pattern has become increasingly difficult for me to ignore:
Sometimes the people are not the problem.
The system around them is.
When Good People Produce Bad Outcomes
Imagine joining a team filled with capable people.
Everyone knows their job.
Everyone wants to succeed.
Yet a decision made on Monday is interpreted three different ways by Wednesday.
Someone misses an important dependency because the relevant conversation happened in a meeting they did not attend.
A manager becomes the person everyone calls when they need context.
Teams spend another meeting discussing something they thought had already been decided.
Work gets done, and then gets done again.
Eventually, somebody concludes:
We have a communication problem.
So the organization responds by communicating more.
More meetings.
More Slack or Teams messages.
More status updates.
More channels.
More reporting.
But increasing the volume of communication does not necessarily increase understanding.
Sometimes it simply increases the noise.
Think About the Organization as a System
My background is in software architecture, so I naturally look at these problems through a systems lens.
If a distributed software system repeatedly lost messages, introduced unpredictable latency, depended on one component for every transaction, and stored critical state only in volatile memory, we would not tell the servers to communicate better.
We would examine the architecture.
Yet organizations routinely experience equivalent problems and treat them primarily as people problems.
That is the shift I believe leaders need to make.
An organization is not simply a collection of people.
It is a system through which information, decisions, context, ownership, and trust must travel.
And that system has an architecture, whether anyone deliberately designed it or not.
The Office Used to Hide Some of This
This is one reason remote and distributed work has been so revealing.
In a shared office, proximity could compensate for weak architecture.
You could walk over to someone’s desk.
You could overhear a useful conversation.
A manager could quickly clarify what somebody meant.
A five-minute corridor conversation could repair an ambiguous decision.
These were effectively human workarounds.
Then teams became distributed.
Many of those workarounds disappeared.
Suddenly, organizations started experiencing problems with alignment, context, decision-making, and ownership.
Remote work received much of the blame.
But in many cases:
Remote work did not break the organization. It exposed it.
It revealed how much of the organization’s operating system had depended on proximity.
Communication Is Infrastructure
This leads to an important distinction.
Communication is not merely a soft skill.
At organizational scale, communication is infrastructure.
A healthy communication architecture should answer questions such as:
- Who needs this information?
- Where does a decision become durable?
- How does somebody discover the reasoning behind it six months later?
- Who owns the next action?
- What happens when the person carrying the context is unavailable?
- How does a team know which signal is urgent and which can wait?
- How much information has to pass through a manager before work can continue?
These are architecture questions.
And poor answers create organizational latency.
Your Manager Should Not Be the Internet
One failure mode I have seen repeatedly is what I call the manager-router.
Almost every important signal passes through one person.
Need a decision? Ask the manager.
Need context? Ask the manager.
Need another team’s help? Ask the manager.
Need to know why something was designed that way? Ask the manager.
At first, this can look like strong leadership.
The manager knows everything.
But architecturally, you have created a bottleneck and a single point of failure.
As the team grows, the manager becomes increasingly busy while everyone else becomes increasingly dependent.
The organization has not scaled leadership.
It has scaled routing traffic.
From Communication Volume to Signal Quality
This is why I believe leaders need to stop asking only:
How can we communicate more?
and start asking:
How can meaning travel better?
A good signal reaches the right people, carries enough context to be interpreted correctly, survives beyond the conversation in which it was created, makes ownership visible, and enables action without unnecessary routing.
That is very different from simply sending another message.
Architecture Changes the Leadership Question
Once you see an organization this way, many familiar management problems look different.
Slow decisions may be a latency problem.
Constant interruptions may be an attention-routing problem.
Knowledge trapped in someone’s head may be a persistence problem.
Managers involved in everything may indicate a centralization problem.
Repeated misunderstandings across teams may reveal an interface problem.
Meeting overload may be compensating for poorly designed information flows.
None of this removes human responsibility.
People still matter enormously.
Culture matters.
Leadership matters.
Trust matters.
But architecture determines whether those things can operate effectively at scale.
Design the System
This thinking became one of the foundations of my new book, Signal Architecture: Refactoring the Human Operating System of Distributed Teams.
The central argument is simple:
People should not have to carry the architecture of the organization in their heads.
The system should help them.
It should preserve context.
Make ownership visible.
Reduce unnecessary routing.
Protect attention.
Clarify interfaces.
Allow decisions and meaning to survive beyond meetings.
Because when the architecture improves, talented people can spend less time compensating for the organization and more time doing the work they were hired to do.
Great people matter.
But great people operating inside badly designed systems will eventually encounter the limits of those systems.
Do not just hire better people.
Design a better system for great people to operate within.