How to increase the chances of success in a team (part one)
When I started studying Computer Science, I used to say as a joke that I chose IT because I just wanted to deal with computers, not with people. The truth is, in the end of the day, to work with IT, effectively communicating with other people is pivotal: we work in teams, we ship projects to our clients, we answer our bosses and we have to deal with expectations, frustrations and different personalities.
In my short career, I've had the opportunity to see my own team and other teams failing when it comes to effective communication. Suddenly, we see ourselves in the middle of a shooting of problems and fires, or we start focusing only on delivering a specific feature and we end up forgetting to deal with one of the most important parts of software development: people.
A coworker once told me one thing that I always remember when we talk about projects:
A big chunk of the problems in IT projects come from people, not the software.
And I'm not saying that only other people are the problem. The thing is, it doesn't matter which project you're developing. It is being thought, defined, specified, designed and developed by people – and this involves us as well. Sometimes, it may be tempting to follow only what's written in our tasks, stories or in our specification, but understanding the process and the people that are part of this process is essential to increase the chances of success for the idea that's being transformed into software.
Sometimes we may not be conscious of the benefits of having a team that does not have communication barriers to realise the problems as soon as they appear, trust to share responsibilities, difficulties and tasks and motivation to give our best everyday, but one thing is certain: these factors make all the difference in a team.
This is why, after a small retrospective with myself, the chats that I had with my own team and with people from other teams that had problems and were able to solve them, or are walking towards the solution, I was able to point some aspects that can help things out.
1. Develop a team mentality.
Alright, maybe it's your first day and you're not comfortable with the people in your team. You're even making an effort to be able to remember the names of your new team mates, understand the tech stack and the domain in which you'll be working on for the next period of your life. Or maybe you're in this team for months, but you realise your teams' gears are not spinning as smoothly as they should.
Invest some time to try to understand which role each person in your team is performing. In a well-balanced team, you have experienced people and newbies. More technical-driven and more business-driven people. Experts and generalists. Find your team's weaknesses and strengths. Understand your own priorities, your team's needs and try to perform a role in the grey area between these two sets.
This kind of attitude shows that it doesn't matter if you're a new member, or one of the most experienced ones, you're a team player - and you're there to help out in whatever your team needs. Showing this kind of availability is essential, and it is an awesome example to set with your team mates.
Sometimes, writing scripts in perl is not what gets you out of bed in the morning, but it's what your team needs. Show your team mates that you are willing to face a few monsters for your team, or willing to face these monsters with their help. After all, monsters and problems can be huge, but they are not two.
A considerable number of teams that I talked with and that had problems, also had more people who would care more about their own development and their own personal priorities over their team priorities. I know, I know. By the end of the day, you may want to be a python developer, you may want to focus on security or high availability – but you're in an internal project that uses java. Learn how to balance your priorities with your team's priorities, and learn to put your priorities on the side when your team needs you.
Project teams, mostly, need developers that know how to work collaboratively, not stars – in a collaborative team, everybody has their own time to shine.
2. Show you care.
It may sound like nonsense. You're a developer, your work revolves around writing code. Or not. I've met my share of teams where there's almost no motivation because no one seemed to really care. This behavior spreads easily in a team, and it's one of the biggest reasons for a project to fail. Caring is linked to a lot of different scenarios, such as:
Caring about whether your project is succeeding or failing
One of the most common symptoms of a team where people do not care if the project is succeeding or not is a team where people complain that things are not going well, but no one is able to do anything to make these things better.
If no one cares, it doesn't make a difference if things are well or not. No one will want to get out of their comfort zone to bring improvements, solve problems or suggest solutions. When we have already accepted failure, things get even worse: you're stuck.
If the people responsible for a project realise their development team is not excited or do not care if the idea that's being developed is going forward or not, it's more than natural that their motivation gets drained and they also start doing things carelessly. This creates a vicious cycle that only makes the results and the relationship with the team worse.
Caring about the problems and fires that appear
Changing is uncomfortable. Complaining is always easier. The hard thing is having the atitude to change things for the better.
Every project has people who will answer for its success or its failure, and you'll not always be one of them: but you can share this responsibility. You can change things for the better. You can hear the people who are having problems, you can suggest improvements or you can be the one who solves these problems. Make a problems and fires backlog and prioritize them with your team.
It is of vital importance that the team leaders know they can count on you when things get ugly and, by extension, with the rest of the team. It's really common to see people disappearing when a problem appears. The result of these attitudes is the development of the "superhero" leaders, that do not feel comfortable trusting important tasks to no one else besides themselves – which also creates a vicious cycle, where only the leader is the one capable and willing to perform important tasks, and the other team members feel that they do not perform an important part in the team, are not involved in the parts of the project that really matter or are not recognized by the work they have been doing.
Caring about the happiness and the health of your team mates
Usually, it's easy to make someone else's life a little bit better. Before being professionals, we are people. Sometimes your team mate didn't have a good night sleep, or had personal problems the day before. Sometimes, they are having problems with some task. You probably also had days like these.
Look around and see what you can do for those people. That task may not be as challenging for you as it is for them, so maybe you can do it. Or even better: you can help them move forward with said task.
Showing that you know there are other people, that we all have our strengths and weaknesses and that we have our good and our bad days is extremely important for everyone to feel like they can count on each other when problems appear.
Caring, in the end of the day, is showing that you recognize other people, their ideas and aspirations, and you want to help them to be their very best. A team that has this kind of attitude between their team mates can develop a day to day a lot healthier and more pleasant – they can find good solutions to problems and solve them the most dynamic way possible in the moment.
