There’s a powerful story in the narrative of Western civilization around the team. It comes up in the context of the military, especially special operations, in the startup community, especially in the early phases of a company, in sports as well as in the leadership literature. The idea is that a group of people can be merged into what’s almost an organism where everyone is aligned around the same goal, committed to putting all their energy towards that goal and operating in perfect harmony, without dissent and complaint. Team members act fluidly without having been asked as they know what needs to happen and altruistically sacrifice their own needs and wants for the greater good of the team.
As you read the above, I think everyone understands that the notion of a team is an illusion or, at best, an unattainable platonic ideal. As human beings, we all have our personal goals and ambitions. Of course, part of those ambitions is to feel part of a community and be recognized as a valuable member of that community, but few people will sacrifice everything to achieve that. We all have our own lives to live and need to (or should) spend time on our self-actualization.
In the software development context, our story is the notion of an Agile team: a group of people operating in sprints and scrums. Like in rugby, where some of the terminology originated, the idea is that the team acts as one with every member contributing his or her best while supporting the others where they need it.
There are three challenges with teams that I see in practice. First, especially in multi-disciplinary teams, different disciplines approach challenges in very different ways, which easily leads to conflicts. A typical example is between user experience (UX) folks and engineers. UX is concerned with providing the best possible user experience for each of the features provided by the system, which often involves experimentation with users. Engineers typically want to build a new function and move on to the next thing.
Second, even for homogeneous engineering teams, there often is a conflict between those who are more inclined toward architecture and have a long-term focus and those who are more concerned with simply getting functionality implemented, even if it means incurring some technical debt. As there’s no absolute and objective measure to balance long-term needs such as minimizing and paying off technical debt and short-term needs of delivering functionality, significant debate can ensue. This can be viewed as creative conflict within the team, but it does create tension and negatively affects team harmony.
Third, as humans, we have different temperaments, but one of the common behaviors is to seek to climb higher up in the hierarchy. In engineering teams, there’s often limited opportunity to ascend in the formal management hierarchy, but the reputational, informal hierarchy is just as relevant for most of us. And this leads to tensions and conflict as different people are vying for the same position.
As a consequence, the notion of a team is often not living up to the platonic ideal that many make it out to be. Of course, there’s a team as in a group of individuals under a common label, but the level of performance and the amount of tension and difficulty experienced may still be significant. In the end, a team is a collection of individuals with their own plans, ambitions and goals.
For leaders, one of the key challenges is overcoming the limitations of teams to maximize performance. To accomplish this, it’s important to be realistic about the drivers of the individuals making up the team. Although the leadership literature is infinitely long, it’s my experience that three activities are key for leaders to engage in.
First, it’s critical to identify what makes each team member tick. This requires significant empathy and reflection as nobody will just throw out their goals, ambitions and quirks. Typically, what people say is not what’s really going on in their heads, even if they truly believe what they’re saying. A leader needs to uncover team members’ actual drivers and use this insight to optimize their performance and that of the team as a whole.
Second, key aspects of self-actualization are growth and development. For a leader, one of the mechanisms to help team members is identifying opportunity areas for development. All people have blind spots that are limiting their ability to grow and develop and they need constructive feedback from others to start seeing them. This helps them develop and grow and can significantly improve harmony in the team.
Third, conflicts in teams are unavoidable for all kinds of reasons. These can be open conflicts with people talking loudly with each other or passive-aggressive conflicts where people ignore each other and avoid collaborating. It’s the job of a leader to find ways to use conflict in the team as a source of energy and development.
Especially in the Western world, the notion of a team is a very strong concept and has a compelling story around it. In practice, many realize it’s a bit of a myth as people are different, members from different disciplines in cross-functional teams approach challenges differently and we often compete and jockey for positions. Leaders are responsible for making teams as productive as possible. This requires understanding the drivers of team members, providing constructive feedback to make people grow and converting conflicts into positive growth and development opportunities for the team. As John C. Maxwell so eloquently said, “Teamwork makes the dream work, but a vision becomes a nightmare if the leader has a big dream but a bad team.”
Want to read more like this? Sign up for my newsletter at jan@janbosch.com or follow me on janbosch.com/blog, LinkedIn (linkedin.com/in/janbosch), Medium or Twitter (@JanBosch).
