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

One approach

[jetkust]

Whoever mentions the word "Agile", do the opposite of what they say.

You can't

[undulato]

Trust only comes through stability. Developers with nothing in common and different project managers sounds like a recipe for disaster and your role sounds like a potential nightmare.

Suicide

[Dog-Cow]

With the number of buzzwords you've spewed into the summary, you should just drown yourself in a nearby body of water.

If each team is doing something different, why the fuck do you need to "build cohesion"? Are you going to glue them together?

Three Dimensions?

[Carcass666]

"I'd be managing a distributed team of developers all assigned to different projects." This isn't necessarily a three dimensions challenge, and you should keep things as simple as possible. People with multiple bosses will often please none of them. If there are not clear lines of accountability and definitions of success, your only hope of this thing not devolving in a complete fustercluck will be the coders who find your projects interesting and don't have families to raise.

You mentioned you "independent project managers". If you are thinking about the Scrum flavor of Agile specifically but have project managers you are likely doing something wrong. More important is product ownership. "Agile" development success largely depends upon decisions being made on a daily basis. If your product owners are not engaged on a daily basis directly with the developers (even when cross-timezone meetings are painful) you're doomed.

Find your local leaders, the people who get things done. You need people on the ground who understand the culture and trust you enough to let you know what is really going on. It will be far easier to build these relationships if you regularly travel and engage with them. Do not delegate this part of your job, you are not going to be able to cultivate your leaders over video conferencing. People behave very differently in-person.

Oh, and keep your staff off of The Register, which has devolved into a DevOps cheerleading site - nothing good will come of it