Have you ever wondered how your team members can be so incredibly brilliant and resourceful in some situations but also be totally surprised to hear that bug reports go in GitHub instead of Asana now (even though you’ve talked about it in three meetings, updated the bug reporting documentation, and personally reminded them every day for a week?)
It’s enough to make a person fantasize about rage quitting.
But what if their forgetfulness isn’t a malicious ploy to undermine your authority?
What if it’s more like a caching issue?
The data layer of the Leadership Stack is focused on the information your team needs to do their jobs. Bugs pop up in this layer when required information is missing, the available information is wrong or when cached information is outdated.
Today, we’ll focus on caching issues, as they are the most often misunderstood bugs in the data layer.
Just like your website works from the cache when possible to keep your site running fast, humans rely on memory to do familiar tasks. Most of the time that works great, but when familiar routines change, updating the brain’s cache isn’t always an automatic process.
Here are three common situations where brain caching can be a problem, and how to manually trigger an update.
Process Issues
Process caching occurs when you change how work is supposed to happen, but people’s muscle memory still routes them through the old flow. You roll out a new deployment pipeline, incident runbook, or code review policy—but under pressure, folks fall back to the way they’ve always done it.
The key to updating this kind of cache quickly is to make the new process easier, safer, and more rewarding than the old one:
- Integrate it where work already lives. Link the new steps from issue templates, pull request descriptions, or runbook pages instead of hiding them in a separate doc no one opens.
- Post clear, visual reminders near the work. Pin the new workflow in Slack, your team’s channel topic, or your internal docs home page.
- Reward early adopters. Call out people who use the new path in standup or retros. The behavior you praise becomes the behavior others copy.
Sometimes that’s enough to fix the issue. If not, either remove the old process entirely, or make it really annoying to use. For example:
- Remove direct links to the old flow so people have to work to access it.
- When someone reverts to the old process, ask them to redo the work using the new process. This will make you fairly unpopular in the short run, but “next time” reminders don’t stick as well as actually walking through the new steps.
This kind of caching can take awhile to settle after a change, especially if the old process has been in place for a long time. During that window, your job is to keep reinforcing the new path and systematically closing the escape hatches back to the old one.
Priority Issues
This type of caching occurs when you update team goals, but people still optimize their work for the old priorities. You say, “Reliability comes first now,” but engineers keep making tradeoffs as if feature velocity is still the main thing that matters.
Sometimes priority caching is just a trust problem: the team has heard “quality matters” before, then watched deadlines and roadmap commitments win every argument. From their perspective, the safe bet is to keep optimizing for the metric that’s historically gotten rewarded.
More often, the problem is that the new priority hasn’t been fully integrated into how success is defined, measured, and talked about. People are still carrying around the old story of what “a good engineer” or “a successful sprint” looks like, and your systems keep reinforcing that story.
Most team members will update their internal priorities when one of two things is true:
- The old priority is clearly deprecated. You stop using the old metric as a primary success measure. For example, you retire “tickets closed” or “story points completed” as the headline number and consistently lead with reliability, customer impact, or quality.
- Leadership explicitly holds both priorities and names the tradeoff. If you’ve actually added priority instead of replacing a priority, be clear about that. For example, you could say, “In the past we maximized speed. Now we’re intentionally trading some speed for stability.” Then be clear about how future decisions, promotions, and performance metrics will reflect the new balance.
Until then, people will keep caching the old priority—even if they can recite the new one back to you—because the old one is still what feels safest to optimize for.
Purpose Issues
Sometimes resistance is rooted deeper than process or priorities. It’s not about how work gets done or what gets measured—it’s about whether the work still matches why people chose this kind of job in the first place.
If you’ve ever tried to get non-salespeople to sell, or asked engineers who care about craft to crank out rushed features, you’ve seen a purpose-caching issue.
This one is the hardest to address because you can’t just clear the cache and update it. Instead, you have to frame the new work in a way that fits into your team member’s existing identities.
Let’s stick with the customer success example.
Say you want a technical support team to shift their focus from strictly debugging a technical problem in a ticket, to proactive solution architecture recommendations that identify high-value customer needs. The goal is no longer just closing the ticket but ensuring the customer’s long-term operational health—even if that means recommending a more complex, paid product solution.
If you want the team to push back hard, frame this change around internal revenue gains or individual financial incentive programs. That doesn’t fail because increasing revenue is a bad goal; it fails because most people in technical roles don’t see themselves as salespeople, and they’ll reject anything that feels like a forced optimization for a non-technical metric.
You hired these individuals because they value one or both of these things:
- Systemic Problem Solving: The intellectual satisfaction that comes from fixing complex problems at the root.
- Optimizing Customer Health: The drive to ensure a customer’s system runs reliably and efficiently.
To turn a support team into a customer success team, you must connect the new work directly to these existing values. Frame the new approach as advanced diagnostic work—moving beyond superficial debugging to identifying the architectural constraint (the missing feature, the wrong product tier) that is limiting the customer’s ultimate business goal. Once the new work reinforces their identity as a sophisticated problem-solver, they will be able to serve these existing values in new, profitable ways.
This works, but it takes time and requires a strong connection between the new work and the existing values. If the shift is big enough, it may be that the new work is a totally different job and requires people whose identity fits the new paradigm better.
In that situation be clear about the shift. Offer dignified and financially viable exits for people who aren’t comfortable with the new paradigm instead of trying to manipulate or gaslight people into doing work that violates their values.
Ultimately, resistance to change isn’t a flaw in your team’s intent; it’s a systems issue. By recognizing resistance as a process, priority, or purpose caching bug, you can stop repeating yourself and start applying a targeted fix.
If you want a debugging partner, I offer a focused Leadership Debugging Session to map your current system and identify where to focus your attention first.
If you are intrigued by the model, but don’t want to work on a specific problem, I’d still love to hear about the leadership challenges you face. These discussions are invaluable as I continually validate and refine the Leadership Stack framework against real-world systems. You can schedule a customer research session from here.