Change Fatigue
Hey!
Welcome back to another week of musings. This will be my last newsletter of the year! I'll leave you to rest for the remaining two weeks.
We'll see each other in the new year! I wish you happy holidays and an uneventful time with your loved ones.
Was this forwarded to you? You can subscribe here!
Things I discovered in the past week
"Rules" that programs in the terminal follow a post by Julia Evans.
A Practical Guide to Executive Presence: I've been reading about executive presence and found this one interesting.
This past week, we celebrated the year's achievements and discussed 2025 goals, roadmap, etc.
During the whole day, we had an exercise of things to start, stop, and continue doing during the following year. Among those things, multiple people called out "no more migrations," "no more upgrades," and "less changing priorities." That made me think that while our work and a lot of us like change, it seems there's a limit to these changes.
Another thought that crossed my mind was that I could see how "priorities are always changing" for most people, but for me, I felt that they never change or don't change fast enough.
One thing that happened for all these migrations was that we never kept them regularly updated, which meant that once critical vulnerabilities started to appear. We risk updating them at the moment, which is vital for other operations to be blocked. What ended up happening is that all these updates had to occur in the relatively same time frame, e.g., Q1-Q2 of the year.
On the flip side, we need to update these tools regularly to avoid this. That means changing how we work, aligning with the product, including all these updates that need to happen during the year, and providing the upgrade windows for all teams, etc. And what I've seen when we have wanted that in the past is that either people don't want to change how they work, or no one wants to take on that "boring" work of leading change to a process, a very intangible thing, especially if you're looking for a promotion.
I tend to make a case for leadership to explicitly reward "reducing tech debt," "keeping tools up to date," and other invisible tasks via the promotion ladder description.
Another noticeable aspect of change fatigue is when developers want to be more efficient. That generally means aligning with teams they depend on, releasing often, etc. If we've kept the status quo in our development or release pipeline, we'll find a lot of resistance to changing this. People have developed "coping mechanisms," basically hacks to work around the issues and inefficiencies. Changing how everything works means relearning the process and rebuilding these hacks. Nobody has time for that.
The other common complaint was changing priorities; I've noticed that the actual priorities don't change. Teams tend to get blocked, delayed, and everyday things during software development. What these situations create for leadership is that they're often asked to "unblock" or "deliver this project this quarter, " making them disrupt people and change their priorities to add more people to a problem. If you're in a team critical to the release of features, then you'll experience this more often than the delayed people. Teams that are delayed or constantly waiting for product input and other teams will rarely notice changing priorities as they might have tunnel vision toward delivery. They will probably have burnout from a different problem, not from changing priorities.
Your turn!
Have you ever had change fatigue? Have you asked your management or leadership to stop with the changes? Let me know your thoughts by replying to this email!
Happy coding!
website | twitter | github | linkedin | mastodon | among others