In this article, we will explain the concept of learned helplessness, how it usually emerges in software development teams, and why it is dangerous. After carefully reading the text, you will delve into the context of this issue and get some useful bonuses that you can apply yourself in practice.
- A clear algorithm of actions to overcome learned helplessness.
- A checklist that helps to independently assess the situation on your project and to understand what difficulties you need to work with and how to solve them.
How do you know that your team faced learned helplessness?If you feel in your bones that something is going wrong with your project, but can’t determine the reason, look at your development team and established processes. Consider if the company has the following problems:
- Really useful experience is not applied in practice and has been ignored for years.
- From release to release, the number of bugs increases uncontrollably.
- Your engineers do not write Unit tests and do not want to start this activity.
- Continuous integration and delivery (CI/CD) has not been implemented on the project, although the product exists for more than a year.
- Your developers have not proposed new solutions or approaches for a long time.
- There is a feeling that the project is in a state of stagnation. The team regularly faces the same problems.
- Your team is constantly engaged in putting out fires: being in a constant state of stress, it fixes bugs during production, which does not give engineers a chance to even try to implement improvements. This situation occurs every time from release to release.
If you find it difficult to determine whether there are problems, you can use our checklist to assess the situation on the project.
All of these factors are direct or indirect signs of learned helplessness — a dangerous state that many development teams come into. This is a serious problem for the entire project, and it is rather difficult to identify it independently and even more difficult to eliminate it.
Learned helplessness in the team poses a great threat to the company: such a problem can lead to software unscalability and uncompetitiveness, irrational and non-recoverable expenses for the work of unproductive specialists, and the occurrence of other serious risks for business, which we will tell about below.
How does the phenomenon of learned helplessness arise and why is it dangerous?
In addition to standard IT services for development and testing, our company provides a professional project management service, introduces new best practices, and analyzes the atmosphere in teams. A rich experience in consulting also plays a big role in JazzTeam expertise. When providing services, we often encounter the problem of learned helplessness in completely different teams. However, the mechanics of the occurrence of learned helplessness is most often similar and looks like this:
The complexity of the product increases over time. The number of components, as well as the volume of unresolved problems increase. At a certain stage, the team encounters a bottleneck in the software that cannot be stabilized and cannot understand how to solve this problem.
Technical debt (for example, the absence of Unit tests, CI/CD, test automation) accumulates with each sprint, and work on it is not carried out. The technical leaders of the project pay little attention to the technical debt, streamlining of processes and cultivation of engineering culture. They do not believe that modern techniques can be applied to your product, explaining this by the fact that the system is too complex or has some unique features (although in fact the implementation of best practices in development and testing is quite real and necessary).
The product code and architecture gradually become obsolete. At the same time, the owners see that the software is unstable and start to urge the team without realistically assessing the situation on the project. Engineers are constantly ‘putting out fires’ trying to ensure the release on time and eliminate bugs during the production. Even if the company has proactive specialists who offer useful innovations, their improvements are not applied, since the solution of problems here and now is always at the forefront.
The project does not have a culture of strategic improvement, so the team simply does not have the necessary skills and confidence that it is possible to get out of the situation. Initially, engineers try to change something, but because of a lack of in-depth understanding of the problem they struggle with symptoms rather than the source of the difficulties encountered. Getting no results, engineers stop believing in changes.
The founders understand that the team no longer feels enthusiastic about the project, engineers avoid communication and do not show proactivity.
This state of affairs on the project raises serious problems: employees have no motivation, they perceive each task as a punishment rather than a challenge. They are not productive, unable to develop your product and offer new solutions. You can say that you, as a founder, waste resources.
JazzTeam consultants saw dead projects with thousands of bugs many times. For example, such a difficult situation was discovered on the project carried out in cooperation with an Indian company. The team paid absolutely no attention to working with the technical debt and the introduction of techniques that could streamline the process of chaotic programming. At first glance, it seemed that the product was evolving. But as soon as full-featured testing started, it turned out that thousands of bugs had accumulated in the application. Moreover, the speed of discovering new bugs was several times higher than the speed of fixing them. The condition of the product was sad. Such a critical situation on the project resulted in a lack of value thinking, focus on improvements and strategic goals, combined with a high degree of learned helplessness within the team.
Unsolvable challenges: do they really exist?
Working on various projects, we often face situations when the whole team sees certain problems, understands that it is time to change something, but is not able to get off the ground. At the same time, there can be certain developments in a separate branch, but they have never been implemented. Engineers do not believe in changes and think that it is simply impossible to solve the pending challenges. But is that really so?
We believe that there are no problems that cannot be solved, and this is confirmed by dozens of successful cases we dealt with.
To prove that any problem can be solved, our team of consultants many times gave a task to Junior and even Intern Engineers who did not have psychological fears and tunnel thinking. We organized the process of their work and asked them to solve the problem applying best practices. Spending from 30 minutes to 1 hour a day, even an inexperienced developer managed to move a very complex and seemingly unsustainable technological debt off a dead point.
It’s not that the team doesn’t have time, or the tasks are too complicated and complex. The reason for all this is psychological difficulties that urgently need to be dealt with.
How to deal with learned helplessness?
Our company adheres to the principle of proactive management and constantly improves processes on various projects. Over the years, we have gained a lot of experience in resisting learned helplessness, so we clearly know how to bring teams out of this state most effectively. Based on our competencies, we recommend following the sequence of actions presented below:
- The first step in the fight against psychological patterns is to admit that the problem exists. And we often see confirmation of this in the companies that we consult. As soon as there is an understanding that learned helplessness exists or there is a lack of an innovative culture in the team, promotion, initiation of changes and discussions begin.
- As a founder or manager, you should have a clear understanding of the project’s status. Including peculiarities of technological complexities. You need to realize that your actions or inactions are also a source of problems. Take responsibility for the situation on the project, no matter how deplorable it may seem.
- Often, learned helplessness is a signal of grievances and ambiguities among team members. Analyze the following issues:
- Can your engineers speak openly about the difficulties encountered?
- Does the company have separate streams dedicated to working on the technical debt?
- Do you conduct retrospectives with the team? If yes, do you keep track of whether the decisions taken at the retrospective are applied?
- Do you admit that any team member can object to you as a founder and you will change your point of view?
All this will allow you to clearly understand the situation on the project and will indicate the vulnerabilities that most likely caused the emergence of learned helplessness.
- To combat the state of learned helplessness, it is necessary to involve a leader who will systematically deal with this issue. It can be a manager or a third-party consultant with relevant qualifications and technological expertise. A specialist who can think through a clear algorithm of actions to ensure gradual progress in the work on the technical debt. It is necessary to show the team that they can gradually make progress and achieve great results without enduring great losses step by step.
- Reduce constant pressure on the team and start systematic work on the technical debt by increasing the iteration time from one week to two weeks. Allocate time for understandable simple improvements (refactoring, code review, pair programming). After getting the first, even small results, the team will realize that everything is possible, employees will begin to believe in their strength and the success of the project.
- Implement regular retrospectives, one-to-one communication with employees. Often ask engineers what could be changed and improved. Believe me, there are no climate issues within the team that cannot be solved with an open, honest dialogue!
- Start transforming your culture. If the phenomenon of learned helplessness is discovered within the team, it is impossible to completely solve the problem locally by separate actions and improvements. It is necessary to radically change the cultural paradigm of the project and develop value engineering thinking in team members.
You should understand that some specialists on your project may already have serious mental prejudices. And these sentiments will affect other colleagues, including new employees of the company. In this matter, the role of a leader who will control the situation is very important. Even one team member who doesn’t believe in the changes can significantly reduce the effectiveness of the efforts put. Therefore, it is necessary to radically change the approach: to pay attention not only to technical improvements, but also to regular communication with employees, to build an atmosphere of honesty and openness in the team.
Be ready that in the beginning the team’s performance in terms of commercial deliveries will be slightly reduced due to the need to work with the technical debt. However, it is important to understand that if you constantly artificially accelerate the development process, you will really get results until the time comes. But sooner or later you will encounter a barrier that will bring very serious consequences for the project. The productivity of the team as a whole will decrease even more for an indefinite period. Without investing in the fight against learned helplessness, you will lose much more.
Need to solve the problem of learned helplessness? We are here to help!
If you feel that you are not yet able to cope with learned helplessness and would like to get the support of a leader with strong managerial and technological experience, we are happy to offer our help.
When implementing changes, our consultants act cautiously and reasonably. They try to understand all sides, harmonize the situation, introduce new approaches without losses and stress for the team. JazzTeam experts offer strong solutions that allow to start serious cultural transformations with little financial and time costs.
Regardless of your request and the types of services we provide, if learned helplessness is discovered on the project, we apply our skills to combat this problem and help the team to find a new impetus for development.
Within the framework of consulting activities, we implement various best practices, including CI/CD, Data Driven Testing, Unit Testing. We also synchronize stakeholders (our founder will help with this within zmicer.consulting) and contribute to changing the cultural paradigm in the team.