At a glance, each developer seems to be working with a computer. But there is an invisible teamwork that decides not only the organization’s executive force but also code quality and personal growth. As I go through many teams and meet various colleagues, I think I’m playing a team sport. Even if they’re the same front-end developers they play different roles. Someone has fast hands, someone makes good design, someone is very good at making UI, someone is a good mentor, and someone acts as a mood maker. Even when making decisions, it’s almost like a fantasy to have everyone technically agree on something. Depending on the team’s situation, experience, capability, or someone’s influence, it is subject to change. Given the same problem, every team comes up with different solutions.

I think that’s why teamwork is important. It is the driving force to respond with flexibility and recover quickly even during a problem. I believe the basis of teamwork is a sense of security and trust.

An Environment Where an Individual is not Blamed

When there’s a problem, it’s easy to blame someone who was in charge of the work or the developer who wrote the code. But this is a very bad culture that hurts psychological safety. Moreover, if you end up thinking that it’s an individual’s fault or mistake, the team will experience the same problem again in the future because they’ll only remember ‘who’ caused the problem, and not the problem itself. They wouldn’t separate the problem from the person and wouldn’t go deeper into the problem itself. Then the team members will get anxious hoping that they won’t become the next target.

After solving a problem, the former head of the organization always said this to encourage us, “Don’t do anything if you want to avoid the problem. Legacy works well, so just leave it be and do not engage in new challenges. But we shouldn’t do that. We must continue to grow. If you have a problem, you can come up with measures to prevent it from happening again and try again.”

My former manager also started meetings where the whole team gathered to discuss solutions for a problem by saying, “We are not meeting to blame anyone and question them. Anyone here could have made this mistake and that’s why we’re meeting to come up with a solution to prevent the same mistake from happening again in our team.”

When it gets revealed that someone was the cause of the problem, that person will defend himself by instinct. What other people say about him will sound like criticism toward him and his abilities. So if a leader creates an atmosphere where the problem gets separated from the person, an individual will feel a sense of security, and the team will be able to solve the problem and establish preventive measures based on this.

A Retrospective Done with Your Head

A cool-headed retrospective done after separating the problem from the person is just like growing pains. It may be embarrassing from that person’s perspective, but there is a sense of security that the arrow is not directed at himself, so there’s a chance for the team to deal with the problem together and recover by transparently disclosing what has happened to solve the problem and to prevent it from happening again.

In Grab, an open retrospective is done in a few weeks after a hotfix. A post-report needs to be filled out in advance before the retrospective. It needs to include the time the problem was dealt with, the impact of the accident, the cause, and preventive measures with as much detail as possible. During the one-hour retrospective, dozens of developers gather around and ask each other sharp questions and suggest solutions, and display collective intelligence. There is no room for equivocation.

When I attended the retrospective for the first time, it was so straightforward that even someone who isn’t related to the incident would feel it was brutal. But as I kept on listening, I could see that everyone was there with the same purpose. This is not a hearing, but a strategy meeting. If you take out your emotions and retrospect with a cool head, you can grow together.

The Attitude to Grow Together

Whenever my old mentor talked about programming skills, many times he would speak with the word ‘team’ as the subject instead of an individual. The overall code quality or the level of code review follows the team’s average level of skill rather than the best developer in the team. So in order to better solve the problem, not only does one person need to be good, but the whole team needs to grow together. Developers who constantly hold study sessions and are eager to participate in them to share their knowledge must know this.

Rarely, there is a developer like this. As soon as he joins a team, he would point out all the wrong parts of the legacy, do code reviews only based on his own standards and criticize the other team members. There is a saying that legacy was the best option until yesterday. If you see something you can contribute to the team, I think it’s right for you to persuade your teammates and spread your knowledge to raise the team’s average. If you separate yourself from the team, nothing will be beneficial for both sides.

People can very well distinguish someone who wants to stand out alone from someone who is truly dedicated to the team. There is trust between people who treat each other with good intentions and kindness, while someone who wants to do things well alone harms teamwork. That’s why a senior developer once said that character is the most important thing he sees when hiring someone, and a famous coach once said that you should hire someone not based on their abilities, but based on their attitude.