There is no single point of truth about teams and teamwork. Similarly to how a majority of leadership centric literature overemphasises the importance of "the leader's skills and traits" it neglects the "follower’s" perspective, most of the team focused publications focus on "managing/building team". The narrative about how to fit well or to align better within a team is practically non-existent. In the context of the popularity of the cross-functional model of teams with more decentralised decision making and shared responsibility (i.e. the ability to respond), this creates a space for discussion about expectations for the team members.
In this blog post, I hope to outline some of my opinions on the teammate perspective and competencies necessary for a well-functioning team. My aim in this piece is to draw a high-level outline of the ideas, give something to disagree with or to have a conversation about, rather than to drill down to details. Also, quite importantly, my views are contextualised to teams involved in software development - I think each profession and industry has idiosyncrasies that cannot be dismissed and it's worth bearing that fact in mind.
From the bottom up, the main operational definition to establish is one of the teams itself. In conversations, most people have difficulty verbalising what they naturally understand. In regards to "what makes a team" in the end, most people will arrive at a few common keywords: "group", "goal", "collaboration". Without a doubt, it is a fair assessment of what the character of a team should be. What on the other hand rarely is the part of an effort to define a team is an inquisition about the reason for their existence.
We invite you to listen to our podcast How you can create a great team. We talked about these topics with some very special guests.
Motivation for the creation of "work collaboratives" can be (over) simplified to two dimensions: task volume and complexity. At this point, I think the characters of the team will start to differentiate, teams with more focus on volume of work will have very different shapes and properties than those focused on solving complex problems. Irrespective of the values for a given axis, a team can be reimagined as a scaled-up version of a single individual. What will differ is the strength of inter dependability and resulting communication patterns.
From a perspective of a team member trust and communication seem to be underlying elements of effective collaboration. From those two elements, we can infer further dependencies that are components of the team framework. I believe that trust is at the very core of the teamwork process and without it, it is hard to move forward. To establish trust we should be able to satisfy the three main criteria: being authentic self, having sound logic (i.e. being able to understandably relay logically sound arguments), and finally to show empathy towards other team members. Easier said than done, to make it even harder to practice any of the criteria (especially authenticity and empathy) we need to build safety. Establishing safety first and foremost takes time, which is also involved in the mutual appreciation of personal differences, shared support and, from every person involved, a certain strength of character.
I've mentioned earlier communication, which is not only an obvious choice but also the easiest of the "soft skills" (CORE skills) to learn and master. I think that most people who realised that they might have too many assumptions about what someone is saying and are tuned to listening and paying attention to what they hear are on the right track to be good at communicating. The next step is usually learning to ask more questions to further clarify and remove your assumptions. The rule of thumb here is: the less you know, the more gaps you fill with your imagination, the more sure you are, the less likely you are correct. Perfectly convoluted. I've recently done a series of meetups on soft skills in software development, that could act as a primer on personal differences, empathy and communication (among other things).
One final note, teams who embrace active experimentation (i.e. design, planning, data collection, analysis, feedback) tend to significantly outperform teams who don’t. On that note, it’s worth remembering that the risk of falling into the confirmation bias during the experimentation will have negative consequences. Celebrate failure. But that's a whole other story.
If you’d like to know more, be sure to check out our previous post, and read about:
What-are-the-skills-that-each-member-of-your-team-must-have
What-is-a-cross-functional-team.