Collaboration Tools for remote team members
Over the last 15 years, I have been working with companies helping them develop and bring products and services to market - you'll see a number of them listed in my LinkedIn profile. A big part of those engagements was developing fit-for-purpose processes and coaching the teams to build their experience and capability in using those processes - I wrote a blog on this recently (Oops, I said the "P" word....). These processes ranged from engineering practices, product development, sales, marketing, customer success, strategy, research, etc. Core to these processes is how the company operates, and teams collaborate together to get their jobs done.
While it was important to get the processes right, it was also critical that easy to use and powerful tools were provided to support the process and the teams to collaborate, including remote team members. And now having all team members working remotely is having to become a reality.
If you have looked, you will know there is a dizzying number of tools out there, and it can be a big undertaking to review them to narrow them down. In the end, you need to pick one and hope that it delivers on what it promises. And then you need to figure out how to best set them up to work effectively.
Here are some things to consider:
One tool to rule them all?
One of the considerations that you will need to make is whether you choose one tool that does everything, or integrating best-of-breed tools together to achieve the same purpose.
The idea of one tool is certainly very attractive where the functionality works "seamlessly" together, one set of licenses, etc.
But the reality is often that while they claim to do everything, they don't do anything particularly well. The licensing models are often expensive (where some companies are forced to restrict who has access to the software to bring the cost down, thus losing the benefits of collaboration features) and inflexible.
On the other end of the spectrum, we have the best-of-breed tools. Each tool has powerful functionality and are finely tuned to do what they specialise in really well for a particular part of the business, eg: a tool that the development team would use versus a ticket management system for customer support. But in order for those teams to work together, the tools need to be integrated. If not done well, this can be frustrating for users that may have to login into multiple systems and confusing because the user interface is different between the tools. And if the integration is not as seamless as it should be, the teams struggle to collaborate and things start falling through the cracks.....
It's not all about the tool - don't put the cart before the horse!
As mentioned in a previous blog, do not be fooled to think that implementing a tool is going to magically solve an organisational problem or change the way people are working, eg: implementing JIRA to make the team Agile.
The focus needs to be on the strategy, the specific objectives of the business, and which best practices they wish to adopt. This will guide what processes are required and then what tools are required to support those processes.
Configuration vs. Customisation
One of the key decisions you need to make when implementing a tool is whether you make the tool work how you specifically want it, or whether you change the way you work to align with how the tool works.
It's nice to think that tools should work how we want them to work - we are the customer after all! But the reality is far from it and can cause all sorts of issues.
Firstly, let's be clear on the difference between configuration and customisation:
Configuration - configurable parameters that allow you to change the way the application works, eg: adding custom fields, changing workflow, etc
Customisation - where the software vender needs to make software customisations specific to the version of software you are using
In short: configuration is good, customisation is bad!
Customisations are bad for a number of reasons. It can become very costly to make the changes in the first place, and then if you want to upgrade the software to gain access to new and updated features (and bug fixes), then you have to pay again. And the customisations are often compromised because you are trying to do something different from what it is designed to do.
So how do you avoid customisations? As you would hopefully agree, there's more than one way to do things. Often, but not in all cases, the way the software works and configured is aligned with industry standards and best practices. My advice is to seriously consider that it might be easier in the long run to change the way you are working - it might actually be a more effective way of working ......
Configuration - there is more than one way to skin the cat
While I have strongly recommended configuration over customisation, configuration has its own set of issues... sorry...
What I have found over the years working with a range of tools, they have added many ways of configuring the tools with a whole range of parameters. But again and again, I find that there are literally thousands of permutations of the different parameters and it often comes down to only one or two permutations that actually work really well. Each tool has its own particular legacy inconsistencies and non-intuitive ways to configure them. And unfortunately, there is no training you can do, video you can watch, or a single post you can read amongst the multitude of community posts suggesting different approaches.
It comes down to trial and error and experience to figure out which permutation to use. And this comes from doing it many, many times. I wouldn't like to think of the many hours/days/weeks/months trying to find the best way to get the tools to work and refining them. But it has become one of my 'super-powers'.
So hopefully that this is useful and you know what to consider.
From my experience with a range of different tools and implementing them for many companies, I have found myself utilising the Atlassian tools as well as their ecosystem of addons (refer note below). They aren't perfect (no solution is), but they are as close as I have been able to get through architecting the solution and configuring them optimally to support the processes.
I am implementing processes and systems for a number of customers at the moment (as well as supporting several meetup groups to move from in-person events to virtual events), but if you would like some help, feel free to reach out.
Cheers, David
BTW - I do not own shares (but I probably should) nor am I paid by Atlassian (apart from one teeshirt they gave me a number of years ago at an event), so my recommendation is based on my experience and the experience of the companies that I have implemented them for.