One of the most common interview questions software developers get asked is whether or not they consider themselves a good team player.
And although this question is a bit generic and overused, it’s asked for a very good reason: Teamwork is an important soft skill for developers.
Most of your career as a programmer will be spent working with other people on a team.
We’ve already talked about how to get along with your coworkers, but there is a different dynamic when those coworkers are actually fellow members of a team.
Effective teams can be more effective than the abilities of all the individuals combined.
This is called synergy.
Ineffective teams can be less effective than the least effective person on the team.
This is called you are all getting fired and the project is doomed, so you better start looking for another job.
All it takes is for one bad apple to spoil the bunch.
This chapter is about making sure you are not the bad apple.
Teams Succeed Or Fail Together
The first thing to understand about teams is that teams fail or succeed together.
You’ve heard there is no “i” in team, but the truth is much more than that.
Any team where the members of that team feel like they are in competition, or where one member can succeed while the others fail or vice versa, is going to immediately be in jeopardy, because it is human nature to serve our own best interests first.
When teams have their fates tied together, and failure or success is at the team level, not the individual level, the best interest of every member of that team is the same as the best interest of the team.
We live in the real world and I realize that doesn’t always happen. You may not even have control over how the success or failure of your team is determined.
Your boss or organization may have put you on a team where each member is rated individually and the whole “we are in this together” attitude is difficult to maintain.
That doesn’t mean there is nothing you can do about it.
You can be the one to step up and suggest that the team would be more effective if the team members were bound to similar fates and success was derived at the team level.
You can unofficially carry this attitude in how you operate on the team.
You can set the example by acting and speaking in such a way as to indicate that you believe that the overall success of the team is more important than the success of any individual on the team.
You can choose to exhibit the team spirit by slowing down to help a fallen teammate rather than take the gold medal for yourself.
One person’s influence and example can be powerful.
Teams Have Common Objectives
Not only are teams’ fates tied together through success and failure, but good teams have common objectives.
One of the biggest problems I see with software development teams is that they too widely disperse tasks among the team members.
Far too many teams adopt a divide and conquer approach instead of a swarm and destroy approach.
Don’t get me wrong: too many cooks can spoil the broth, but it’s ideal to have a team work together as much as possible.
Not only does working together help to enhance the feeling of a unified fate, but it can often bring about more synergistic outcomes.
If everyone on a team is working in isolation on their own tasks, and not actually working together, there isn’t much teamwork happening.
Sure, there may be a common larger objective of getting the project done or completing the assigned work for the week, but the actual benefits of having a team are not being realized.
Again, real world. I know.
You may not have direct control over the objectives of your team.
You can still influence them.
One of the things you can do as a software developer on your team is to make sure that you don’t pick up new work when you can contribute to work that is already in progress by another team member.
In an Agile development environment, this means not picking up a new backlog to work on by yourself, but instead to go and find team members working on a backlog already and help them complete that backlog before moving on to the next.
In the Kanban style of software development, this is known as limiting the WIP, or work in progress, and it’s an effective technique to get more backlogs flowing through the pipeline faster.
Take Responsibility For The Team
Not everyone on a team is going to understand the idea of what makes a good team and what teamwork is, but that doesn’t prevent you from doing what you can to help make the team succeed.
It’s tempting to focus on your own goals and objectives and put those of the team secondary.
In fact, many software developers erroneously believe that by looking out for number one, they’ll be doing the best thing they can for their career.
This is rarely the case.
Although individual performance is important, most software development managers are more concerned about the overall performance of the team.
It does no good to be the all-star MVP player on the lowest-ranked football team in the league.
Sure, everyone will know how great you are, but your team will still lose, which means you will still lose.
An individual can only do so much.
Even the best software developer has a maximum amount of effectiveness he can produce by writing his own code or doing his own job.
An exceptional software developer is a developer who makes everyone else around him better, and improves the ability of his entire team.
If you really want to get noticed and be the kind of software developer everyone wants to hire and have on their team, be the kind of software developer who cares more about the ability and performance of the entire team rather than your own.
This involves taking responsibility for things you may not have direct control over, and it’s not easy.
Jerry doesn’t work. He just sits at his desk all day and watches cat videos on the internet.
You could say “Screw Jerry,” and do your work as best as possible and just let Jerry fail to get anything done.
But what does that do to the team?
Again, you might perform great as an individual programmer, ignoring lazy Jerry, but when the status of the project is reported and all your work is done but the objective for the team is not met because Jerry didn’t pull his weight, your victory is going to be quite empty, isn’t it?
Instead, even if you aren’t asked, even if you aren’t the team lead or manager, take responsibility for the whole team––including Jerry.
That doesn’t mean that you have to go over to Jerry’s desk and call him a lazy asshole, but it does mean that perhaps you should go over to Jerry’s desk and ask him what’s wrong or if there is anything you can help him with.
It might mean that you have to encourage Jerry and other team members by reminding them you are counting on them and so is everyone else.
It might mean that you have to go out of your way to mentor other developers and help them bring their skills up to par.
Taking responsibility for the team is not an easy task, but it can make a huge difference on not just the team itself, but your career.
If you are known as the kind of software developer who not only gets their work done and does a great job at it, but brings up the performance of the entire team, you’ll never have a problem finding a good job, and you’ll not be overlooked for promotions.
Communicate And Collaborate
As a software developer, it’s easy to adopt the attitude of just tell me what you want done, leave me alone, and I’ll do it.
It’s easy to hide in your cave and crank out some code by yourself, finally emerging when it’s all done and tested––you did test it, right?
But being part of a team means communicating and collaborating.
To be an effective team member, you need to be an effective communicator.
You need to let other team members know what you are working on and any issues you are encountering so that you can benefit from and contribute to the collective knowledge and ability of the team.
Really, that’s the whole point of having a team.
It’s not difficult to do, but you have to develop the habit.
Instead of working solo, try to work with other team members as much as possible.
Yes, I know you could code up that feature much faster by yourself and that Fred is going to slow you down, but by working with the less experienced Fred, you’ll be bringing up his skill level, even if it slows you down a little.
And Fred, although less experienced, may see things differently than you do, and may notice something obvious which you overlooked, saving you hours of time.
Be Honest, But Use Tact
One of the worst kinds of teams is a team where everyone is exceedingly polite and no one ever directly opposes anyone else’s opinions.
It’s human nature to try and avoid conflict as much as possible, but a healthy team––like a healthy relationship––has some degree of good conflict.
If you want to be a valuable member of a team, you can’t go around blowing smoke up everyone’s asses.
When something is wrong, or you have a differing opinion, you need to state it.
When a team member isn’t pulling his weight and it’s slowing down the team, or another team member is causing disruption, which is preventing the team from reaching its objectives, you can’t stand idly by and think, “it’s not my problem.”
It is your problem.
It’s everyone on the team’s problem.
Remember, teams succeed or fail together.
So, be honest.
Say what is on your mind.
Don’t mind your own business.
But use tact––please.
The same message can be communicated in a variety of ways.
Healthy conflict comes from communicating opposing ideas or dealing with issues in ways that don’t directly personally attack the other person.
Before you say something, think about how it will sound.
Think about how you would feel if a team member said to you what you are about to say.
Tread carefully. Words can do a large amount of harm.
They can also do good, so choose to use them for good.
Remember, plenty of software developers can write code, fix bugs, and develop software in isolation, but if you really want to be as effective as possible, and you really want to have a successful career as a software developer, you need to learn to work on a team.
