I Was Publicly Corrected on LinkedIn Last Week. He Was Right.

Last week, I was corrected publicly on LinkedIn. Not vaguely. Precisely.

I had argued that AI is doing something useful for engineering organizations: it's revealing which engineering managers were actually managing versus which ones were individual contributors with a title. The coordination layer was overhead, I wrote. Strip it, and you see who was doing real work.

Jake Lundberg disagreed. Publicly. Specifically. [Link to original article and exchange]

His argument: information routing isn't overhead. It's where a significant amount of judgment hides. His example was precise. Leadership hands him something still in flux. The call to not pass it down yet, because the direction will look materially different in 48 hours, is the actual work. Judgment about timing, about signal maturity, about when information is stable enough to be actionable rather than merely current.

His line: "strip the coordination and you don't just expose the judgment, you delete the surface some of it was living in."

I sat with that sentence for a while. Then I conceded publicly. Not because I was being diplomatic; because he was right, and I hadn't named what he found precisely enough to protect it.

What I want to do now is give his insight its precise name. What he described has one.

He found a structural bearing.

A structural bearing is a named organizational tension that doesn't resolve, only gets managed. The term comes from civil engineering: a structural bearing transfers load between two systems at their interface without merging them. Both systems remain distinct; the bearing is what makes it possible for both to function simultaneously.

In organizations, a structural bearing is the boundary point where two legitimate requirements meet and neither can fully prevail. Both sides are operating correctly. Their requirements are genuinely incompatible. The conflict between them is evidence that the system is working, not evidence that something is broken.

The bearing Jake named sits at the interface between how leadership operates and how teams need to receive information.

Leadership functions productively in ambiguity; that ambiguity is inherent to the role. Direction emerges. Priorities shift. Decisions that look settled on Tuesday look different by Thursday. A leader who waited for complete certainty before thinking would stop being a functional leader.

Teams operate on the other side of that interface. They need stable, directional signals to do their work. A team that receives information still in flux will either act prematurely and generate rework, or wait for it to settle and generate delay. Neither outcome is a team failure. The instability of the signal is the problem.

The engineering manager sits at that interface. The work Jake described: the judgment about when a signal from leadership is stable enough to transmit, is what I call Signal Staging. It is a timing judgment drawn from knowledge of how leadership's thinking actually develops, calibrated to protect the team from acting on information that will change before they can use it.

Most organizations don't strip this function deliberately. They compress it: as spans of control widen, as layers flatten, as AI tools accelerate the throughput of information, the dwell time that made Signal Staging possible disappears. The result isn't efficiency. It's raw leadership flux arriving at the team level at intake speed, without anyone assessing whether the signal is ready to move. Rework follows. The team learns to wait for things to settle before acting, which defeats the speed advantage the compression was supposed to create.

The leaders who manage this well are not operating differently from you in skill or effort. They stopped stripping the wrong things. They identified where their coordination layer was bearing load and protected that function specifically, rather than treating the entire layer as overhead.

This is what the structural bearing framework makes possible: precision about which tensions are designed to persist, and which functions are constitutive of the work rather than separable from it.

The routing of a signal and the judgment about when to route it are the same act. Automate the routing and you delete the timing judgment. A system that passes information downstream at intake speed is not a faster version of the previous system; it is a different system with different failure modes.

The diagnostic is direct. Look at your last major instance of team rework: not a quality failure, not a capacity issue, but a case where work had to be done over because something changed. Trace the signal that started the work. When did leadership make the call? When did the team receive it? What happened to that information in between, and who was assessing whether it was ready to move? If the answer is nobody, you have found the bearing point. The question is whether you stripped it intentionally or whether it compressed away and you haven't named the cost yet.

The September issue of the LeadershipOS™ Inner Circle goes deeper on Signal Staging as a structural bearing: the full Constraint Architecture diagnostic, the bearing mapped across the interface between leadership and team clocks, and what holding this bearing well actually looks like for an engineering manager whose organization is changing around them.

The Inner Circle is a monthly physical newsletter for technology leaders, mailed on the first of each month and designed to be read with a highlighter. Each issue installs one piece of leadership architecture: a named pattern, a diagnostic framework, and a tool you can put to work the following Monday.

The Edge Case ships the moment its current constraint ends. Subscribe by the end of July, remain current through September, and your copy ships to you when it does. That commitment is in print on the back cover of the July issue.

The window is July. LeadershipOSInnerCircle.com (http://LeadershipOSInnerCircle.com)

I write about structural leadership for technology leaders in high-stakes operating environments. If you want this depth every month in print, the LeadershipOS™ Inner Circle ships the first of every month. Reply 'maybe' and I'll send you details.

---

I write about structural leadership for technical leaders in high-stakes operating environments. If you want to see where your system is load-bearing on you personally, the LeadershipOS™ Scorecard maps it: https://theleadershiposbook.com/scorecard