Why multifunctional team is not what you think it is
Methodologies ·
Multifunctional Teams
Software is getting more complex and its ecosystem is changing rapidly. Applications that we could write as a monolith system with a few developers and isolated system administrators and operations team don’t exist anymore. Customers’ expectations have skyrocketed and the infrastructure and tools got so much complex and sophisticated that no human being can possibly understand it all.
From all the programming languages, databases, operating systems, content delivery methods, network infrastructure, cloud and its friends, … to project management Methodologies have been created so much diversity that even choosing proper tools and processes is often a significant problem by itself.
DevOps movement influenced software industry at large in past few years and tried to simplify the complexity by merging different teams into one or multiple “multifunctional teams”. The idea is simple, each team should be able to create, deliver and operate its own software and service.
Large and complex software broke down into multiple services (or micro-services) with their own individual life cycles. Which makes them easier to manage and understand.
I had a chance to work in both, with traditional isolated teams and more recent approaches. What I observed is that although this new approach is quite efficient and helpful sometimes it can hurt teams and organizations.
Issues:
Apparently there are a few definitions of “multifunctional team”. Sometimes management and team members interpret it as every team member should be able to do everything. The other way to interpret is that each team is constructed of few subject matter experts.
I favor the latter and I have a few reasons.
As I already mentioned above no one can be expert at everything, specially in software. Software industry moves very fast, thus we need experts to focus on the specific subjects, like UX, design, programming, infrastructure, delivery, operations, machine learning and …
Even in imaginary situation that everyone is expert at everything, then they will step on each other toes. Experts are human beings first, and they have opinions. The fact that they are experts does not mean they necessarily have the same line of thinking and usually they don’t.
We are all biased and we are all obsessed to some degree, about the code quality, testing software, design, infrastructure, agile methodology and etc. Naturally we have different focus points (or favorite subjects) but we have opinions in other areas of expertise too and this creates conflicts.
Our brains process information differently. That’s because we have different knowledge, background, culture and a lot more diversities than we can think of. If we consider a few experts have access to the information about one subject equally it does not mean they will understand and realize it equally. And in more complex situation often they don’t. Which means in teams of jack of all trades the understanding and overview will diverge.
There is a high risk that team members in such teams will have a weak sense of safety and they are more defensive as they might see other team members as a threat. This will negatively influence communication and collaboration. And that’s what I clearly observed in many occasions.
What can be done
On the other hand I think teams should have individuals with with different expertise and in order to make such teams successful we should pay enough attention to a healthy information flow and effective communication across the team.
I noticed in teams with subject matter experts in multiple areas the communication is stronger and understanding of the big picture is more accurate.
Worth noting that having teams with experts in different areas doesn’t mean they should not be curious to understand what others are doing, rather they should educate each other and let others learn how to work in other areas as well.
This also give the safety feeling to the team members as they know they are trusted in their strengths and this makes them more open to change, teach other people and get taught.
What to observe
Of course like any other practice there are down sides to this approach as well.
First problem arises when people don’t let others to understand what they are doing and contribute to their work. This type of silos are very critical and other team members should help to break this silos within the team.
It might be harder to take over the responsibility of team members since they are the only expert in that area. Although this can also happen in the other approach as well but in this type of teams it’s more significant.
Interested to share your experience or add something? Please leave a comment below.