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..
Once they're working for you and you understand your developers, either you'll figure out something, or you won't.
Quit trying to stuff them into boxes before you even know what makes them tick.
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
I work in a matrix team where we look after functions but across multiple projects. Certain people in the team focus on specific projects but what try to maintain is the communication within our team for issues across the various projects as more often than not, we have common or similar issues and if someone has a resolution, it may help on other projects too. It's also useful as a lessons-learned sharing so that if others face something similar in the future, they have documents to refer back to. So make sure that even if you have people working on multiple projects, they talk to each other and share best practices etc
You cannot serve.
My ism, it's full of beliefs.
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.
How can I build cohesion, alignment and trust for my team of embedded software developers in this new three-dimensional distributed matrix organization?
- Build plenty of slack into the project plan for when (not if - when) things go wrong.
- Don't put forth unrealistic commitments.
- Allocate their time accordingly.
each with their own independent project managers
Good project managers are worth their weight in gold. Crappy ones are worth their weight in lead drowning out a project. Really crappy ones will drag down other projects as well as their own. That is going to be your biggest risk - not the developers. Make sure you have a handle on your project managers and mitigate that risk first. Then focus on your developers.
As a manager for multiple developers all working on different projects, for different product owners, what is the benefit that you're trying to bring to these developers? If you can answer that, we can probably come up with some things you can do to reach your goals.
Easy Online Role Playing Campaign Management
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.
If you've hired people who need management into that situation, you've hired the wrong people. You need smart people with good time management skills who are not assholes and can work together like grownups without any oversight despite whatever personal differences they may have. They should also be humble enough to ask their peers for help when they are in over their head on something.
Good luck!
Hello there, may I suggest looking seriously at using systems like Watson or other AI systems to learn project management concepts and project tracking, this way you will be freeing yourself from the hassle, you can automate virtually every aspect of your project management processes and make it possible for a decision maker like yourself, to make informed decisions regarding team member, different development methods and other project and business related matters based on best practise methodology for each project type and real world learning regarding the dynamics of project types and each individual project....
MS, ALS, Aphasia ? http://globability.org - Me http://einarpetersen.com
Oh, hi Mervin!
Nice to see you here. How are things in your new job?
bickerdyke
And MongoDB, Agile, Ruby, Python, and Python.
putting the 'B' in LGBTQ+
How?
putting the 'B' in LGBTQ+
I work for a medium sized multinational, and the development teams I work with are exactly as you describe. (I'm in systems integration, so I get to make their output work in the real world.) Many of the senior managers in our company have a professional services background, so development is run like a typical offshore body shop, even when the developers are local. Developers are plugged into a project and disconnected when done like they're working for one of the outsourcing code factories.
The short answer is that it's very difficult to manage developers pulled in a million different directions. Agile is definitely in use here, but the reality is that the nature of our work means that developers actually need to understand a little more than a code specification to do the work. They also need to stay involved after writing their code for that reason, but are often pulled off projects because someone shouts loudly enough or is politically connected. As a result, my experience talking with them is that no one ever feels they can get anything done to a reasonable degree before getting unplugged and reconnected to something else. Project management isn't the best around here as a rule, so there's constant emergencies.
When you're "matrix managed," the actual manager is pretty much responsible for your performance review. The rest of the management direction comes from project managers that range from good to extraordinarily bad. I know I wouldn't want to do dev work in that environment, nor would I ever in a million years want a PM job. But, with DevOps being a thing now, I imagine it's just around the corner for us too.
Manage the PMs, let them manage the devs.
I came to the datacenter drunk with a fake ID, don't you want to be just like me?
Agile doesn't work for us; 7 teams time zones 12 hours out in some cases (i.e' half way across the globe), 300 employees (developers, testers, managers, support teams, architects etc.). A couple of the teams were part of other companies which were acquaired and their companies networks were pasted into ours and so we have large numbers of hops and so lags which makes downloads across teams of artifacts difficult at times (1.5. day sofr a standard completely provision and integrated application).
Due to time zone differences communications is hard and constant close communication is the lynch pin of Agile. I don't think Agile scales well or works well with large projects. A water fall with a 3 month release schedule and restricted scope works better, IMO.
putting the 'B' in LGBTQ+
Managing such this type of team is no different than any other complex distributed virtual team. 1) Governance: get all the teams working from a single sheet of strategic music (HOW them implement is their decision) otherwise you will continue to experience too much organizational (team-to-team entropy). 2) Program/cross-team Trust: Trust is built through face-to-face meetings (early on) and takes time - scheduling either face-to-face meetings or conferences on some regular basis (the more distant the teams the fewer you'll be able to do physically), can also leverage video meeting technologies (i.e. vidyo, netmeeting, skype for business, skype, etc.) on a more frequent basis. To ensure folks are all working on same plan, the lead PM should implement the "Master Kanban" board from which all sub-teams driver their Kanbans/Sprints. RRP's should be frequent, regular and scheduled so there are no surprises. 3) Accountability: hold folks accountable, whether it's good stuff or bad... communicates that no one is special. Definitely cheer the good and definitely help those who aren't cutting it to improve but if they continue to not deliver you GOT to deal with it. 4) Master repo: maintain a master repo (used by testing & deployment) that pulls from all development repo's (sub repo's constructed by what makes most sense). Ensure you have rules set accordingly for pushes such that ALL pushes are tested prior to allowing that push to be integrated onto the master trunk version. 5) Continuous Build/Test: gospel!!! must have or else!!! 6) Design review whenever possible (doesn't have to be crazy, stickies on the wall, take a picture, quick document the workflow/etc.) just so everyone understands the goal, the intent and the initial roadmap. 7) Code reviews: must do prior to any push to master repo 8) Code base: be smart, be practical, this isn't supposed to be a death march but have a test(s) for each capability/function to verify it works as intended/designed 9) Management/PM's quiet in development team's RRP 10) Management/PM's have their own separate planning cycle and stand-ups that don't involve developers 11) Owners/Product Managers: push back on management but ALSO on development teams to challenge the initial response... Management always wants more than can be delivered and developers always cry that too much too soon.... Truth is in the middle. 12) If this is a long-term gig; have regular large conferences/team meetings where folks get to show-off their deliverables and how they were successful. Good work deserves recognition. Others can learn and improve. 13) Roles & Responsibilities: ensure that everyone assigned to the project/program understands their role & responsibility (foundational for accountability). For developers, there should be a common Developer's Agreement (deal with IP, etc.) for the overall project but there should/could be a similar agreement for each company/contractor if you have multiple teams working a single company/contractor's code. 14) Agreements: have your NDA's and IP management agreements in place before the work starts
And, to be honest, I don't recommend it, but it doesn't sound like you have any good options, so it you may as well try a better bad option. Base it on internal billing. Since the project managers will prioritize based on their projects, the priorities will be inherently heterogeneous. You need a homogenizing metric and that's the purpose which money serves.
Any guest worker system is indistinguishable from indentured servitude.
First off, this is a good question, since I see this happening more and more.
It can be done, it is just highly inefficient from a management perspective. More of the manager's time will be spent soliciting and providing feedback. Without being there in person, if there is a performance problem, it may be hard to tell what the political situation on the ground is like, and whether the team dynamics, developer or PM is at fault for any project-related issues that come up. And there is no substitute for in-person meetings when it comes to providing reviews, feedback and coaching.
If you are a manager in this situation expect to travel quite a bit in order to meet with your team members (at least quarterly) and their local co-workers and PMs. If, by chance, your company does not permit that sort of travel or you do not want to travel, I recommend finding new employment. It is not likely to work well.
I would not want to manage in that sort of environment unless I understood what problems they are trying to solve and was convinced that it was the most efficient way to solve it. The real key question for me has always been "are they paying me enough to put up with this shit?" It's going to be a lot more shit to deal with. You should expect to be compensated for it.
the growth in cynicism and rebellion has not been without cause
If you are a Project Manager, sure Agile, Kanban, Scrum, lots of good ways to make sure that people can say they are going to do something, say they did it, and show it to somebody else.
If you are a Development Manager, your first questions should be: Do I know what I expect out of my people? Do my people know what I expect out of them. Do I know how to look at their work and tell if it is any good?
I have managed people across geography and timezones on matrixed work. We did it with weekly 1 on 1 meetings over videoconference, Devs would tell me what they have been doing, show me code in screen sharing, and talk about expected results of that code.
If you are a Dev Manager, think like a developer and stay close to the technology, make sure your staff knows you expect to see results. Have meaningful, helpful things to say about their work.
If you are a Dev manager and you can't look at their work and tell if it is any good, get a job as a Project Manager.
Well, git is a tool, but it's for source control, not managing users.
The problem of managing multi-project multi-site development seems to be very much like what we do at work. A lot of overhead and processes that not really fits anyone. Nobody has a really good picture and the system team that shall hold this together have some crazy notion about that Enterprise Architect shall be used to structure the requirement perspective.
The only reason that we do get something that works is that some people works their asses off and other people stands as gatekeepers and quenches the wildest requests.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
Don't need managers, get team leads instead. The whole reason there's one manager for so many teams is that upper management is saving money: workers are dirt cheap, managers are precious resources. Workers keep their heads down, managers have to attend a thousand meetings a week (all on corporate time not foreign time).
I've been managing teams of developers for well over 15 years, periodically assigning smaller teams from project to project. There are quite a few moving parts but it can be managed by one or more managers. It's not unusual that I'm both manager and co- developer on a given project, a DBA for another, and solely admin for yet another. Some components must be common across all projects, namely task management and time tracking (where applicable). It's wildly helpful if code versioning is also centrally managed and integrated into task management. Messaging between individual team members should be consistent across teams but groups isolated by project so as not to create cross-project noise. Reporting and accountability tracking are crucial, as well as monitoring of individual performance (from commits) vs time and customer budgets. That's probably the most complex system I had to build to manage my teams: staying within customer budgets, developer available bandwidth and accountability. I built everything based on mostly open sourced components and tied them together with my own code based on rapidly evolving needs as customers arrived and left over the years. There are purchased apps and services out there that provide comprehensive albeit expensive solutions.
Do not try to "manage" them, but try to help them achieve their goals. Be the enabler, ask them what they need to complete their tasks, and make it a priority everyone is able to function at their peak.
This of course setting up shared calendars, VC software/hardware, DVCS, and so on on the techinical side. People should be able to see what they are supposed to do, reach their peers for information, and gather together to talk about updates, and have ideas (on the VC).
On the personal side, try spending some time with each member every week. Communicate what is expected of them, and let them tell you their worries.
As long as you have competent developers, they should be able to handle the job. If you do you job well, they will not even realize you're there.
The developers must be sufficiently experienced that they can manage themselves. You can coordinate and advise, but you can't do classical "management" if you are not there. If they are good, you are good. But if someone hired the cheapest that could be found, then you are "up the preverbial polluted waterway without a means of propulsion".
In most big companies, matrix management does not work. But if you have good people, almost anything can work. 8-)