Collaboration as a Tool towards building great teams

What is cross group collaboration? When I was first introduced to this concept in my previous organization, I was wondering what it is and why there is so much hype around it. So much so, it was included as a part of a competency that you could measure the effectiveness of yourself while working with teams located across the globe. Now that was a different story as the Organization was so huge that there was an absolute need. Looking at the competency and thinking through the lines of our day to day work there is a lot of benefit in this simple but very useful practice. What I realized over a period of time is that if someone in the organization has invented or improvised upon a useful piece related to Process or Technology, why does a different group need to re-invent the wheel and waste expensive time and resources. They could re-use the same and leverage the time for something more valuable. The key to this aspect is to understand how does the existence of a wheel that got created by group A comes into the limelight of the organization or gets communicated to group B who is working on a related piece of work. This is not rocket science or it is based on a tool. It is all in the peoples mind as well as willingness to share as well as show case the work they have done. Be it side projects or anything that is a part of the mainstream project work one is involved with, fostering this show casing approach shall pave way to reduce time spent on expensive resources, avoid duplication of the work done by someone else. It helps improve communication, obtain formal feedback in a win-win fashion
There is ample scope to improve one’s connections within an organization where you meet and show case your work with a wider audience for a given concept. How does this happen. A simple way to get this done is via brown bags, collaboration sites, knowledge sharing sites, blogs etc…
There could be client specific restrictions on what could be shared Vs what cannot be shared. Anything of this sort can be made generic for the Audience to avoid conflict of interest or anything that may breach the laws of confidentiality with customers.
For this competency there are two facets. One is a proactive one where the knowledge is shared on a continuous basis via collaboration portals tied up with enterprise search engines where everyone in an organization can access information based on access control lists. This approach may be unrealistic in that due to our day to day responsibilities and a constant pressure one may not feed data to these repositories while these individuals are required to accomplish more important deliverables. So the intent to share your world class code or design practice or a process improvement may not happen on the fly other than information being in people’s heads or local drives. The willingness to share sets the stage for cross group collaboration.
The other facet is a re-active one where a project team starts approaching other teams who have worked on a related problem space. This is where the real challenge lies wherein the team possessing the knowledge needs to have bandwidth or the inclination to share the nuts and bolts which usually is lost due to project priorities taking precedence. There could be formal process to leverage this via an organization’s hierarchal relationships, but this is not as simple as it may seem. In reality most of the times, access to source code and artifacts is made available but the priceless information in people’s heads is not transferred.
The key to this competency can be highlighted when you are working on a large project and you know in advance that the tools and technologies required by your project have already been touched upon by groups that are globally situated. Getting the right contact and initiating a meaningful dialogue to accomplish your task. Most importantly, what if your team decides that the component you are interested can be re-used with some minor modifications. Extensibility and object oriented approach is one approach, but what if you could convince the team to make the changes for you by raising a change request. Would that not be beneficial instead of re-inventing the wheel while focusing on more important aspects to avoid a lengthier cycle of software engineering
These situations are best observed when acquisitions happen between companies and there is an absolute need to collaborate in a win-win manner. To conclude, regardless of the size of the company, collaborating with teams where synergies are visible always cut down the cycle times for release to market