Is your team happy to work with you?
My own personal take on what makes for a good teammate these days
Hi there, it’s been a while since I sent one of these, sorry, but like I always say, I rather send you an email once every two months and add value, than send you crap every week.
So I hope today’s email falls into the first category!
Working as part of a team
There are very few people in our industry who can really do all the work by themselves, so we usually tend to gravitate toward building teams. Be it because we’re forced by our employer, or because we find like-minded individuals who provide us with the skills we lack.
Whatever the reasons might be, being a “good part” of a working team is a crucial skill all developers should actively work on.
Now, what makes a great teammate? That’s a difficult question to answer for everyone, since your context will definitely affect the way you interact with your team.
Are you part of a remote team? Or are you all collocated?
Do you all share the same native language or are some of you communicating using a secondary language?
Does your company foster competitive behavior for people to advance in their careers or is collaboration possible?
I’ve seen many different working environments during my 20 years of career, so I know it’s not as easy as saying “just be kind to one another”. Sadly, that doesn’t always work out for the best.
That said, I think I can still try to give you some insight into what makes a good teammate without sounding awfully generic.
Your Ego is your first enemy
Developers have a huge ego, there is no surprise there. You may be able to have it more under control than others, but the beast is there, lurking inside you and waiting for you to set it free.
When you’re working as part of a team (which let’s be honest, happens quite often), you’ll do well to control it.
As developers we tend to believe all our solutions are correct and all our implementations are the best possible ones, and that couldn’t be further from the truth.
That can especially be seen when you look at the interaction between developers and testers. Mind you, you might be working at a company that has no specific “tester” role, but you should still be probably cross-testing your features or something. The point that the minute someone tells us “Hey, I found a problem with your new feature”, our initial gut reaction is to think “Fuck no, you’re the one with a problem, I closed that feature and it was working just fine, I tested it myself”.
That’s our ego talking, not us. We need to understand it and keep that “inner voice” inside :)
If you don’t accept that you might be wrong about something, you will never grow as a developer because you’ll keep making the same mistakes over and over.
You see, there are many ways of learning, not just Youtube or online tutorials, your teammates are a great source of knowledge, you just have to be open to receive it. That can only happen if you keep your ego at bay.
I wrote more about this topic here in case you’re interested.
Understand how to work remotely with others
This point becomes more relevant every day, and it’s important to remember that many developers will be working remotely, whether you
agree with that or not.
Given the nature of our work, we don’t really need to all be collocated inside the same office to perform our work. In fact, some would argue that the best way to do our work is to let us work from wherever we want (and I tend to agree with that).
A very common scenario you might find these days, is to have hybrid teams, when some people are collocated and others are working remotely, even if it’s just a few days a week.
For you to be a good teammate for those remote colleagues means you have to understand what it means to work remotely, even if you don’t do it yourself.
Things like taking part in a meeting when you’re one of the few remote members can be a pain if your collocated colleagues will engage in local chit-chat while you’re trying to make a point over the phone. The remote teammate won’t be able to assess everyone else’s disposition or body language to understand whether or not they’re paying attention.
The same goes for understanding that a remote colleague might not share your timezone. I’ve been in teams where some of us had a 5-6 hours difference and we all had to understand that if we had the need to interact with one another, that small window of time when our schedules overlapped was the only time we could do it. So plan accordingly.
That or take matters into asynchronous communication, such as emails or long-lasting chat messages (only if the information is not critical and you’re expecting them to see that message the next day).
But never try to force your timezone into someone else’s life if you can avoid it. You might be sending that message or meeting invite at 3pm your time, but it could be 8pm for your colleague. Do not do this expecting an immediate response.
Being sensitive to other people’s situations and working arrangements makes for a great teammate.
Are your colleagues happy to work with you? Or be led by you? While obsessing over that question might not be the best idea, asking yourself that every once in a while might be good. Consider these two points and think about whether you’re being affected by them somehow.
What else would you say makes for a great teammate? Leave a comment with the link below if you feel like sharing, I’d love to know what you think about it!
BTW, if you agree with these points, you might want to consider taking a look at my latest book, “Skills of a Successful Software Engineer”, there I cover a lot more topics and advice about what will help you grow into a great developer.