Problem Overload
Hello!
I'm still dizzy from so much walking in Disneyworld and Universal Studios parks!
I hope you enjoyed your Holidays; if you are in the US, I hope you had some restorative time during the past weekends.
Was this forwarded to you? You can subscribe here!
As a topic, problem overload has been on my mind for a long time this year.
Shrinking teams
Due to layoffs or other events within the organization, we streamline our operations as much as possible. But in many cases, we can optimize very few things or even a single thing with fewer people.
This backlog of things to fix gets added to the standard "running the business"/"keep lights on" (RTB/KTLO) work.
Dreams die in the backlog.
This implies that it gets prioritized eventually or goes to the backlog to die. But also, in some cases, these are squeaky wheels! But in software organizations, only broken things get fixed. The squeaky wheels tend to stay around forever.
What ends up happening is that weekly (or daily), we talk about a topic that needs fixing but will never get fixed.
Negative feedback loop
This creates a negative feedback loop, where people feel the issue has no end.
I've seen cases where this negative connotation of not fixing the issue creates low morale among the team members, triggering thoughts of low agency or thinking that leadership never pays attention to problems that stop innovation and swift delivery.
Overwhelmed by the issues
The negative feedback loop is reinforced by the number of things that need fixing as time progresses and shrinking teams due to layoffs and people leaving because of no better future in sight.
We eventually end up with many things that need fixing, and we either become overwhelmed or jaded by the situation.
Choosing and Iterating
In the past, we've talked about creating change; in this case, it is the same thing. But the steps might need to be even more minuscule because it's probably a negative topic.
By choosing one, you're not saying no to the others, but rather "not right now."
Asking Leadership
The practical reality might be less favorable; even choosing small steps might never achieve a meaningful result given the need for teams to keep delivering on business needs, which might revert the small steps we have taken.
Especially if the organization needs to be aligned in those small steps and iterations, you should keep asking leadership for more people or driving a large change across the whole org to at least align on small steps.
Your turn!
Let me know how you handle these scenarios where reality sinks in and the future seems negative. Have you lived through these events? Please let me know what your thoughts are. Let me know by replying to this email.
Happy coding!
Things I discovered in the past week
- The necessary art of persuasion Effective persuasion becomes a negotiating and learning process through which a persuader leads colleagues to a problem's shared solution.
- Avoiding "Death by Calendar" as an Engineering Manager suggests that managers must prioritize their work and not let their calendars control them.
website | twitter | github | linkedin | mastodon | among others