May 1, 2026 · 6 min
The Workaround Becomes the Curriculum
Patrick McClory
When a team doesn't understand their tooling well enough to trust it, they build around it. The build-around becomes what everyone learns. Nobody ever learns the tooling. The distrust gets baked into onboarding. New engineers inherit the wrong mental model and build on top of it. The workaround defends itself.
The Workaround Becomes the Curriculum
The Jenkins job that validates 35 other Jenkins jobs exists because someone, at some point, didn’t understand Jenkins well enough to trust it.
That’s the honest origin. Not malice. Not deliberate policy. A gap in understanding that got filled with code the engineer controlled, because code you wrote yourself feels more trustworthy than behavior you don’t fully understand in a tool someone else built. The custom validation job was the engineering equivalent of checking your work by doing it again differently. Reasonable instinct. Wrong solution.
The engineer who wrote it eventually left. And here’s where the snake starts eating its tail.
What Gets Inherited
The next engineer who joined the team didn’t get a history lesson about why the custom validation job exists. They got a pipeline with a custom validation job in it. They learned the system as it was, not as it was meant to be.
For them, “we validate with this job after the pipeline runs” isn’t a workaround. It’s just how the pipeline works. They never learned that Jenkins has stage gating built in. They never learned that the custom job was added because someone didn’t trust the built-in gating. They inherited the behavior without the context, and the behavior is now their mental model.
This is how institutional knowledge accumulates. Not through deliberate teaching, but through observation. New engineers watch how things work and learn from what they see. When what they see is a workaround, they learn the workaround. When the workaround is thorough enough and old enough, it stops looking like a workaround and starts looking like the right way to do things.
The misunderstanding has been promoted. It’s now the curriculum.
The Propagation Problem
Individual misunderstandings are tractable. You can identify them, correct them, move on. The person who didn’t understand Jenkins stage gating could have learned it. The gap could have been closed. It wasn’t, but it could have been.
Institutional misunderstandings are a different problem. Once a misunderstanding has been encoded into process and inherited by a team, correcting it requires more than learning. It requires unlearning, convincing people that the thing they’ve been doing, the thing they were taught, the thing that has worked reliably enough to become standard practice, is wrong.
Unlearning is harder than learning. The custom validation job isn’t just a technical artifact at this point. It’s part of how the team understands their own deployment process. It’s in the runbooks, if there are runbooks. It’s what gets mentioned in onboarding. It’s the thing senior engineers reference when explaining how things work to new ones.
Removing it now isn’t a technical decision. It’s a cultural one.
The Workaround Defends Itself
When someone eventually suggests removing the custom validation job, something predictable happens. The engineers who have only ever known the system with the job in place push back.
Not because they’re wrong to push back. They have a legitimate concern: they don’t know what the job is doing and they’re not confident removing it won’t break something. Which is exactly the problem. The thing that was added because someone didn’t understand the system has now been in place long enough that everyone has forgotten what the system does without it. The workaround has become load-bearing in the cognitive sense even if it’s not load-bearing technically.
The pushback isn’t obscurantism. It’s real uncertainty, produced by the same gap in understanding that created the workaround in the first place. The original engineer didn’t understand Jenkins well enough to trust it. Neither does anyone else now. The workaround didn’t close the understanding gap. It papered over it, for long enough that the paper became structural.
So the suggestion to remove it gets tabled. The workaround survives. The next engineer who joins learns the system with the workaround in place. The cycle continues.
Why This Is an Onboarding Problem
The moment a workaround survives long enough to be taught to a new engineer, it has escaped. It’s no longer contained to the person who created it. It’s no longer fixable by having a conversation with that person. It has been institutionalized.
This is why onboarding is the leverage point. What new engineers learn in their first weeks becomes their baseline for what normal looks like. If the workaround is part of what they learn, it becomes part of their normal. If the underlying capability is what they learn, the workaround looks like what it is: an unnecessary layer on top of something that already works.
Most onboarding processes teach people how to use the existing system. Very few teach people why the existing system looks the way it does, which decisions were deliberate, which were workarounds, which were historical accidents that nobody has cleaned up yet. That distinction matters. An engineer who knows the difference between a design decision and an accumulated workaround can evaluate both critically. An engineer who doesn’t know the difference treats them the same.
The fastest way to spread a misunderstanding is to put it in the onboarding materials and never label it as a workaround.
The Honest Fix
Fixing this requires two things that are both harder than they sound.
First, the technical archaeology. Go find the workarounds. Not just the obvious ones, the ones that have been in place long enough to look like features. Trace each one back to its origin. Understand what gap it was filling and whether that gap still exists. Evaluate whether the workaround is still necessary or whether it can be replaced by the capability it was working around. This is the work from the CI/CD pipeline post, applied to everything, not just the pipeline.
Second, the curriculum correction. When you find a workaround that can be removed or replaced, the removal is only half the work. The other half is teaching people what replaces it and why. Not just “we’re removing this job” but “here’s what Jenkins stage gating actually does and why we didn’t need this job in the first place.” The understanding has to get built somewhere. If you remove the workaround without building the understanding, you’ve created the conditions for the next engineer who doesn’t understand the system to build a new workaround in its place.
The workaround becoming the curriculum is a symptom of understanding that never got built and never got taught. The fix isn’t just removing the workaround. It’s closing the gap that made the workaround feel necessary in the first place.
The Longer View
Every engineering team has a body of institutional knowledge. Some of it is accurate. Some of it is workarounds that have been promoted to standard practice. The ratio of accurate knowledge to institutionalized misunderstanding tends to drift in the wrong direction over time, especially in fast-growing teams where the pace of onboarding exceeds the pace of knowledge maintenance.
The teams that stay healthy are the ones that treat their institutional knowledge as something to be maintained, not just accumulated. They ask regularly whether the things they’re teaching are the things that should be taught. They distinguish between deliberate decisions and historical accidents. They close understanding gaps when they find them rather than building on top of them.
The workaround that becomes the curriculum starts as a gap in understanding. It ends as a gap that teaches itself forward, one new engineer at a time, until the workaround is so thoroughly embedded in institutional knowledge that removing it feels like changing the culture.
Which, by that point, it is.