One of the critical catalysts that facilitated the rapid innovation we see in software development today results from collaboration. It's amazing how software engineers can work on a project from different locations with (sometimes) different languages and find a way to make the different pieces fit. While it doesn't look like much you should remember that cloud computing now allows people to edit the same office document like word, slides, and excel documents yet the market hasn't fully adopted it because working on the same project in real-time is harder than it sounds.
Teamwork doesn't always make the dream work
Teams aren't all rainbows and sunshine, collaboration bears the risk of failure if there's a weak link and at such times technical skill isn't as important as emotional intelligence. A lot of times, the most competent person on the team or the leader of the team bears the brunt of the feedback from irate clients, at other times you're receiving the feedback because you did something wrong. The ability to take feedback without being defensive is an underrated skill.
Advice from a CTO
I asked Daryl Orts about handling negative feedback and he had some insights I feel are worth sharing. As much as it is important to save face and not look totally inept, It is just important that you don't lie to whoever is giving you feedback, taking ownership is very important here, equally important is outlining your next steps that should ensure that the issue is addressed and that it doesn't repeat itself. A lot of developers tend to blame their teammates, legacy code, tools, and even their devices when things go wrong. It's not a healthy culture to imbibe. You should empathize with whoever it is that is giving you feedback because the average person doesn't look forward to giving negative feedback (it stems from serious discomfort with a product, service, or conduct). You become easier to work with when you're more approachable and more receptive to feedback.