How to be an effective team player

I’ve had jobs as a developer where I had teammates who were great people, but we did not work well together. Not because we were bad at it but mostly because the culture of that workplace did not reward or incentivize working as a team — or working well as a team.

However, there were always those people who would** **stand out, manage to overcome such work cultures, and show that working well as a team is not only effective but highly rewarding. Nowadays, I’m privileged enough to be working in an environment where teamwork is much smoother, constant, and rewarded, and I can see the difference is huge.

“Working effectively together feels good. It may be a new experience in the workplace for some.” — Kent Beck in Extreme Programming Explained

Regardless of your work environment, being able to work well with others will always make you stand out, get the best results out of your efforts, and become a reference on your team. So, here’s what great team players do to achieve this.

1. They Communicate Effectively With Non-Technical People

Whenever talking to non-technical folk, avoid using too many technical terms or an unnecessary level of detail.

This seems obvious at first, but I’m pretty sure you’ve already told some PM or PO about a bug or a technical challenge only to be met with a confused facial expression followed by a question along the lines of “OK, is this a blocker?”

Whenever you find yourself in this situation, always provide small chunks of information that represent a comprehensive but simplified version of everything that you have to say. If the person you are talking to is still curious or not convinced, repeat the process with an increased level of detail. Keep doing so until you’ve made your point. This will also give you the opportunity to focus on the parts that the listener has the most difficulty understanding or finds most important.

This will save time for both you and whoever wants to know what happened in the depths of the technology you are working on.

Sad engineer after wasting a lot of time on an unnecessarily detailed explanation. A funny but incredibly true depiction of a real-life situation. Sad engineer after wasting a lot of time on an unnecessarily detailed explanation. A funny but incredibly true depiction of a real-life situation. Source: KRAZAM

2. They Communicate Well With Other Developers and Detect Learning Opportunities

Now, whenever you are talking with other developers, you certainly have more freedom to use statements that go well without any explanations. But not all developers have the same amount of seniority and, most importantly, familiarity with the technology that you are both working on.

In order to communicate effectively in this case, it is important that you tune the speed of your delivery so the other developer has time to at least tell you if you just went through something that they don’t quite understand. Especially when working with someone less experienced than you, it is important that you are able to pinpoint gaps in their knowledge so you are able to create short but concise moments of teaching.

If you are the less experienced developer or simply don’t know much about something that is being discussed, don’t forget to say so, as no one will be able to guess this.

The person who is learning will likely carry these very precise and self-contained moments with them throughout their entire career, so make sure you don’t rush when you are talking and make this conversation very interactive so you don’t lose such opportunities.

If you happen to work on a team where there is very little cooperation, try creating such moments of sharing somehow. Both teaching and learning are crucial to building knowledge as a developer.

3. They Are Egoless Programmers

This sounds fancy, but it simply means splitting your personal self from your work — both when doing your own work and when reviewing others’ work. Developers who nail this are able to consistently receive criticism of their work without feeling down about it or creating grudges.

“The most brilliant programmers alive working competitively in an ego-rich environment can’t get as much done as ordinary programmers working cooperatively as a self disciplined and self-organizing team. You need a process where team empowerment and collaboration thrive to reach your full potential.” — Don Wells on Extreme Programming

On the other hand, don’t be arrogant or mean when reviewing code or discussing solutions. Don’t use putdowns or any form of aggressive communication. Find problems in the code and criticize the work — not the author. Don’t state facts. State opinions, which is what they are. Make suggestions based on evidence or thoughts that support them.

“Don’t use put-downs, e.g. ‘That was the buggiest code I’ve ever seen.’ Be clinical when it comes to code that isn’t yours. Better: ‘There were a few bugs.’” — WikiWikiWeb

This also includes not trying to prove that you know some fancy feature from the language or design pattern. There are coders out there who write complicated stuff just to show off or maybe because that way the code would be super concise, brilliant, and… guess what: super hard for others to understand. Don’t do this. Good code is often dumb and simple. Let patterns emerge naturally and discuss big abstractions with others before forcing them into the codebase.

4. They Prevent and Destroy Knowledge Silos

Great team players have a keen eye for knowledge silos. Such silos occur when — probably due to working in isolation — a certain developer (or even someone with a different role) knows everything about a certain topic, while the rest of the team doesn’t.

Whenever you become aware that someone on your team ended up accumulating all there is to know about a certain feature or something else that is your team’s responsibility, invite them to share. This can be very easy and does not require a fancy document or presentation. A 30-minute meeting showing your own computer screen is good enough. If you really need to go async, a simple but well-written document in Google Docs also works well.

Photo by You X Ventures on Unsplash.

Pair programming can be a great way of fixing this problem altogether, as context will be shared naturally among developers or whoever takes part in such pair or mob programming sessions.

Wrapping Up

Working together effectively and realizing that a team is more than the simple sum of its members is highly rewarding and addictive.

Remember to communicate with as little noise as possible. Try catching daily learning and teaching opportunities and remember to leave your ego at the door. An environment of growth and fulfillment is not only made by company culture and incentives but also by small and daily interactions. Being aware of this and implementing small changes yourself is already a big step!

Featured image photo by Annie Spratt on Unsplash.