What Counts as Good Management Changes Every Time the Balance Sheet Does

They called themselves the Librarians. Leadership at the firm I worked for saw the migration off on-premise servers into the cloud as an opening, and stood up a new team with a mandate: extract the common functionality living inside every other team's code, normalize it, catalog it, and hand it back out as shared microservice libraries everyone would use going forward.

My team was one of several running internal-only systems. The Librarians kept circling anyway, trying to extract patterns built for an externally facing team and force them onto ours. I spent months finding reasons to defer. Not because I doubted their intentions. I understood the enthusiasm completely and wished, honestly, that it could work the way they wanted it to. What they did not understand was what it would cost us. The people who used our systems were the closest thing the company had to rock stars, and anything that added friction to their day would not be forgiven quietly. We had built our systems to deliver the green M&Ms and only the green M&Ms: precise, filtered, nothing extra sitting on the plate. That was the whole design.

Every technical leader who has sat in that particular seat knows the private math I was running. Say yes, and you inherit friction your best people will not tolerate. Say no, and you look like the team standing in the way of what leadership has just decided is progress. Almost none of us say that math out loud to another technical leader. We just quietly run it, over and over, one initiative at a time.

The version of this everyone repeats out loud is friendlier: management best practices evolve because we are getting smarter. Each new framework represents genuine progress on the ones that came before it. Staying current with the latest thinking is what separates the leaders who are still growing from the ones who have calcified. Say that at a conference and heads nod. It sounds like humility. It is actually the reason the Librarians were so hard to say no to.

Here is what that framing hides. A business condition shifts, funding tightens, an acquisition closes, an AI cycle hits, and the industry brands its response to that condition as the new definition of good management, not as a response to the condition. Leaders adopt it as though it were an upgrade to the underlying principle rather than a costume draped over it. In adopting it, they do not just add new vocabulary. They retrofit the real structural work they already had into that vocabulary, and the retrofit dilutes the principle underneath it: empowerment becomes we removed the manager layer, efficiency becomes headcount ratio. It buys short-term legibility to whoever is currently doing the scoring. Then the cycle turns, the fad reverses, and the leader who staked their identity on staying current does not just look outdated. They look structurally naked, because what they built was optimized to be seen by the last judge, not to survive on its own.

The Librarians effort eventually stalled, the way most of these do once it runs into teams that have been autonomous long enough to have real, hard-won reasons for working the way they work. Years later, that same organization became a vocal proponent of Modular Monoliths, the architectural pattern that explicitly rejects the full decomposition centralization requires. Not a purely technical reversal. An admission that the coordination cost of the centralized version had been higher than the plan assumed all along. The swing itself was not a failure of judgment on either side. It was a Structural Bearing: centralization optimizing for consistency, decentralization optimizing for responsiveness, both legitimate, trading one failure mode for the other depending on which one currently holds the floor.

The leaders who navigate this well do not look different from the ones who get burned by it. They stopped treating every new mandate as either a threat to repel or a truth to obey, and started asking a narrower question instead.

The system needs an explicit function for this, not a personal habit of staying current. Something has to sit at the boundary between the operating system your team actually runs on and whatever the organization is currently calling good management, and make a deliberate call: does this new thing have real value to add to the operating system, in which case you integrate it on purpose, or does it not, in which case you absorb the demand and translate it so the operating system underneath stays intact. This is Signal Staging: the continuous judgment about which incoming signal from outside has matured into something worth transmitting into the architecture, and which one needs to be held at the boundary instead. Skip this function and you get one of two failure modes. Either everything gets let through, and your operating system gets rebuilt from scratch every time the cycle turns. Or nothing gets let through, and you look stagnant to the people scoring the short-term view, whether or not the work underneath is actually strong.

Think about the last new practice, framework, or mandate that came down from above your team. Did you make a deliberate call about whether it actually improves the operating system you run, or did you just adopt the vocabulary because that felt safer than explaining why you had not.

I write about structural leadership for technical leaders in high-stakes operating environments. The full operating model is in LeadershipOS: http://TheLeadershipOSBook.com

---

I write about structural leadership for technical leaders in high-stakes operating environments. The full operating model is in LeadershipOS: http://TheLeadershipOSBook.com