During my career I’ve seen many teams of different shapes and sizes, and I’ve noticed that the most effective teams are those where people actually care more about their teammates than themselves.<\/p>\n\n\n\n
Takehiko Inoue shows this very clearly in his best seller manga Slam Dunk<\/em>, which also happens to be my favourite. This manga follows a problematic teenager (Sakuragi) as he learns to play basketball and transform himself along the way, but it also shows the readers that the only way for a team to be successful is to have real team players that collaborate rather than focusing entirely on individual plays.<\/p>\n\n\n\n These lessons apply to all kinds of teams, including software development teams. With that in mind, here are five concrete ways in which we can play for the team:<\/p>\n\n\n\n Imagine that one of our teammates makes an awesome play (pull request), and they need a teammate (you) to complete the play (review the changes) and score (merge the PR).<\/p>\n\n\n\n When we decide to keep working on our own assignments and review the PR later, we break the momentum. It’s like moving away from the play and waiting for someone else to join it. Surely we’ll score at some point, but overall we’ll score less points in this game.<\/p>\n\n\n\n If we’ve become aware of that PR, then we are already in the play: we’ve already had a context switch, so let’s make it count by completing that play and score some points for the team!<\/p>\n\n\n\n We are people, and it’s in our nature to make mistakes. If a teammate is about to score, but their form is not perfect, we don’t want to stop them (unless it’s in our own basket). We’ll let them shoot, and we can talk about that or practice together when the time is right.<\/p>\n\n\n\n The same happens when we block a PR due to nitpicks or style preferences. By being too picky we prevent our team from scoring. Unless the comment is critical, we can ask for it to be done in a follow-up PR, if really needed.<\/p>\n\n\n\n Of course, any play needs to follow the rules. If a shot is taken while being out of bounds, that won’t count, and the referee will stop the game. If a change does not meet the definition of done, it’s our duty to ensure that it is before a change is merged.<\/p>\n\n\n\n On a Basketball Game, it’s important to know where your teammates are so you can pass to them, set a screen, or help them with a play. For this reason, teammates communicate often using verbal and non-verbal cues to share this and other relevant information that will help them make that play count.<\/p>\n\n\n\n In a software project, we need to be aware of what everyone is doing so we can go help our teammates when needed. For example, I was recently working on the wrong task due to a misunderstanding on my part, but we were quick to correct that because I told my team what I was doing. Otherwise I would have just wasted lots of time.<\/p>\n\n\n\n The same goes for when we\u2019re struggling with our assigned opponent. A selfish or close-minded player might keep trying (and failing) on their own, which could end up costing the team points. The alternative is, of course, to ask for help. Tell your teammates when you need help, everyone needs help from time to time, and it’s only by supporting each other that we can win games (or successfully complete projects).<\/p>\n\n\n\n Great teams don\u2019t just run plays: they teach each other how to run them better.<\/p>\n\n\n\n In Slam Dunk<\/em>, there\u2019s a moment where Akagi, the team’s captain, takes time to teach Sakuragi how to rebound. He doesn\u2019t have to: Sakuragi is rough, inexperienced, and full of himself, but Akagi knows that if the team is going to succeed, every player needs to grow. By passing on his skills, he makes the whole team stronger.<\/p>\n\n\n\n In a software team, the same idea applies. If you\u2019ve figured out a neat pattern, shortcut, or trick, don\u2019t just use it silently. Share it. Drop a link in the chat, mention it during stand-up, or pair with someone on it. When we teach what we know, we\u2019re not just helping someone once, we\u2019re helping the whole team play better, every time that play shows up.<\/p>\n\n\n\n A team that shares its best moves doesn\u2019t rely on one star player. It builds a deep bench that can take on anything.<\/p>\n\n\n\n Some plays don\u2019t show up in the highlight reel \u2014 but they win games. A well-timed screen. A pass to a teammate with a better shot. A rebound in traffic. These are the things that keep the team moving, even if they don\u2019t get you the glory.<\/p>\n\n\n\n In software teams, it\u2019s the same. Pulling customer data, cleaning up flaky tests, triaging bugs \u2014 it\u2019s not glamorous, but it matters. These are the things that help the team stay in the game.<\/p>\n\n\n\n If only one person does it, the balance is off. We all need to chip in. That means being the one who sets the screen, so someone else can score. Those plays may not get a big cheer, but they\u2019re what great teams are made of.<\/p>\n\n\n\n Great teams don\u2019t win because everyone plays like a star, but because everyone plays together. Whether it\u2019s helping a teammate score, letting the little stuff go, asking for help, sharing what you know, or doing the dirty work that keeps things running, it all adds up. These aren\u2019t just plays from Slam Dunk: they\u2019re habits that make software teams faster, stronger, and way more fun to be part of.<\/p>\n\n\n\n Happy coding!Keep the momentum<\/h3>\n\n\n\n
Shoot first, review the tape later<\/h3>\n\n\n\n
Shout Your Position<\/h3>\n\n\n\n
Share the playbook<\/h3>\n\n\n\n
Do the dirty work<\/h3>\n\n\n\n
\n\n\n\n
Jos\u00e9 Miguel<\/p>\n\n\n\n