Why Your Team's Problems Look Like Network Problems
Twenty years in engineering organizations, and I keep seeing the same gap. Teams spend years mastering version control, testing, and delivery pipelines, and almost no time on the skills that decide whether any of that work actually reaches the business: how a leader manages their own attention, how a team communicates under pressure, how that team stays aligned with everyone outside it.
We call these “soft skills,” and the name is part of the problem. It suggests something vague, personality-dependent, nice to have if you happen to be a people person. In practice, running a stand-up, giving feedback, or protecting focus time is just as systematic as running a deployment pipeline. It only looks soft because most of us were never taught to see the structure underneath it.
That structure is what the book is built on, using a metaphor every engineer already knows: computer networking. A computer doesn’t work as one undifferentiated blob of logic. It works because clearly defined layers, each with its own protocols, cooperate without needing to understand each other’s internals. A CPU doesn’t need to know how a network packet gets routed. It only needs its own layer to work, and to trust that the layers around it do the same.
Engineering leadership works the same way.
- CPU — the layer where you manage yourself: attention, task list, memory, habits.
- LAN — the layer where you manage your team: roles, growth, feedback, day-to-day collaboration.
- WAN — the layer where your team connects to everything outside it: stakeholders, other teams, customers, the organization’s shifting priorities.
Confuse the layers and the fix won’t hold. Try to solve a team communication problem with a personal productivity trick, or a stakeholder-alignment problem with a team-building exercise, and you’ll get the same result you’d get trying to fix a routing problem by reinstalling the operating system: nothing, plus wasted effort.
This series follows the layers in that order, CPU, then LAN, then WAN, because that’s also the order in which they tend to fail. A leader who can’t manage their own execution will struggle to lead a team, no matter how many team-building exercises they run. A team that can’t communicate internally will struggle to represent itself to anyone outside it. Fix the foundation first, or the rest keeps sliding.
Over the next posts we’ll go layer by layer, with the same practical, no-fluff approach: what breaks, why, and the protocol that fixes it.
If you want the full framework now instead of waiting for the series, The Engineering Protocol Stack is available on Leanpub.
And if your team is already past the individual stage, and the friction you’re feeling lives at the LAN or WAN layer, book a free 30-minute call and we’ll find out which layer is actually broken.