The Tangibles of Teamwork — How Teamwork Makes a Team Work
Dissecting the term teamwork with the context of analytics teams and inspirations from the UC Davis MSBA Practicum Project
Job interviews in any field involve a discussion on teamwork. “Give an example of a time when you worked in a team” “Tell us about an instance when you were a good team player” etc. Along with problem-solving and analytical ability, team player/teamwork is a commonly listed soft skill on resumes of people who apply for tech jobs. Everyone has done a course on Coursera, watched a video on YouTube, read a LinkedIn influencer’s post, or bookmarked a Twitter thread on what teamwork is. Everyone has previously worked in a team at some point of their lives. Does that mean there are no dysfunctional teams anywhere? That is certainly not the case. We work as part of multiple teams in life and at least one of them is dysfunctional. Why is that so?
The truth is, in theory teamwork is a glaringly obvious concept, however, in practice it is incredibly abstract. When we work in a team and need to make a decision that could potentially define whether or not we are a team player, all of a sudden all these frameworks, content and examples from Coursera, YouTube, LinkedIn and Twitter evaporate and it’s just us and our instincts. And what exactly is instinct, if not a projection of either our experiences, or values, or both? It is difficult to accrue experiences or change our values overnight. It comes with time and practice. But hey, you thought I just said teamwork is abstract in practice? Exactly. That’s why it takes time to unravel the exact sciences of the abstract construct that teamwork is.
My perception of teamwork has been created and developed though the numerous teams I was a part of in undergrad, my work experience prior to coming to the US, and most recently my practicum project. As part of the MS in Business Analytics (MSBA) program at UC Davis, I am working on a year-long project with an e-sports company called Pittsburgh Knights to build a data product for game analytics.
Since it is a team engagement, I was one of the five pseudo-randomly chosen guys with complementary skills put together for this project. We originate from three different nations, five different cultural backgrounds, and four different career backgrounds, all working on this project as students, batchmates, friends and teammates. It is natural for my perception of teamwork to have a heavy recency bias, but that is how I believe it should be. Human perceptions are built on experiences with the topping often being the most recent experience. The topping always tilts the taste of the dish. So here’s how I break the abstract concept of teamwork into exact sciences that are more easily perceptible.
1. Teamwork is Self-Awareness
When we start working with a newly put together team, the people in the team we know the best are our own selves. And we should understand which skills of ours, technical and otherwise, we could bring to the table in the context of the project. I realized in the beginning of the project that my strengths lay in fearless communication, logical thinking, SQL, data engineering knowledge, data visualization and writing. In addition to our strengths, we should recognize our weaknesses very clearly. Since we (inevitably) get to know the strengths of our teammates over time, we would know what to learn from them by recognizing our weaknesses.
“I think….you still have no idea. The effect you can have.” — Suzanne Collins, Mockingjay
But maximizing our strengths and addressing our weaknesses are things that could be done only if there is a clear personal goal for the project. I wanted to do good quality work on a real world business problem, constantly apply the concepts that I would learn from the program, and develop my storytelling with data. The goals, however, could very from wanting to deliver a top quality product on time to the client (internally termed as MIP — MSBA Industry Partner) to wanting to address holes in our skills. One thing does not necessarily cause the other because amidst all the assignments, it is easy to be focused on getting good work done in time by just maximizing each person’s strengths. If that is what we want, then it is perfect. If the goal is to address holes in our skills, then we need to communicate that with the rest of the team.
2. Teamwork is Communication
If we want a specific piece of work in the project, we need to ask for it. We need to communicate and explain why we really need that piece. We need to prepare a pitch. And for that, we need confidence and communication.
Communication is required to not only pitch our interests, but also to learn about our teammates. To obtain different perspectives of the project. To talk about our work in the project and provide updates. To talk to the clients.
On the first internal call that my team had, we spoke about our work experiences, strengths and weaknesses which helped us pre-determine what role each person could be playing in the project. We know who is good at programming, and who wants to become good at it through the practicum. We know which of us understand first-person shooting games better than the others. Our diverse skillset and experiences have provided internal solutions to most of the roadblocks we have faced so far. So it is crucial to create and sustain an environment that is judgement-free and conducive to productive communications.
3. Teamwork is Initiative
We are now self-aware and comfortable to communicate. We discuss the tasks and align them with our strengths/weaknesses and project goals. The next aspect of being a team player is to step forward and take initiative. “Anything is fine with me” is not showing initiative, it is hardly a useful comment to make since everyone in the team ends up saying that, hoping that someone else delegates work to them. We need to be specific and say, “Hey, I got this covered, this is on me”. Proactively showing initiative provides a psychological security to the rest of the team that the task is taken care of, while also encouraging the diffident ones to step forward and own a task.
I usually take up the editorial role for writing assignments as it is something I am experienced in. I did not delve deep into the programming parts of the project since it is not something I am experienced in, but the programming experts in my team stepped up and provided the psychological security to the rest of us.
However, showing initiative can be hard when we are fundamentally introverted and shy to step forward. We let the extroverted folks run the volunteering session, and pick up the task that others leave behind. Nobody wants to be that person, but they often end up being so out of shyness to speak up. While it is important to speak up, failure to do so should not mean the same person always does the grunt work in the project. How do we ensure that?
4. Teamwork is Compromise
Making sacrifices for the greater good says volumes about how great a team player one is. That does not mean we need to be pushovers — compromise must not come at the cost of project goals. But it is healthy to sometimes show initiative for work that nobody would want to do. It is a compromise that if every team member makes in turns, no one ends up doing more grunt work than the other. Projects are a trade-off among our comfort zone, personal goals and greater good. All of them need not take us in the same direction (it is great if they do), therefore managing this trade-off by giving preference to all of them equally at different stages of the project is key.
“You forget a little bit, the guy who sacrifices himself is Firmino. He is the guy who works for the team, who works for everybody and gets them to shine. This piece of the jigsaw is always very difficult to find: a striker who is generous.” — Arsene Wenger on Roberto Firmino, a model team player in soccer
In any tech project, documentation or support is often seen as grunt or mundane work that no one wants to do. But a well-documented system makes thousands of lives easier. Being a reliable support team enhances the productivity of our stakeholders. It doesn’t align with our personal goals, so why should it matter to us?
5. Teamwork is Empathy
I mentioned “greater good” in the previous section. In this context, greater good is the quality and timeliness of the deliverable which, in the case of my practicum project, is the data product. Documentation is a part of any deliverable and a metric in evaluating its quality. Good documentation ensures the stakeholders of the data product have a smooth transition to and understanding of the product. It ensures that subsequent developers/supporters of the product don’t have trouble understanding certain code snippets. These are little acts of empathy that go a long way in building sustainable customer relationships.
Empathy manifests in many forms, making intermittent compromises for the greater good is one form. Good communication is an act of empathy where speakers put themselves in the listeners’ shoes before they decide how best to communicate their thoughts. Initiative is an act of empathy towards the project manager. Compromise is an act of empathy towards our teammates.
When we talk technical elements of the project with the MIP, we do not use jargons. We take turns in writing minutes of the meeting. We keep everyone in loop with everything even when anyone misses out on a meeting.
This is relatively easier when we are committed to the greater cause of delivering a top quality product to our clients. The little details in between could be important, but we should not let them be decisive.
6. Teamwork is Commitment
Self-awareness, communication, initiative, compromise and empathy — when all these are done consistently, it is commitment. Commitment is a wrapper package that encapsulates all these exact sciences of teamwork with the added dimension of consistency. Being accountable for and seeing through a task is as important as stepping forward and owning one. Commitment, discipline, accountability: it could take several labels, but the core idea is similar to eating in a buffet — we are responsible for what we put on our plate, and we are also responsible for eating them without wasting food.
Commitment builds credibility. Credibility builds reliability. Humans refrain from being judgemental, but they inherently seek reliability which often dovetails into an evaluation/judgement of commitment. There is a dimension of consistency to it, so commitment is something that can only be displayed over time. Through good and honest work.
In a non-hierarchical setup like my practicum team, these tangible elements of the intangible concept of teamwork epitomize the functionality of the team and our merit as a team player. In this team, everyone is a leader, everyone is a follower, but above all, everyone works for the team.
I recently read/watched/heard about the difference between “complex” and “complicated”. A solution to complexity is a function of unpredictability, while that to a complication is often predictable. This article has the interpersonal dynamics in teamwork as its focal point because humans are complex beings, a more unpredictable version of the complicated projects that they work on. Therefore, frameworks to navigate these complexities are a significant step that makes simplification of any project complication smooth.
For the whole to be greater than the sum of its parts, firstly, there needs to be an equality. Understanding what teamwork means and playing by its rules ensure equality. Anything over and above equality, which is often achieved by genuinely good teams, shows the power of teamwork that makes it an invaluable trait to have for anyone who works in a team.
