It is common for teams to struggle with tech debt. It is a raging topic at many tech conferences. Every time it is discussed, folks responsible for the success of their teams listen with rapt attention. They take back the learned ideas to their teams, attempt with renewed vigor, fail, and then go to other avenues, looking for the elusive elixir. The cycle is almost self-perpetuating.
Very few teams manage to transform a spaghetti code into a modular and well-composed version of it. But it has been done. This post is not a repository of ideas on how to do it. Instead, it is a brief note on the psychology of teams dealing with the problem and a possible remedy that could be attempted.
In India, when elephant trainers get their hands on a baby elephant, they tie it with a rope to a post. After repeated attempts to free itself, the elephant learns that it is futile. As the elephant grows up and acquires disproportionate strength, it fails to recognize that it is now strong enough to break the rope easily. Instead, it continues to rely on the trainer to remove the rope for movement. This belief of learned helplessness that the condition is beyond its control and cannot be helped with individual actions, becomes deeply rooted.
Learned helplessness is a behavior exhibited by individuals when they are faced with repeated failure or aversive stimuli for reasons outside their control. Individuals with learned helplessness believe that their actions do not change the circumstances and become accustomed to the ongoing situation. As a concrete example in the context of technology, an attempt to refactor code in absence of tests can result in repeated production issues that can result in negative consequences. Alternatively, the impact of a well-intentioned change in code can fail to make a positive impact if not built upon subsequently. This reinforced belief that individual effort does not matter and can lead to a “learned helplessness” on the team. The broken window theory reinforces this belief. It is plausible that because of this belief, even knowledge and up-skilling sessions don’t help immediately and individuals continue to work with unaltered habits resulting in the status quo.
So, how can one counter this? If we turn back to psychology, it is important to recognize that learned helplessness is a serious problem that cannot be solved without external support/intervention. Anyone who is already part of the system is not going to be able to shake their deeply rooted subconscious belief to make significant changes without external instigation.
To overcome learned helplessness, it is important to create a safe culture where mistakes are not only tolerated well but sometimes even encouraged. At Sahaj, learning by making mistakes is a rite of passage for every engineer — we trust people to learn by failing. In addition, it is crucial to reinstate the belief in being action-oriented. Instead of complex jargon and tech debt management strategies, what needs to be demonstrated is the power of small, collective, and repeatable actions that start a virtuous cycle.
As a starting step, it makes sense for the team to focus on regular actions and inputs rather than impact. For instance, everyone in the team can get together every day for 45 minutes to make minor (or even trivial) changes to the code to make small improvements. Small seemingly inconsequential changes snowball into behaviors that drive impactful changes. Simple things like renaming a variable, shortening a method, making a name more appropriate, combining parameters into a class, etc. Until it becomes a recurring habit or akin to a team muscle memory, somewhat like the Boy Scout rule “Always leave the campground code cleaner than you found it”.
Once the cadence is established, the next step is to solidify the purpose of the time spent together. Make the goal concrete for the team. Sometimes, it means establishing hard objective metrics that are short-lived and achievable, and at other times, it means more subjective agreements like a growing sense of improvements in the code quality. Lastly, provide guidance, knowledge, and direction that will help improve the outcome consistently by mentoring and working alongside to take everyone through the process and calling out observed improvements periodically, no matter how minuscule. The skills for refactoring slowly, safely, and patiently are not easy to develop — and it helps to see others do it (and struggle with it). Teams can use small time blocks to chip away slowly, and collectively, and yet continue to build trust in the actions of individuals as well as that of the team. Once a collective belief in small actions sets in, the improvement is more likely to become self-sustaining.
While the example here focuses specifically on tech debt, the key point of the observation is that in situations where learned helplessness is the root cause of a problem, knowledge, tools, and techniques will fail because they are not coupled with the belief that they will bring about a change. Instead, an external force, an agent of change that does not carry the burden of the historic context, must re-establish the belief in the power of individual action and change. This path requires a bit of faith. Once a continued effort of small increments leads to a bigger positive change, it can reinstate belief in the power of simple practices and techniques when executed with a bit of trust in the process.
