There’s few things more frustrating than working on a data system rife with legacy implementations, side effects, and questionable architecture decisions. Best practices on data teams are not exactly common. The optimist in me sees this and says “Cool. We have lots of room to improve things.”

The next step is to put together an implemenation plan that solves the pain points, typically with a mixture of best practices and new frameworks. This is usually received warmly as everyone is aware of the system’s shortcomings. However, somewhere in the middle of this process someone in charge inevitably asks something like this:

“This looks great. But we’re pretty used to these side effects and I’m not sure we should get rid of them.”

Often its things like having a staging area, protecting the master branch so no one can directly commit to it, or removing certain manual interventions into production.

The name for this kind of behavior is well known in psychological circles as “Loss Aversion.” We value losses much more than equivalent gains. Losing the ability to check code in directly to the master branch is valued much more highly than the accuracy and reliability that comes from branch based development.

Usually this logjam is overcome when the existing system becomes so unreliable that the team has no choice but to make improvements. Once those improvements become the new default everyone wonders why they didn’t do it sooner.

While eliminating this bias is not really feasible, limiting its effects is possible. When pitching these improvements I’m always looking to highlight how many problems will cease to exist afterwards. The gains feel invisible until they are spelled out. I always refer to things like branch protection rules as improvements in stability. Even if it feels like a loss, framing as an improvement can subtly shift the conversation. And advocating for improvements needs all the help it can get.