Teamwork quotes aside, what actually makes a team great and how do team dynamics and structure – amongst other factors discussed here – come into play when building great systems in the context of software development?
Many of us have come across the above platitudes and even more at some point or another in our lives, usually within a team-related context (be it willingly or unwillingly). This could have been in our own homes, at some stage of our academic careers, or when we entered the world of work. Think back to the times of packing and planning for family vacations or moving house, the school group projects and extracurricular team sports, or the company-mandated after-work functions and teambuilding workshops – the list goes on. Notice how I didn’t make use of any descriptors or adjectives to colour the above-listed events as, I’m sure is true for many of us, these could have gone either way. For instance, while many of us may recall bitter arguments over ‘what-goes-where’ or ‘whose-is-what’ in the throes of the packing process with family, others might remember the shared responsibility in these preparations and looking forward to the upcoming vacation or new home; while some dreaded and dragged the dead weight of their ‘group’ or ‘team’ members towards the finish line of a mid-term project, others celebrated the victory of their collaboration at the goalpost; or while some feigned illness or made excuses to opt out of functions and workshops, others instead rose to the occasion and motivated their colleagues to participate and put their best foot forward. So, what then are the differences between the polarities of each scenario, besides context and perspective?
While we can speak to either the desirable or undesirable leadership and team-oriented qualities of specific individuals in each scenario, the efficiency and effectiveness of how a team functions on the microcosmic level is also reflective of the whole – whether that be a family, institution or organisation.
Looking up the definition of a ‘team’ on Google search, the following was likely the simplest I found:
“A team is defined as a group of people who perform interdependent tasks to work toward accomplishing a common mission or specific objective.” (https://asq.org/quality-resources/teams#:~:text=A%20team%20is%20defined%20as,to%20solve%20a%20particular%20problem.)
According to this then, a team is essentially composed of the three elements as underlined above: (1) a group of people, (2) interdependent tasks, and (3) a common mission/specific objective. While we can enjoy the reductiveness of this definition, it fails to speak to what really makes a team great and in what context – which leads us in the direction of a more qualitative inquiry on the topic at hand. But, before we consider the types of teams and their structures within a typical software development environment, we need to take a look at multifactoral teams and investigate what makes these great.
Firstly, the term ‘multifactoral’ denotes involving, being dependent on, or controlled by multiple factors; this seems to speak more to the dominant characteristic of the projects these teams are suited to, rather than the teams themselves. However, secondly, this definition of a team either influenced and/or managed by multiple factors – whether these are internal or external to them, the project or even the organisation – can infer a specific team structure and dynamic in order to respond effectively to the unique combination of these factors at play. As such, a multifactoral team may essentially speak more to a change in approach and possibly also structure, rather than a change in methodology or philosophy when building systems (i.e., Agile, Waterfall, etc., whichever you choose). How and why is this important, if not beneficial? A different approach not only informs a different way of thinking in terms of what we are looking at and what our focus areas are, but can also invite innovation into the software development process, especially when it comes to resolving issues that arise along the way.
As a side note, I would also like to highlight the following: please do not not confuse multifactoral with multidisciplinary or multifunctional – while it is tempting and the latter terms can easily overlap with the former and main one, I am considering teams as a whole for the purposes of this article rather than the makeup of those teams (although this may, funnily enough, be considered as one of thee factors).
This is where a multifactoral team may have an advantage over the traditional Generalist, Specialist and Hybrid teams – although I feel there are some similarities shared with that of the Hybrid structure. If we turn our focus onto the multitude of factors that can affect a project – which could potentially form part of the business analysis phase to identify these – and construct a team accordingly, or vice versa (which may prove to be more difficult), a multifactoral team could also be more prepared for potential pitfalls and gaps in development than traditional teams. The purpose of a different approach and innovation in this case lends to breaking away from the traditional structures and ways of thinking. From this perspective, multifactoral teams introduce elements of dynamism and flexibility to building systems that do not necessarily impeach on tried-and-tested methodologies or philosophies in place. Likewise, this approach and way of thinking also reflects in how these systems are built and operate.
To add to the topic, there are additional factors that make teams great and that make great teams which will need to be considered as part of this discussion. While these commonly include shared values such as communication, accountability, diversity, organization, understanding, support, etc. – many of these terms have become relatively generic and synonymous for most companies’ and organisations’ in terms of their their modus operandi – irrespective of whether the true meaning is understood or not. However, from a more crowd-sourced point of view and apart from many of the practical and applied skills that team members are already assumed (and also required) to have when hired in order to complete at least the pragmatic/necessary aspects of their job, a survey was conducted on LinkedIn in 2022 for the top 10 in-demand ‘soft’ (i.e., interpersonal) skills, identifying the following – which both speaks to what employees could believe they should offer to their co-workers and vice versa, especially when working within a team-related context in their companies:
(Source: www.linkedin.com, 2022)
Just as all of the above skills are pertinent on an individual and team level, it cannot be reasonably expected that even one individual can embody absolutely all of the traits of the team. Many are likewise complementary and can be contributed by/through various team members to help shape the overall dynamic, or ‘ethic’ thereof. So just as the competence, skillset and ambition of any one individual either contributes towards or harms the overall team’s ethic, the team also has to find a way to support the individual in their contribution as a part of the sum/whole. This refers me back to the old adage of ‘ The whole is greater than the sum of its parts’ – while individual contributions are valuable in their own way, contributions to and by the various team members working together also compound one another when carried out harmoniously and collaboratively. A quote by Casey Stengel (American Baseball Manager, 1910s and 20s) illustrates my point further from the perspective of an individual to team capacity in that “Finding good players is easy. Getting them to play as a team is another story.” Likewise, Phil Jackson (former NBA player and coach) also had another to add: “The strength of the team is each individual member. The strength of each member, is the team.”.
While factors such as the complexity of projects, the preferred software development process, project scope and feature prioritisation also determine the effectiveness and success of multifactoral (and other) teams, as well as the systems they build – there are still other areas of business value that can be further investigated outside the scope of this article. In conclusion, however, just as there advantages and disadvantages to the traditional Generalist, Specialist and Hybrid team structures in software development, the same also applies in the case of multifactoral teams. Therefore, it is important to bear in mind not only the suitability of a particular team structure to a specific project, but the preferred approach, process and methodology the team will follow in order to meet their goals, as well as the limitations of these. Furthermore, while the dynamic and skillset of the team contributes to the success of a project from a pragmatic viewpoint, a basis of shared values and an offering of diverse yet complementary interpersonal skills reduce the likelihood of conflicts, misunderstandings and ultimately failure. All things considered, a team is just a group of people working toward accomplishing a common mission or specific objective at the end of the day.
End
