Being a Person in a Team from a Tech Viewpoint

Swiss Army Knife, Together we can do better (source)

According to Merriam-Webster, a People Person is “someone who enjoys being with or talking to other people” but in a team I think we can all agree that enjoying being or talking with other people is not enough, we should also make sure that the person we’re with is also enjoying being with us.

Working in a team is not easy. I am very sure a lot of you have experienced a situation where 1 person takes 99% of the work for the whole team. Well I mean the work is done, but it’s usually not the best. But the important part is that the team lacks good team dynamics. In this article we’re going to talk on how to create a good environment for your team, specifically in a team that works on programming or tech in general.

Team Dynamics

According to Cambridge Dictionary, a team is defined as “used in a number of phrases that refer to people working together as a group in order to achieve something”. While team dynamics can be defined as the unconscious psychological factors that can influence the team’s performance and behavior (source). In short having a good team dynamic means a better performance on the team and overall leave a positive impact for everyone. But how can we improve our team dynamics as a people person?

1. Communication

Communication is the first and the most important step of having a good team. Making assumptions is a natural human behaviour but unfortunately it usually does not end well for all of us, so rather than assuming why don’t we just tell the truth?. That’s why we should make sure that our team is always aware of what’s going on, nobody likes to be left with radio silence. Got any problems or concerns about your or other people in your team’s work? Communicate about it before it becomes an actual problem due to miscommunication.

2. Planning

Before you are going to do anything, let’s make sure that everyone is well aware about the plan. A bad plan is always better than having no plans at all since the cost is only going to be a revision of the plan instead of chaos ensued by the lack of plans. Share your ideas with the team, and be open to everyone’s idea to make sure everyone’s on the right track.

3. Be Supportive

Not everyone knows everything, but with everyone present we can know ask everyone about what they know about it. If your team member is having a problem and needs help, let’s help them and assure them that we can do it. Nobody likes to be left alone with a problem, it is also worth nothing that it is not just their problem but also your team’s problem.

4. Keep it blameless

Mistakes happen, and nobody likes to be blamed for accidental mistakes. Instead of blaming, is there something that we can do better? Fortunately there is, and it’s called “learning from mistakes”. Ask yourself and your team “Is there a way for us to prevent this from happening in the future?” is a great start to keep it blameless instead of asking who’s in charge for it. Being constructive is always the key.

5. Gratitude

Gratitude is defined as being thankful and showing appreciation to other people. At the end of the day as a team, the work is done by the whole team and not by one individual only. So for that, let’s show our gratitude to our team members for their hardwork! One simple act of kindness to anyone can motivate someone for the rest of their lives. Say thank you to your team!

Teamwork in a Tech Viewpoint

Team dynamics is an abstract concept for any kinds of team just like Sun Tzu’s Art of War is not only limited to actual warfare. But let’s talk on how we can bring a good team in tech, specifically software development with examples on what happened on my Software Engineering Project team.

Code Reviews

The main purpose of code reviews is to ensure better quality of the code. But it should not be the sole reason of doing code reviews. In a good team, code reviews are used as a learning opportunity while also sharing ideas with each other, this is where communication and being supportive comes into place as you are writing the code for the team and not just for yourself.

Being blameless also comes into place. Focus on the bad code instead of blaming the person who wrote it badly, give them advice and suggestions on what can we do about it. Bad code will always stay bad no matter how much blaming or how senior the ones who wrote it is, it will only turn good after it has been changed.

Example of a constructive code review, let other people know your concerns and what you think about it that can be a potential solution

In the end, the focus is on the bad code no longer there. In the end good code was written and both the reviewer and the programmer learned better ways on doing things

Incident Management

No software is 100% impenetrable (Single Event Upset), while a random radioactive particle from outer space inverting a boolean value is very very unlikely, it is mostly from us ourselves who wrote the code or created the system. While of course the first priority should be you and your team handling the incident first, the most important thing is to learn what happened, why it happened, and think of ways to prevent it from happening again in the future.

One popular method is called post-mortem culture developed by Google where one of it’s core values is blamelessness and learning. A post-mortem document is not always necessary if the incident is not big enough, but the learning part is always necessary. Talk with your team on what can be done to prevent it happening again in the future.

Our staging server went to a bit of a chaos due to an unknown error

A check is on progress, we found out that there’s a problem on the models’ migrations but we still didn’t know what caused the migrations to fail

After a series of debugging and trial errors. We solved the case and learned something new and very important. Moral of the story? Blame nobody and appreciate the value of learning.

Sprint Reviews

Sprint reviews is generally defined as a presentation session to stakeholders to show what has been done for the current sprint. But we don’t live in a perfect world, some sprint may not go well as planned which means some of the tasks are not finished in time. But remember to always be blameless, do not every tell the stakeholders any fault of your team member since it would only decrease the morale of the team. Instead what you can do is back each other up, call out the technical difficulties that the team faced and not just the specific individual.

Other than that don’t also forget to show gratitude to your team! A thank you slide dedicated for the team can impact your team’s morale in the long term.

Showing gratitude to your team.

Planning and Retrospectives

In Scrum methodology of software engineering there is a term for sprint planning and sprint retrospectives to keep everyone in line on what’s going to be done and what has been done. But team dynamics are still very important in this part. Sprint planning in short breaking down tasks into smaller workable tasks but not everyone thinks the same way about the weight of every task. That’s why it is important to let everyone voice out their opinions, one good way is to hold a Scrum Poker where the weight of every task is voted by everyone, and every concerns about any task is talked out to everyone, this is where planning comes into place.

At the end of every sprint there’s also retrospectives that is held specifically for everyone’s learning purposes outside technical. This is where openness and blameless values are the most important as we should always learn from our past as repeating the same mistake is always a greater mistake.

Some of the points that we pointed out together in our Sprint 1’s retrospective event. This was written together and most importantly discussed together

Conclusion

A good team is caused by good team dynamics which also implicates better performance and overall happiness of your team. To make a good team dynamic, most of the time it is necessary for everyone to communicate, plan, and be open to everyone. However mistakes happen but the focus is for you and your team to learn from it instead of blaming who is in charge.