The Programmer’s Guide to Working on a Team

One of the most common interview questions software developers get asked is whether or not they consider themselves a good team player.\n\nAnd 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.\n\nMost of your career as a programmer will be spent working with other people on a team.\n\nWe’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.\n\nEffective teams can be more effective than the abilities of all the individuals combined.\n\nThis is called synergy.\n\nIneffective teams can be less effective than the least effective person on the team.\n\nThis is called you are all getting fired and the project is doomed, so you better start looking for another job.\n\nAll it takes is for one bad apple to spoil the bunch.\n\nThis chapter is about making sure you are not the bad apple.\n\n

Teams Succeed Or Fail Together

\n\n\n\nThe first thing to understand about teams is that teams fail or succeed together.\n\nYou’ve heard there is no “i” in team, but the truth is much more than that.\n\nAny 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.\n\nWhen 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.\n\nWe 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.\n\nYour 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.\n\nThat doesn’t mean there is nothing you can do about it.\n\nYou 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.\n\nYou can unofficially carry this attitude in how you operate on the team.\n\nYou 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.\n\nYou can choose to exhibit the team spirit by slowing down to help a fallen teammate rather than take the gold medal for yourself.\n\nOne person’s influence and example can be powerful.\n\n

Teams Have Common Objectives

\n\nNot only are teams’ fates tied together through success and failure, but good teams have common objectives.\n\nOne of the biggest problems I see with software development teams is that they too widely disperse tasks among the team members.\n\nFar too many teams adopt a divide and conquer approach instead of a swarm and destroy approach.\n\nDon’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.\n\nNot only does working together help to enhance the feeling of a unified fate, but it can often bring about more synergistic outcomes.\n\nIf everyone on a team is working in isolation on their own tasks, and not actually working together, there isn’t much teamwork happening.\n\nSure, 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.\n\nAgain, real world. I know.\n\nYou may not have direct control over the objectives of your team.\n\nYou can still influence them.\n\nOne 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.\n\nIn 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.\n\nIn 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.\n\n

Take Responsibility For The Team

\n\nNot 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.\n\nIt’s tempting to focus on your own goals and objectives and put those of the team secondary.\n\nIn 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.\n\nThis is rarely the case.\n\nAlthough individual performance is important, most software development managers are more concerned about the overall performance of the team.\n\nIt does no good to be the all-star MVP player on the lowest-ranked football team in the league.\n\nSure, everyone will know how great you are, but your team will still lose, which means you will still lose.\n\nAn individual can only do so much.\n\nEven the best software developer has a maximum amount of effectiveness he can produce by writing his own code or doing his own job.\n\nAn exceptional software developer is a developer who makes everyone else around him better, and improves the ability of his entire team.\n\nIf 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.\n\nThis involves taking responsibility for things you may not have direct control over, and it’s not easy.\n\nJerry doesn’t work. He just sits at his desk all day and watches cat videos on the internet.\n\nYou could say “Screw Jerry,” and do your work as best as possible and just let Jerry fail to get anything done.\n\nBut what does that do to the team?\n\nAgain, 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?\n\nInstead, even if you aren’t asked, even if you aren’t the team lead or manager, take responsibility for the whole team––including Jerry.\n\nThat 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.\n\nIt 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.\n\nIt might mean that you have to go out of your way to mentor other developers and help them bring their skills up to par.\n\nTaking 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.\n\nIf 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.\n\n

Communicate And Collaborate

\n\nAs 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.\n\nIt’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?\n\nBut being part of a team means communicating and collaborating.\n\nTo be an effective team member, you need to be an effective communicator.\n\nYou 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.\n\nReally, that’s the whole point of having a team.\n\nIt’s not difficult to do, but you have to develop the habit.\n\nInstead of working solo, try to work with other team members as much as possible.\n\nYes, 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.\n\nAnd Fred, although less experienced, may see things differently than you do, and may notice something obvious which you overlooked, saving you hours of time.\n\n

Be Honest, But Use Tact

\n\n\n\nOne of the worst kinds of teams is a team where everyone is exceedingly polite and no one ever directly opposes anyone else’s opinions.\n\nIt’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.\n\nIf you want to be a valuable member of a team, you can’t go around blowing smoke up everyone’s asses.\n\nWhen something is wrong, or you have a differing opinion, you need to state it.\n\nWhen 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.”\n\nIt is your problem.\n\nIt’s everyone on the team’s problem.\n\nRemember, teams succeed or fail together.\n\nSo, be honest.\n\nSay what is on your mind.\n\nDon’t mind your own business.\n\nBut use tact––please.\n\nThe same message can be communicated in a variety of ways.\n\nHealthy conflict comes from communicating opposing ideas or dealing with issues in ways that don’t directly personally attack the other person.\n\nBefore you say something, think about how it will sound.\n\nThink about how you would feel if a team member said to you what you are about to say.\n\nTread carefully. Words can do a large amount of harm.\n\nThey can also do good, so choose to use them for good.\n\nRemember, 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.\n\n

\n\n