You Didn't Run a Framework. You Ran a Mood.

September 15, 2026

You Didn't Run a Framework. You Ran a Mood.

I was in a software architecture conversation when an offhand comment, not about the software, about how my team actually operated, hit me with the idea. That evening, on the train home from Stamford to Milford, I took out a yellow legal pad, the same instrument I had been using for years to process what actually happened after a hard day, and I started writing.

What I wrote that night was not the five-layer framework I teach now. It was an early version that did not match what it is today, close enough to recognize in hindsight and rough enough that pinning down its exact shape would only confuse the story rather than clarify it. It took years of testing against real teams and real stakes before it converged into something else entirely. The moment Communication emerged as its own layer, separating cleanly from what became Cadence, Coaching, Culture, and Continuity, I felt something close to pure intellectual joy: pieces that had been tangled together for years suddenly holding their own shape, each one snapping into a structure that made every dependency between them make sense at once.

That process took years because I was testing a real question, not performing an exercise: does this pattern survive the leader's absence, or does it depend on the leader personally showing up to sustain it? Every rule I kept, every rule I discarded, ran through that same test. I still use it. It is the reason a framework built years ago can classify a rule I have never seen before, correctly, on the first pass.

Right now, a widely read essay is telling engineering leaders to do something similar: go back through your old management rules, one at a time, and ask whether each one assumed code was expensive to produce. Keep the ones that do not. Discard the ones that do. It is being treated as a fresh, necessary exercise, something every leader now has to run for themselves, from scratch, rule by rule.

Here is what that produces. Run the audit rule by rule, and each classification is a felt judgment call: reasonable in the moment, connected to nothing else. What comes out the other end is a list of keep-and-discard decisions, not a method. The test that produced the list was never written down, only its answers were.

Six months later, a new rule needs classifying, or a different leader inherits the audit, and the whole exercise resets and runs again from scratch. Nothing accumulated. The list from last time cannot be checked against the list from this time, because there was never a shared test connecting them, only one person's judgment, exercised repeatedly and never captured.

None of this means the leaders running that audit lack rigor. They are asking a real question. What they are missing is not intelligence, it is infrastructure, the same distinction that already separates Communication Infrastructure from communication as a behavior: when a practice depends on one person performing it, it is only as reliable as that person; when it is written down as a repeatable test, it survives them. The leader who never writes the test down is not protecting the organization from an untested framework. He is protecting his own judgment from being checked, because an unwritten test can never be argued with, only trusted.

Pick one management rule on your own team that you have quietly kept or dropped without ever fully explaining why. Try to write down, in one sentence, the actual test that decided it: specific enough that someone else could apply it to a different rule and reach the same answer you did. If you cannot, you did not run a framework. You ran a mood.

The LeadershipOS™ Scorecard runs that exact test against your own team, the same structural-versus-personal classification, not a generic system check: https://theleadershiposbook.com/scorecard

Anthony S. Jackson

Anthony S. Jackson

Anthony S. Jackson has spent 30 years inside technical organizations. He is the author of the Architecture Protocol Series: three books on the structural problems technical leaders were never told they would face. He writes the LeadershipOS™ Inner Circle, a monthly printed newsletter for CTOs and engineering managers who design teams that hold under pressure.

LinkedIn logo icon
Back to Blog