Companies might fall into the trap to believe that developer experience is a nice-to-have luxury rather than a necessity. However, this is not the case. High developer productivity results from a great developer experience and thus, the companies' success ultimately relies on this.

When talking about developer experience, there are a couple of other names thrown into the conversation that all kind-of mean the same, but IMHO have a slightly different touch / focus and can be perceived quite differently.

Code ownership on a team-level can not only help to identify the team that has knowledge in a certain area, it also can serve as a signal for a mismatch between architecture and team structures.

Code ownership is an important topic when it comes to enabling your teams and allowing developers to improve the system while keeping the overhead of changes low. While today, most companies would (hopefully) agree, that individual code ownership is bad because it creates knowledge silos and makes the organisation dependent on individuals, code ownership still is essential on a larger scale.

Developer experience is a crucial topic which affects all development teams of a company. Therefore, it can be beneficial to introduce a team that has as their only mission to improve developer experience and productivity as these improvements multiply the impact of the other teams.

Whether a team works synchronous or asynchronous is not determined by whether it is co-located or not. Both teams have to make an effort, if they want their work to be synchronous.