You are watching Marcus as he leans into his monitor, squinting at a call-to-action button that sits uncomfortably close to a block of descriptive text. Marcus is a senior software engineer with twelve years of experience in frontend architecture.

He knows that the current spacing is twenty-four pixels. He also knows that the visual tension would be resolved if the spacing were thirty-two pixels. To make this change, Marcus must open the global theme configuration file, locate the spacing scale, and determine if a thirty-two-pixel token already exists. It does not.

He must then draft a proposal for a new spacing token, submit it to the design system guild, wait for a bi-weekly review meeting, and hope that three separate stakeholders agree that thirty-two pixels is a necessary addition to the existing scale of sixteen, twenty-four, and forty.

Marcus chooses a different path. He opens the local component file. He writes a CSS override that adds eight pixels of margin-top to that specific button. He adds a comment that reads: “Temporary fix for layout tension; will move to theme later.” He saves the file.

The visual tension is gone. The button looks correct. Marcus has just created a shadow system. When the cost of following a process exceeds the cost of duplicating effort, competent people will always choose duplication. This is not a failure of character. It is a rational response to an over-governed environment.

The Single Source of Truth

The design system was originally built for speed. Three years ago, the engineering team realized they were building the same primary button fourteen different times across six different repositories. Some buttons had rounded corners; others were sharp. Some used a hex code for navy blue, while others used a slightly different shade of cobalt.

The inconsistency was not just a branding problem; it was a maintenance nightmare. Every time a global style changed, developers had to hunt through thousands of lines of code to find every instance of a button. The design system solved this. It allowed a developer to import a component and trust that it met all accessibility, brand, and performance standards. It worked exactly as intended.

When Consistency Becomes Drag

Then the system grew. It gained a governance board. It gained a contribution guide that is forty-two pages long. It gained a versioning strategy that requires a changelog entry for every minor tweak. These steps were not taken out of a desire to be slow. They were taken to protect the consistency that the team had worked so hard to achieve.

“This is how institutions begin to charge more than they deliver. You can see this phenomenon in almost any large organization.”

But at some point, the cost of using the system correctly began to exceed the cost of the duplication it was invented to eliminate. Nobody made a bad decision. Every step in the evolution of the bureaucracy was reasonable at the time. When you find a complex, multi-tabbed Excel spreadsheet running an entire department that supposedly has a multi-million-dollar ERP system, you have found the receipt for an institution that has become too expensive to use.

I remember a moment a few months ago when I was walking down a crowded street and saw someone waving enthusiastically. I waved back, only to realize a second later that they were waving at someone standing directly behind me. I spent the next three blocks thinking about the misinterpreted signal and the unnecessary energy I spent responding to a prompt that wasn’t meant for me.

Software governance often feels like that wave. We build signals and protocols for a version of the team that existed two years ago, or for a hypothetical scale we haven’t reached yet. Marcus’s override is the fourth such comment in that specific file. The oldest one is dated from twenty-seven months ago. It is no longer temporary. It is a permanent monument to a moment when the design system was too heavy to move.

The Architecture as a Straightjacket

At Digital Heroes, we often see this when we are called in for performance rescue engagements. A client will complain that their site is slow, or that their development velocity has ground to a halt. When we look under the hood, we don’t just find unoptimized images or heavy JavaScript bundles.

We find the debris of a design system that has become a straightjacket. We find hundreds of local overrides that are fighting the global styles. The browser is being asked to calculate a theme, then calculate an override, then calculate an override for the override. This creates a cumulative layout shift that frustrates users and a cognitive shift that frustrates developers.

We once worked on a project where the “system” was so rigid that the developers had started naming their local classes things like not-the-design-system-button. It was a form of professional protest. They were talented, competent people who were being forced to choose between doing a good job and following the rules. They chose to do a good job.

The danger of a “standardized” approach is that it assumes all problems have the same dimensions. But a marketing site built with Astro has different needs than a form-heavy workflow tool built with Remix. A headless Shopify storefront has different performance constraints than an internal dashboard.

The bureaucracy that was originally the acceleration eventually becomes the drag. This is the paradox of growth. You build the process to handle the mistakes of the junior staff, but that same process eventually stifles the brilliance of the senior staff. Marcus doesn’t need a meeting. He needs the ability to move a button.

If your design system requires a proposal for a margin change, you don’t have a design system. You have a legacy codebase that just happens to be written in a modern framework. When you make the right thing impossible to do quickly, you ensure that the wrong thing will be done in the dark.

The best systems are those that are designed to be outgrown, or at least modified, by the people on the front lines. The next time you see a “temporary” override in a file, don’t look for the developer who wrote it. Look for the process that made them feel like they had no other choice.

The margin that costs a meeting is a border that no one will ever cross.

The real work of performance engineering is removing the barriers we built for ourselves. It is about stripping away the “governance” that has become a ghost in the machine.

It is about giving Marcus his eight pixels back and trusting that he knows what he’s doing. Because at the end of the day, the user doesn’t care about your changelog. They care about how the button feels when they click it, and how fast the page responds to their touch.

Everything else is just noise.