Why choosing architecture over workarounds is intelligence in practice
Imagine you run a restaurant and there’s a loose floorboard near the kitchen entrance. Every new server trips on it during their first week. You could put up a sign. You could add it to the training manual. You could even station someone nearby to warn people. All of those things would reduce the number of trips.
Or you could fix the floor.
This is the decision that comes up constantly in enterprise web platforms, and it’s remarkable how often teams choose the sign.
Last year, a component update on a platform we manage for a client caused twelve pages to break. The root cause was a pre-release version of a component that went live before it was ready. Content editors on those pages didn’t do anything wrong — they published normally, and the platform served the broken component. The editors had no way to know.
The instinct after something like this is to prevent recurrence through training. Add a step to the publishing checklist. Send a reminder about component versions. Maybe create a Slack channel for platform alerts. All reasonable responses. All signs next to the floorboard.
We pushed for an architectural fix instead. The platform itself needed to prevent pre-release components from being served to production pages. No amount of editor vigilance should be required to keep the site stable. That’s a platform responsibility, not a people responsibility.
At Johns & Taylor, one of our guiding principles is Intelligence — and we define intelligence as the drive to elevate, not just inform. In architectural decisions, elevating means solving problems at the structural level rather than the behavioral level. Training addresses what people do. Architecture addresses what the system allows. When you fix the architecture, the problem disappears regardless of who’s in the room or how experienced they are.
This principle shows up in subtler ways, too. We were recently working through the implementation of a global footer component — the kind that appears on every page across a massive corporate site. The complexity wasn’t in the footer’s design. It was in how it interacted with other components in the page’s rendering stack. The footer needed to exist at a specific layer in the component hierarchy, and getting that layering right required a conversation about how the platform manages Z-index values across all components.
The workaround would have been to hard-code a Z-index value for the footer and move on. It would have worked — for now. But every future component that needed to interact with that layer would face the same ambiguity, and each team would make their own judgment call about what Z-index to use. Over time, you’d end up with a patchwork of arbitrary values, and some unlucky developer would spend a week debugging why a modal renders behind a footer that renders behind a tooltip.
The architectural approach was to step back and address component layering as a platform concern. Define the Z-index scale. Document which layers exist and what belongs in each one. Make the right choice the easy choice for every future component, not just this footer.
I’m not suggesting that every problem justifies an architectural overhaul. Sometimes the workaround is the right call — when the scope is truly isolated, when the fix is temporary and you have a plan to replace it, when the architectural change would block a time-sensitive release. Context matters.
But the default should be architecture, with workarounds as the conscious exception. Most teams default the other way. They ship the workaround, promise themselves they’ll come back and do it right, and then never do because the next deadline is already pressing. The workaround becomes permanent. The training manual gets another page. The floorboard stays loose.
The intelligence principle asks us to pause and consider: are we solving this problem, or are we teaching people to walk around it? If the answer is “walking around it,” we need a good reason. “It’s faster” isn’t a good enough reason on a platform that will exist for years and be maintained by people who weren’t in the room when the workaround was chosen.
Platform problems deserve platform solutions. Content editors shouldn’t need to be system engineers. Developers shouldn’t need to remember which Z-index values are “taken.” The architecture should make the right behavior automatic.
Fix the floor. Throw away the sign.
