Slashdot Mirror
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?
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?
Whoever mentions the word "Agile", do the opposite of what they say.
"Please state the nature of your emergency." (EMH mark 2, Startrek Voyager)
Hello AC, welcome to slashoverflow.
The question as formulated now is vague. There is a proposed solution (managing) but no problem stated that needs solving.
And what you have tried to resolve this problem.
Hivemind harvest in progress..
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.
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?
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.
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.
Do not look at laser with remaining good eye.
How can I build cohesion, alignment and trust for my team of embedded software developers in this new three-dimensional distributed matrix organization?
It's a traditional matrix, nothing special about it. Manage each team individually the same as any other development team;, the fact that they're matrixed is irrelevant. Occasionally (maybe once per quarter) have an all-hands meeting and have each team give a 3 minute presentation on what it's doing so people have an idea what else is going on, same as any other large development organization.
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!
I work on a very similar team, about 25 people, distributed globally, all contributing to various Open Source projects, all with different processes, governance, etc. Our managers focus on handling the management and human resources bits, ensuring that I have what I need to do my job. Most everything else; time management, development process, tooling, location... even travel, etc - is left up to me.
I personally feel that the key to the team is the core belief that everyone's an adult, and can manage themselves and their own work. Managers aren't authoritarian, they're coaches. We're all encouraged to be strategically minded, though a lot of that is taught and socialized in the team's always-on IRC channel. The team was founded by adapting the Valve handbook, throwing out all the things that require people to be colocated. Other than that, the unique dynamic of autonomy, mutual respect, support, and the freedom to ask any question - no matter how dumb it may seem at the time - isn't something I've ever seen reproduced elsewhere.
This signature can save you $400 on your car insurance!
"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
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.
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
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.