Skills vs. Attributes
As software engineers, we usually focus on skills, abilities, and knowledge when considering advancing our careers or compensation. Undoubtedly, competencies are crucial, and there are many clear paths to increasing them. Still, competencies are only half the picture when considering what it takes to be highly successful as a software engineer. Despite the widespread use of the misleading term “individual contributor,” software engineering is a group effort, and you can’t be a great software engineer without being a great team player.
Upon reaching a certain skill threshold, being a great team member requires developing the personal attributes which make anybody an asset or liability to their team. While there is an ocean of beneficial personal attributes, working as a software engineer today involves cross-functional collaboration with design, research, and product folks in a hybrid or fully remote environment—circumstances that magnify the harm of being a self-centered teammate.
In the book The Ideal Team Player, the author describes a framework called Humble, Hungry, People Smart to focus on the essential attributes of a team player and advocates that all three are equally necessary. This post will describe how this framework applies to software engineers. As always, this writing is as much a reminder to myself as it may be to anyone else of implementing social responsibility in the workplace.
Hungry
In the Ideal Team Player book, Hungry comes second, but it’s the most overlooked attribute, so I’m putting it first. Simply put, a hungry team member always looks for something to do. In this sense, they are never truly “blocked” because there is invariably something that can be done to support the team.
It’s also worth noting that the opposite of hungry is avoidant. The avoidant person sees any issues obstructing the team as someone else’s problem and practices a minimal interpretation of their role. This isn’t to say that they don’t perform high-quality work; they are just not a helpful team member. From a team perspective, this person acts like a guest in their own home, stepping over a broken glass while someone else picks up a broom.
To be 100% clear, the hungry software engineer is not toiling away into the night with no life outside of work; they are just making the optimal usage of work time.
A hungry software engineer:
- notices assigned PR reviews and prioritizes unblocking peers
- fixes an intermittent test failure
- is steadfast in answering a question from a peer
- traces issues back to the root and shares their findings
- corrects inaccurate documentation when encountered
- opens PRs across team or library boundaries
- lets people know when they are available to help or pair
- updates dependencies, language, and framework versions
- learns the nuances of the business subjects of the work
- spends time learning new methods or practices relevant to their tools
- develops time management skills such as time-boxing so they are in and out of focus time
- fixes an accessibility issue they notice
- creates a ticket when they observe a problem that requires prioritization
People Smart
At first, people smart seems like emotional intelligence or empathy, but it is simpler than that. People smart is the awareness of how one’s words, actions, and reactions affect other team members. This applies both to what a person does and doesn’t do.
Here are some examples of how to apply people smarts as a software engineer:
In the phrasing of PR, feedback to avoid embarrassing a team member when they made an error. For example: “What do you think about putting this in an environment variable?” instead of “This should be an environment variable.”
When providing constructive criticism to a team member, explain why it makes a difference. For example: “Can you mark your in-progress PRs as drafts? That will help alleviate confusion as I sometimes have provided feedback on in-progress PRs when they aren’t labeled accurately.” Or, in working with a product manager, “Can you add more detail to these tickets? I’m interested in working on them, but I’m not sure how to get started.” Or in working with a designer, “Could you put in a few notes about the interaction here? I want to provide what you had in mind, but there are a few cases I’m uncertain about.”
Related to the above, not providing feedback to a teammate when you are concerned isn’t people-smart because issues only worsen when teams don’t discuss them. Most teams today have retrospective meetings, the perfect forum for constructive feedback. Yet, we often see folks holding onto their concerns and getting increasingly frustrated as they persist.
Another case of non-communication is when someone is assigned a PR that they cannot review promptly, but they don’t communicate their current situation. There are many acceptable reasons why this can happen, but leaving a PR without saying anything leads to confusion and potentially delays reassignment to another team member with more capacity.
Humble
This attribute is the most easily understood. I won’t write much about this as there isn’t much to say about it besides its importance. Humble people are quick to point out the contributions of others and slow to seek attention for their own. They share credit, emphasize team over self, and define success collectively rather than individually.
The opposite of humility is arrogance. The arrogant team member’s behaviors lead to distrust and communication problems that reduce productivity.
