An anonymous reader writes: I work as a software developer in a company which builds industrial and automotive computers. I've recently been offered a position as line manager for a new, distributed team of software developers. All embedded software engineers from multiple offices in different countries are now being reorganized into this new distributed team, as opposed to belonging to any specific office. An advantage would be that this new team has better control of its own development practices, processes and tools since everyone are working in the same field; embedded software. However, since we operate like a matrix organization, I would be allocating the resources in my team to various projects managed by independent project managers, where a typical project spans both hardware, embedded software and mechanics to complete the product. Every project is different and they can operate very independently.
While there's extensive material throughout the Internet on best practices for managing distributed teams, it seems to either take an agile perspective, the project manager's perspective or be otherwise based on the assumption that everyone in the team are working in the same project. In my case, I'd be managing a distributed team of developers all assigned to different projects. Therefore it's very unclear to me which parts of the available online advice about managing distributed software teams are applicable to my situation. How can I build cohesion, alignment and trust for my team of embedded software developers in this new three-dimensional distributed matrix organization?