There is a common perception that collaboration is the universal solution to all issues that software companies encounter. A lot of effort is invested in improving collaboration between tech people, starting from tools that can be easily purchased and ending with programs that encourage collaborative behavior. The idea is quite simple: if people collaborate better, the output of the entire team, both its quality and quantity, will be better.

While I do not want to mitigate against collaboration, there are specific cases where it simply doesn’t work. I will exemplify that and suggest some solutions as well.

Addressing Opportunities

Collaboration does not improve the team’s ability to find opportunities and address them. In fact, a very collaborative team will most likely miss opportunities more often than a disconnected team does. The explanation is pretty simple: when the team is collaborating nicely, each member learns a lot about the best abilities of their team-mates, which is unlikely to happen if you’re part of a disconnected team. The team usually distributes tasks very efficiently, based on abilities. In most teams, this is not something that is officially settled by a standard process, it’s just self-assumed.

This process eventually leads to a good quantitative and qualitative output, yet makes the team miss opportunities on account of insufficient analysis and simply because people tend to rely exclusively on those team-mates that are generally acknowledged as the best.

There are several ways to solve this on long term, but I will focus on how bringing troublemakers into all these teams usually helps. Troublemakers by definition will question and challenge everything and, by doing so, they will eventually make the other teammates more reactive. Nonetheless, this does not work for too long, simply because troublemakers are either essentially assimilated or rejected by the team.

Software Architecture

Many companies take great pride in having lots of architects with different levels of maturity. Usually such companies assign difficult projects to a team of architects for the simple reason that collaboration will produce better output.

While it’s definitely good to have many architects and to mentor young architects, difficult projects do not exactly benefit from an extended group of architects. The quality of the architecture will not surpass the level of expertise of the best architect in that group. The advantage of the team is that it is extremely good in raising concerns, fixing minor issues, and bringing minor improvements. However, it is very rare that it is able to totally reshape an average architecture.

Sometimes, disconnecting the architecture group and making them come up with several designs turns out to be a good idea. In this process, it is essential to keep the small teams entirely separated – no collaboration, no communication.

UX Design

Studies recommend to have different UX designs, to expose them to users, and to raise metrics. As a process, this is OK, but if you aim at achieving several exceptional UX designs, use the same process like with software architecture – split the UX design team. It’s good to have each member of the team bring their own design to the table. Once again, it is essential to keep everyone disconnected.

Of course, there are many cases where collaboration does not help, but I think you got the idea. Still, this does not mean that collaboration is not required – you simply must avoid considering it a universal solution. In fact, in all the above cases, collaboration will help deliver faster and better once the breakthrough discovery has been made.

In my next article I will also cover “global collaboration”, a concept that is overlooked in many situations.