We use Slack, Asana, Greenhouse, Notion, and Expensify (which we use in collaboration with BERI). It’s worth trying out a few software options with a small team to see which one suits your needs the best. I’d suggest that you have 3 people try out one software at a time for 1-2 days to see what works. Software should be ultimately easy to use and easy to onboard new people seamlessly. Any kind of software that has a lot of complicated features and takes a long time to learn is likely not going to be great because if it’s complicated to use then new members will be less inclined to use it and the software will ultimately become useless. One bottleneck for software that I’ve encountered is making sure that everyone actually uses it. For example, if you are going to use a software for hiring purposes but one person in your team doesn’t want to use it or not willing to learn it, then things will likely get more complicated on your end as the person who is managing the software. Even if one person doesn’t use the software, your work will grow quite a bit since you have to balance 2 systems instead of one. It’s a simple thing to tell people who are looking into implementing software but it’s an important thing to emphasize. Some software are more flexible in terms of its use (i.e. modifying layout to suit their needs, etc) which may mitigate this problem a bit. As long as everyone is using it, then this should be fine. It’s worth documenting norms and rules related to any software and have new members read that document prior to using the software (although I often find norms surrounding software are fairly easy to grasp simply by using it for some period of time / intuitive). Another thing I’ll note about software is that software should be easy to use collaboratively and you should make sure that the software has the ability to tag different people, share documents easily, have multiple people comment on one project, etc. I suspect pretty much all software has this feature but it’s something to keep in mind nonetheless.
My general philosophy is that software is quite important to consider since it’s going to be much harder to shift your team to use a different software down the line. Suppose you choose a software somewhat haphazardly and you want to use a different one down the line, then it’s going to be quite hard to do so. I’ve often found people are reluctant when it comes to learning new software. The classic woodworking advice, “measure twice, cut once” is sort of the motto here. Also, for me, I try to keep using the same software as long as possible until a serious problem shows up. Like I mentioned before, getting an entire team to use a new software is tedious and takes a long time to implement and even if you do implement it, perhaps you will encounter problems with the software that you didn’t think about before you started to use it. There will always be new software that come out and some of them likely offer slight improvements compared to your current system but personally, unless those improvements are substantial, I ignore them.
We use Slack, Asana, Greenhouse, Notion, and Expensify (which we use in collaboration with BERI). It’s worth trying out a few software options with a small team to see which one suits your needs the best. I’d suggest that you have 3 people try out one software at a time for 1-2 days to see what works. Software should be ultimately easy to use and easy to onboard new people seamlessly. Any kind of software that has a lot of complicated features and takes a long time to learn is likely not going to be great because if it’s complicated to use then new members will be less inclined to use it and the software will ultimately become useless. One bottleneck for software that I’ve encountered is making sure that everyone actually uses it. For example, if you are going to use a software for hiring purposes but one person in your team doesn’t want to use it or not willing to learn it, then things will likely get more complicated on your end as the person who is managing the software. Even if one person doesn’t use the software, your work will grow quite a bit since you have to balance 2 systems instead of one. It’s a simple thing to tell people who are looking into implementing software but it’s an important thing to emphasize. Some software are more flexible in terms of its use (i.e. modifying layout to suit their needs, etc) which may mitigate this problem a bit. As long as everyone is using it, then this should be fine. It’s worth documenting norms and rules related to any software and have new members read that document prior to using the software (although I often find norms surrounding software are fairly easy to grasp simply by using it for some period of time / intuitive). Another thing I’ll note about software is that software should be easy to use collaboratively and you should make sure that the software has the ability to tag different people, share documents easily, have multiple people comment on one project, etc. I suspect pretty much all software has this feature but it’s something to keep in mind nonetheless.
My general philosophy is that software is quite important to consider since it’s going to be much harder to shift your team to use a different software down the line. Suppose you choose a software somewhat haphazardly and you want to use a different one down the line, then it’s going to be quite hard to do so. I’ve often found people are reluctant when it comes to learning new software. The classic woodworking advice, “measure twice, cut once” is sort of the motto here. Also, for me, I try to keep using the same software as long as possible until a serious problem shows up. Like I mentioned before, getting an entire team to use a new software is tedious and takes a long time to implement and even if you do implement it, perhaps you will encounter problems with the software that you didn’t think about before you started to use it. There will always be new software that come out and some of them likely offer slight improvements compared to your current system but personally, unless those improvements are substantial, I ignore them.