An individualistic and detrimental approach to managing software projects is emerging among programmers and development teams. The focus of individuals seems to be solely on completing their own tasks as quickly as possible, without considering how this may impact the work of other team members and the fact that this aspect only brings temporary value to the project.
Completing tasks is not the ultimate goal
This approach may also be the first sign of poor management within the company. It occurs in projects that are heavily structured around tasks, where each person is assigned a task that must be completed as soon as possible, and their performance is evaluated based on this task.
That programmer is a war machine, they finish everything assigned to them in the morning and then move on to something else.
How many times have you heard this phrase and the widespread satisfaction from colleagues and management? But is it really so positive?
To achieve certain performance levels, individuals tend to be isolated, stripped of any concerns, in order to push them to achieve maximum results.
From one perspective, this is positive: all distractions, endless meetings, phone calls, and multitasking situations are eliminated in order to focus on the goal. However, from another perspective, the bigger picture is lost, and there is a risk of creating a toxic work environment that is highly individualistic, where people do not help each other or share their knowledge.
The fact that many programmers are inclined towards isolation when doing their work does not help this situation.
The racehorse syndrome
You can understand how easy it is, in an environment like this, to not notice the dissatisfaction or disconnect between different team members if you only look at short-term results. Just as a racehorse wears blinders to run fast towards the finish line without looking at the outside world, programmers are driven to complete their tasks.
The important thing is the completion of the task, not the economy of the project.
Rewarding individualism
Thus, individualism tied to tangible results is rewarded.
Unfortunately, a project also consists of a series of intangible results, such as knowledge sharing, collaboration, and personal and professional growth of the people involved.
The metrics dictated by management and many tools used in companies tend to evaluate everything that is tangible: the number of closed tasks, lines of code written, the time between the opening of a problem and its resolution. They rarely take into account intangible tasks.
Think about all the times you have helped a colleague overcome a problem, corrected a line of code that solved a long-standing issue, engaged in pair programming sessions, or shared a tip over coffee.
Therefore, it is necessary to think about projects holistically and try to detach from the logic of the task as the sole objective. A team works together to achieve a common goal. It is not the individuals who win, but the group that is able to continuously and harmoniously evolve and improve the product.
The problem of “completing tasks”
The real challenge is to transform a group of individuals, operating in an environment that rewards individual performance, into a team that thinks, acts, and works towards long-term goals.
Working as a team is not just a matter of soft skills, but also a matter of company culture and how individuals are evaluated within the company.
Creating isolated compartments benefits no one and must be balanced with activities that bring value to slower or isolated individuals, in order to help them improve culturally and personally.
When teams are composed of people with varying levels of expertise, if you can find a way to transfer knowledge from one person to another, it becomes an enrichment for both the project and the individuals involved.
For those managing a software project, it is essential to make the best use of people’s time in order to increase the value of the project beyond task completion.
It is essential to promote a collaborative culture within the team, where people can help each other and share knowledge.
Whose responsibility is it?
Promoting a collaborative approach is certainly the responsibility of management, but individual team members also play an important role in this process. It is crucial that project members are aware that their work is not just about completing their own tasks and going home as soon as possible.
In regular meetings, stand-ups, it is the responsibility of team members to inform others if there are any blocks or if they need help. Similarly, team members must be ready to help colleagues by sharing their knowledge and skills.
However, this aspect may not emerge spontaneously. Therefore, it is necessary for management to actively promote collaboration, identify these situations, and encourage people to work collaboratively.
What strategies can we implement to mitigate this problem?
There are various ways to prevent this approach from compromising the project’s economy.
When it comes to soft skills, it is important to include in the team individuals who have a natural predisposition for teamwork, who know how to work in a group, and who are willing to share their knowledge.
If a person completes their tasks and has nothing to do, they could be encouraged to conduct code reviews of other team members’ work, refactor recently added code, or provide mentoring and coaching to less experienced individuals. The performance of individuals should be evaluated based on these types of activities.
Managing superstars
In a perfect world, everyone can do their job, have lunch at home with their family, and play tennis in the afternoon.
In the real world, we face problems, and not all of them can be solved on our own. Sometimes it is necessary to seek help from so-called “superstar programmers”.
In this regard, I am reminded of a speech by Ottavio Bianchi to the Napoli football players when Maradona joined the team:
He is Maradona, and we are us. The problem arises if any of us wants to be Maradona. If we accept this, that he is him and we are something else, we can win. But if we do not accept it, or if any of us does not accept it, it doesn’t work.
Sometimes a superstar is needed to complete certain tasks. Imagine all the situations where you have faced a problem that someone highly knowledgeable on the subject could have solved in minutes, while it took you days.
In these cases, it is easy for the individual to work on well-defined tasks and not need, or have little need for, help from others.
The obsession with completing tasks by the superstar is not a problem, but it is crucial for management to be able to handle these situations and ensure that the work of the “superstar” is understandable and maintainable by all team members.
Therefore, it is essential for the team to subsequently analyze the code written by the “superstar”, review it, document it, and refactor it in order to make it understandable and maintainable by everyone.
The “assembly line” effect
We must avoid thinking of programming as an assembly line, where each person is responsible for a single task and has no responsibility towards others.
Why did you add this line of code that slows down the program?
Because it solves a security issue.
But didn't you realize you could have done it this way?
No, I didn't notice, it wasn't my task.Code language: PHP (php)However, be careful not to abuse the opposite approach, where as soon as a person completes their tasks, they are bombarded with continuous assignments or the completion of other people’s work.
This could lead to situations where people perceive increased stress and an excessive workload, which can prevent them from effectively managing their tasks.
Burnout is a real and tangible problem, and a poorly managed situation could lead to job dissatisfaction and the departure of the best individuals who feel overwhelmed by the number of tasks they have to complete.
Similarly, there may be people who intentionally slow down their work to avoid having to do the work of others. In these cases, it becomes crucial for management to handle these situations, ensure that the workload is evenly distributed among team members, and implement strategies to improve collaboration within the team.
Conclusions
A good programmer is not someone who completes all assigned tasks, but someone who is able to work collaboratively and share their knowledge with other team members.
It is necessary to foster the growth of the working group in which one is involved, and it is important for management to not only evaluate their results based on numerical data but also to manage individuals, listen to them, encourage them, and understand where the differences lie to bridge them.
The value that a senior brings goes beyond task resolution; it should extend to coaching and mentoring activities to help less experienced individuals grow.
This is the best way to ensure that the software project is successful and that the team can grow and improve over time.
