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.
Takehiko Inoue shows this very clearly in his best seller manga Slam Dunk, 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.
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:
Keep the momentum
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).
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.
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!
Shoot first, review the tape later
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.
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.
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.
Shout Your Position
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.
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.
The same goes for when we’re 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).
Share the playbook
Great teams don’t just run plays: they teach each other how to run them better.
In Slam Dunk, there’s a moment where Akagi, the team’s captain, takes time to teach Sakuragi how to rebound. He doesn’t 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.
In a software team, the same idea applies. If you’ve figured out a neat pattern, shortcut, or trick, don’t 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’re not just helping someone once, we’re helping the whole team play better, every time that play shows up.
A team that shares its best moves doesn’t rely on one star player. It builds a deep bench that can take on anything.
Do the dirty work
Some plays don’t show up in the highlight reel — 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’t get you the glory.
In software teams, it’s the same. Pulling customer data, cleaning up flaky tests, triaging bugs — it’s not glamorous, but it matters. These are the things that help the team stay in the game.
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’re what great teams are made of.
Great teams don’t win because everyone plays like a star, but because everyone plays together. Whether it’s 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’t just plays from Slam Dunk: they’re habits that make software teams faster, stronger, and way more fun to be part of.
Happy coding!
José Miguel
Share if you find this content useful, and Follow me on LinkedIn to be notified of new articles.