Ask Slashdot: How Can You Manage Developers Distributed Across Multiple Projects?

An anonymous Slashdot reader asks whether it's possible to manage a "distributed" team of software developers in different locations who are all assigned to different projects, each with their own independent project managers: All embedded software engineers from multiple offices in different countries are now being reorganized into this new distributed team [with] better control of its own development practices, processes and tools, since everyone is working in embedded software...

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. How can I build cohesion, alignment and trust for my team of embedded software developers in this new three-dimensional distributed matrix organization?
Anyone have any relevant experiences to share with distributed teams or "matrix" organizations? Leave your answers in the comments. How can you manage developers who are all distributed across multiple projects?

Comments

Some advice from experience

[Anonymous Coward]

I've been in this situation before, and in some ways still am. Here are a couple tips:
- This matrixed team structure was likely put in place because the company thought there would be advantages to having these developers interacting even if they're not working on the same project. Get together, maybe once a month, and have people present on the project they're working on. It'll help give everyone visibility into everyone else's work, give some practice presenting, and provide a great opportunity to share best practices.
- More tactically, provide some social platform for the team interact and ask each other questions. We use Yammer, but a Slack channel would probably be effective too.
- You're probably responsible for some level of coaching/mentoring for your team even though you're not directly working with them. Meet with them individually and regularly to find out how they're doing and how you can help them. You'll also want to set up some regular check-ins with their project managers to get their perspective.
- Finally, you may he responsible for setting technical direction and standards for the team. Unless you're highly revered and have already earned a ton of respect for this capacity, you'll need to build some consensus rather than ruling by decree. Seek advice and feedback from your senior team members before presenting your approaches.

Best of luck!