I think a lot about why teams work well together.
Ever since I was a kid, my favorite part of playing basketball was making a pass, which led to a bucket, which led to a high five. It's not just the assist that's fun, it's the entire process - everything before (the trust and chemistry) to everything after (the celebration and reflection).
I'm drawn to software because it's a team sport. I hate working alone because such a large portion of my brain is dedicated to teamwork and working solo feels like under utilizing valuable resources. It's wasteful.
But today, I wanted to reflect on qualities of good teammates. Obviously, this list isn't conclusive, but I intend to elaborate on this concept with time. I expect this will be just one post of many.
It is my experience that good teammates have a sense for what is valuable work.
In basketball, people often say a player has a "nose for the ball" - the player happens to be in the right place at the right time. Of course, there's luck, but when Marcus Smart or Jimmy Butler routinely find themselves making play after play, there's more than just luck happening. They seem to know where the ball is going to be.
Likewise, great teammates have a sense for doing work that matters. With software engineers, it's a sense for what parts of a codebase are risky - and thus, where we should double down on high quality work, testing, and documentation. It's a combination of knowing which features get used a bunch, which code paths get executed often, and what parts of the codebase need frequent updating.
Sometimes it means reworking code to get the result into a simpler state. Sometimes it means shipping out something hacky to capture team momentum and boost morale (with a cleanup task in the back of their minds). Sometimes it means spending one hour to document a process.
An average engineer will work on whatever comes their way, sometimes optimizing just to optimize. But a good teammate will work on what matters. They won't always get it right, but you can tell they're skating to where the puck is going to be.
Not only do good teammates have a sixth sense for value - they also understand the velocity of value.
Thinking in terms of velocity is similar to the mindset of "it's a marathon, not a sprint"- but deeper. In actuality, business is not a marathon. You're never done. You're building a system, a lifestyle, a philosophy that can endure. Good teammates understand why we try to introduce process into our work.
But it goes deeper than that. Good teammates can see leverage. Again, from the vantage point of software engineers, they understand the value of CI/CD pipelines. They understand the importance of short testing cycles. They understand the importance of well written libraries, and code that can be reused by many aspects of the company. They see a beautiful API and they see combinatorial leverage. They understand that not only can you produce technical debt, you can actually produce technical wealth. They can think in platforms.
There are things you can do to increase velocity and good teammates seek to make those changes.
And in fact, it goes even further. If someone understands higher order value, they start seeing the value of culture, of hiring, and the forces that shape the processes.
Remember: position -> velocity -> acceleration -> jerk -> snap -> crackle -> pop
Good teammates see the big picture.
All of the best teammates I've worked with are excellent communicators in writing. English isn't always their first language and their writing might contain grammatical blemishes (which are endearing 🧡), but after reading something they've written, you understand the point being made - and quite often, that energizes you.
Writing is important because it:
Good teammates excel at written communication.
This is a quality I've come to understand from working with bad teammates.
Bad teammates frequently obscure the truth. They will often obfuscate concepts such that no one understands exactly what is going on, but they seem to say "don't worry. Trust me, I know how this works".
Now, trust is not a bad thing. In fact, it's a very healthy thing. But the bad thing is when trust is being used as a proxy for mastery before mastery has been demonstrated.
You'll be able to detect this if - after seemingly every conversation with someone, you leave thinking "I don't understand what's going on", or "Hmm, this feels way more complicated than it is". When you poke and prod, the person maintains the illusion of expertise, but you're still not any closer to understanding what is going on. Sometimes, the problem is that you need to learn more before it makes sense (especially if you're junior), but more often than not, you're dealing with some form of charlatan.
My rule of thumb is not to trust someone until they've explained a concept to me - in a way that is easy to follow and demonstrates knowledge that is supple and flexible. Until then, I assume I'm either dealing with an average teammate (nothing wrong about that!) or a quack (definitely someone to avoid).
Good teammates are intellectually honest. They don't try to present themselves as experts. There is no insecurity when they admit their limits. But when they talk about something they do understand, it's a "no flex zone" of pure knowledge transfer. You'll feel smarter, or at the very least, have a list of topics to research next.
A dangerous caveat is the previously intellectually honest teammate who has grown accustomed to feeling a sense of mastery in their old domain, but is a relative novice in their new domain. Without someone to keep them intellectually honest, they might become a charlatan to maintain the feeling of being a master. This is exceptionally dangerous. So watch out for experienced people changing domains who have an ego.
Good teammates have good emotional awareness. I think this manifests in at least one of two forms:
Emotional awareness is important because projects often collapse when the team cannot function effectively. People are not listening to each other. Values are out of whack. It results in people working on opposite things. One teammate might be writing a design doc. Another might be building a "prototype" (which they 100% intend to deploy to production). One teammate might be cleaning up code. Another might be making more messes. Chaos.
Good teammates make it clear to the team and their manager how they feel about something. Or, they understand how everyone else feels and skillfully adapt to what the team needs. In other words, they're either a little blunt (but not quite an abrasive jerk), or they're great listeners.
However, only listening and adapting is a long-term losing strategy. It might help the team in the short run, but it will eat you up inside. You'll feel bad for not expressing your thoughts and values, grow resentful, and it may impact your performance. It might not be your MO, but if you're someone who frequently prefers adaptation - start expressing your disagreements with poise and confidence: "If I understand you correctly, you're saying X. From what I see, I believe the right conclusion is actually Y. Here are my reasons".
I don't think I captured everything about good teammates in this article, but I like this list so far. The qualities I find important:
A couple undercurrents that cut through all of these is an eye for simplification, valuing truth over ego, and seeing the big picture.
But let me add one more thing before we go - in addition to all of the above, good teammates seem to experience great joy when the team succeeds.
Like I mentioned to above, one of my favorite parts of playing basketball was giving out high fives. I think another great quality of good teammates is they love to create situations where everyone is high fiving. That might actually be the best measure of team health that I can think of. The number of high fives between members of a team.
🙌