I was talking with a friend a while back who had gone through some jobs they didn't enjoy, and had now landed on a job they seemed to thoroughly enjoy. When I asked them about it, the key reason they provided for why this particular job seemed so much better was: "I have teammates, not coworkers."
That phrase has resonated with me since.
What distinguishes a "teammate" from a "coworker" in a way that improves job satisfaction like it did for my friend?
Here are some thoughts.
I believe explicitly listing principles and values is incredibly valuable in all sorts of contexts. I particularly think that is true in the context of a company. Many, many companies do this, and know that it is a meaningful way to differentiate themselves to potential applicants as well as provide a guiding force for the business. Sometimes it is under different names, but the purpose is generally the same: broadcast their principles, values, and way of working to attract like-minded teammates. It also goes without saying that professing principles/values doesn't stop a company from being evil (see Enron).
Sometimes, values can come into tension with each other, and that is healthy. But, it's hard to be a good teammate when there is not a large overlap in values. Instead, it will be a consistent source of friction.
Fundamentally, I think this is the key point. Then, depending on what those shared values are, it's easy to see some concrete examples. Here are some examples that I think are teammate behavior drawn from my personal values.
Teammates reduce entropy, coworkers fuel it.
Entropy in engineering shows up a lot of different ways. It could be the codebase (i.e., the software architecture, the abstractions, the tooling, etc.). It could be communication (i.e., messages that lack sufficient context, require unnecessary back-and-forth, etc.). It could be all sorts of other things (documentation, company policies, IT management, and more). I'd also classify complexity in general as a component of entropy, despite the fact that growing complexity is often fundamental to a developing product. I define complexity as APOSD does: "anything related to the structure of a software system that makes it hard to understand and modify the system". This generally pragmatic definition also applies to things outside software. Entropy is the extra noise, disorder, confusion, etc.
I've found that people I'd call teammates naturally reduce entropy (and strive to contain complexity) in their respective domains. Meanwhile, coworkers are often the source.
Some examples:
- A coworker sends a bare hello, a teammate includes the context necessary to make asynchronous communication effective.
- A teammate opens that PR fixing those 6 typos in the source code comments.
- A coworker sends that message tagging a bunch of people to investigate a "super flaky test", only to discover the issue is a real bug and the tests were not flaking at all after people context switch to help. They do not respect others time as much as their own. A teammate is willing to context switch to help.
- A coworker opens a PR with a bunch of code that "might be used in the future", even though it's not right now, increasing maintenance burden. A teammate deletes dead code.
- A coworker provides unhelpful commit messages like "fix stuff", or has poorly organized commits, or general doesn't explain the why. A teammate provides thorough context that often helps future debugging efforts.
- Teammates introduce tooling, frameworks, design patterns, etc. to help systematically reduce complexity.
- A coworker sends you a screenshot of text, often of a token or credentials or something you need to then transcribe and enter. They claim innocence, but their actions make it clear they have no respect for your time or appreciation of optimizing communication to get things done.
- A teammate is the type of person that puts their shopping carts away, regardless of whether people are watching.
Teammates are the type of people that actively educate and build the collective skills of those they work with. They are the subject of those "Alice showed me how to"- or "I picked this up from Bob"-style comments. They are the ones who introduced you do that game-changing editor feature, or taught you about dotfiles, or helped you get up to speed and build a good mental model for that part of the codebase. They recommended that book that you read that changed how you thought about something. They are the ones you frequently have deep, meaningful conversations with. Teammates share because they want to. Teammates make the people around them more effective now, while also helping them grow and expand their potential in the future.
Here's another way I see this happen. Suppose there is a task that requires some custom effort. Someone probably had to write a little script or something to do the job, maybe had to deal with some edge cases. Now, you are handed essentially that same ticket and a pointer that "it's just like last time".
If you have a teammate, you would go to that other ticket, and likely find everything you need. They probably even shared the snippet they used.
If you have a coworker, you would go that other ticket, and likely find nothing except it being marked "Done".
Coworkers aren't interested in sharing. That's not their job.
Teammates care about the team, coworkers care about themselves
Sure, the company isn't a family. It's not meant to be. But, as DHH says,
You don't have to pretend to be a family to be courteous. Or kind. Or protective. All those values can be expressed even better in principles, policies, and, most importantly, actions.
Teammates care about the team. Teammates break down silos and artificial divisions, resulting in increased unity. They are people you enjoy working with, and you can tell they genuinely care about you. Their pattern of care often extends into their other communities as well. You sincerely look forward to interactions with teammates.
Coworkers don't bother investing in relationships outside what impacts their core job. Interactions with coworkers might be laborious and taxing.
Teammates enjoy the craft, coworkers only see it as a means to an end
This one might be controversial. I think teammates enjoy the craftsmanship of whatever craft they are engaged in. They are often the people that inspire others from their enthusiasm. Maybe they play for the love of the game. Maybe they play to win. They are the ones metaphorically early to practice and always hitting the gym. Their enthusiasm and corresponding work ethic is contagious.
Coworkers are just here to get that cash and do other things.
Indeed, I think it is also common for a person to be a great teammate by this measure in some contexts while simultaneously not being a great teammate in others.
(Nikola Jokić, who I'd argue is a great teammate, is one prominent example of an exception here with the way he exemplifies team play but, in the off-season, couldn't care less about basketball.)
Conclusion
I'm sure I've missed a lot of examples here, but even so, it's been a good source of personal reflection to think about how I myself can try and be a good teammate. I certainly am convinced that striving to be a good teammate, and having good teammates, leads to improved job satisfaction and team success.