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

Re:Plenty of experience

[sh00z]

Here's a clue: you're not managing them. You might be their "supervisor," assigning them to projects, signing their timesheets, etc., but this is a simple matrix structure, and the Project Managers are managing them. You should be working with these PM's to hear about performance issues or praise, training requirements, vacation plans, etc.

Re:One approach

[MightyYar]

You probably have a management team who actually understands the intent of agile and crafted a system which embraces the spirit while working well with your particular needs. Many just rename their round-robin micromanagement meetings as "scrums" (only they force everyone to stand the whole time) and re-badge their glacial feature planning process as "stories". Basically, they read the books, adopt the terminology, and ignore the parts that don't mesh with the practice they already like. So, agile in name only and of course all the staff hate it.