It’s a well accepted fact that teamwork usually produces better outcomes than a single individual’s work. It’s easy to see why:
- some parts of the work can be worked on in parallel by team members
- redundancy is improved
- diversity makes it easier to find a better solution
This makes it natural for companies to organize into teams, each responsible for a given business goal. Often, though, I see companies building teams that aren’t really teams, but just a group of individuals. Despite belonging to the same team, the “team members”’ work is unrelated more often than not and the only thing they share is who they report to. I’ll call this a fragmented team.
In my opinion, this is a problem because it defeats the purpose of having a team. While there still might be collaboration happening, there is a huge cost due to context switching (since your colleagues aren’t up to speed on your work, you have to explain a lot of more). This is particularly troublesome in the software development industry, where many of the industry’s best practices revolve around peer interaction (things like pair programming, code reviews and daily meetings). Since the fragmented team doesn’t really share a concrete common goal, these practices become an exercise in frustration and starting lowering the team’s morale. As an example, meetings can devolve into mere reporting or just monologues, where everyone but the person speaking tunes out because there is very little value to take out of it. Even if a meeting takes 15 minutes, on a 5 member team, you’ll spend an average of 3 minutes talking and the remaining 12 thinking what a waste of time it is.
From an outsider’s point of view, fragmented teams give a false sense of security: calling it a team misleads you into thinking that there is some redundancy, when any small disturbance can have a disproportionate effect on the team’s output.
Identifying a fragmented team
Fragmented teams usually show a number of symptoms. Some are easy to identify, like looking at the team’s mailing list and noting that there are various unrelated topics popping up; there should also be a clear pattern of which team member answers which topic. You might also see things like “Matt is in charge of that but he’s on vacation, he’ll pick it up when he’s back”.
Another is walking into the team’s room and seeing how often they talk to each other, particularly if they need to explain the context of their work.
Meetings are another indicator that a team might be fragmented: like I pointed out above, people just take rounds talking and everyone but the person talking tunes out.
Analysing each member’s footprint can also be significant, since, in a fragmented team, there will be little overlap. On a team of 6 people, you might see the same 2 people commiting into an application’s source, while the remaining commit into another, unrelated, application.
Why fragmented teams are created
I believe that the main reason for creating fragmented teams is a poor business goal oriented company structure. Companies thus structured tend to allocate teams to work on products, rather than business goals. A team can then be responsible for 2 or 3 products which reflect different business goals and fragments when those business goals conflict. An extreme of this is the creation of transversal teams: teams which effectively centralize a purely technical function and so must cater to every business goal. Like an army fighting in a several large warfronts, these teams end up fragmenting.
How team fragmentation can be avoided
Since fragmented teams are originated from poor business goal orientation, it follows that they can be “fixed” by closely aligning the company structure with the company’s goals.
For teams that are already fragmented, the solution is either splitting the team into official teams or offloading some of the work into other teams.
None of these are, of course, a one-shot affair: you must keep making adjustments to the structure to keep the company as a whole focused and efficient.
