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

No team

[WPIDalamar]

You don't have a team of developers. You have a bunch of single-person teams. Don't try to manage it as a team.

Hands off and let them do their job.

[Lumpy]

Honestly, let them do their job. if you want to be a good mid manager above the other managers. you let them do their job and you act as a "what do you need" guy that simply get them what they need and keep the fuck out of the way 99% of the time.

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.

Some suggestions

[swillden]

First, if you truly have a bunch of single-person projects, you have an additional problem that you don't appear to have recognized: You have multiple single points of failure. I often use the notion of a "bus metric" which is "the number of people who have to be hit by a bus to cause serious problems for the organization". Your bus metric is 1, but it's a little worse than that, because you have several single individuals whose unavailability would cause problems.

This second problem actually points to part of my recommended solution: If you want to build team cohesion, you need to break down the silos between the projects and get your engineers working together more. At the same time, you don't want to impose a lot of process that will slow them down.

Some concrete suggestions (in no particular order):

1. Do code reviews. In fact, make them mandatory. In general, I'm against mandating much of anything but this is an exception because it is so extremely valuable. Mandate that every piece of code checked into the source repository must have been reviewed by someone other than the author. To make this effective and not an obstacle to getting work done, though, you need tool support. Something akin to Gerrit. Do not attempt to require code reviews until the infrastructure is in place, and once it is, ease into it and make sure everything is working well and everyone is comfortable with the tools before you mandate the reviews. However, be clear that the intention is to mandate them.

2. Do design reviews. Similar story to code reviews, except that design reviews should be attended by the entire team, or at least a largish subset. Again, good tooling is helpful. In this case using something like Google Docs or Office 360 for the design docs and then a good teleconference or, better yet, video conference solution for the review meeting. In terms of breaking down silos, cross-project design reviews will be hugely valuable.

3. Do standups via teleconference or (better yet) video conference. They don't need to be daily, and if your team is all working on different things they probably shouldn't be daily. Once a week for 15 minutes is a good place to start, just go around the "room" and have everyone briefly describe what they're working on and what challenges they're having. It's the discussion of challenges that make this valuable, because others will pipe up with their suggestions. Again, before you do this make sure that your infrastructure is in place and working *well*. Also, keep a close eye on how this is scaling. Beyond a certain number of participants it breaks down and you need to split it up.

4. Encourage lots of random, ad-hoc communication among the team. Again, good tools -- VC and shared docs, mostly, but you also need good chat and email systems -- are important for effective remote collaboration. As for how to encourage it, one good way is for you to get a solid understanding of what everyone is good at and when you have one-on-one meetings with them (which you should be doing regularly) look for opportunities to suggest collaborations.

5. Set up face-to-face get-togethers as frequently as you can, within the constraints of time and budget. Ensure that these contain equal parts business-related discussion of goals, plans, challenges, etc., and chances for people to do fun stuff together -- but make sure that you find activities that everyone can participate in and enjoy. IMO, you should avoid those obnoxious "team-building" programs.

6. If you can, consider getting budget for an additional engineer to focus on common tooling. The goal isn't to force all of your engineers into a common toolset against their will, but to build up some useful common tooling that all of them find valuable. Source control, code review system, continuous integration, automated testing, etc. This tool engineer will become another central point that everyone communicates with regularly (in addition to you).

7