Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Businesses The Matrix IT

Ask Slashdot: How Can You Manage Developers Distributed Across Multiple Projects? 112

Posted by EditorDavid from the believing-the-unbelievable dept.
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?
This discussion has been archived. No new comments can be posted.

Ask Slashdot: How Can You Manage Developers Distributed Across Multiple Projects? More

Ask Slashdot: How Can You Manage Developers Distributed Across Multiple Projects?

Comments Filter:

  • One approach (Score:5, Interesting)

    by jetkust ( 596906 ) on Monday June 20, 2016 @07:40AM (#52351053)
    Whoever mentions the word "Agile", do the opposite of what they say.

    • Re:One approach (Score:5, Funny)

      by fintux ( 798480 ) on Monday June 20, 2016 @07:43AM (#52351063)

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

      So... Should this advice be followed or not? The A-word was mentioned, after all...

      • Re: (Score:1)

        by Anonymous Coward

        Ah yes, the strategy of listing all strategies as Agile or not-Agile, in which list do we put such as strategy?

        • What about the odd time of double references? I feel like we're going to need a flowchart before too long defining who said what, when, and the dependency trees of their arguments.

          • Re: (Score:2)

            by plopez ( 54068 )

            I think we need a video conference on this. WHat itme is good for half a dozen teams located across 6 time zones?

            • You think we should jump straight into this? Why not have a planning meeting for the video conference meeting?

              • Re: (Score:2)

                by plopez ( 54068 )

                Whoa! not so fast. Don't you think we a pre-planning agenda framing conference call?

                • Whoa! not so fast. Don't you think we a pre-planning agenda framing conference call?

                  somebody needs to document an agenda for the meeting to establish the goals of the pre-planning agenda framing conference call, that we can have a meeting to discuss. probably need to meet in person to ensure we get it right, rather than start off on the wrong foot.

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

      In other words, don't do unit testing.

  • "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.

    • Re: (Score:2)

      by Barryke ( 772876 )

      After reading the article again i see:

      > build cohesion, alignment and trust for my team of embedded software developers in this new three-dimensional distributed matrix organization

      I say create a common enemy for those people, and then use that to steer them away from certain things. Fear and anger can accomplish great things together. So any kind of management would do, i guess. As for the three-dimensional distributed matrix organization, i have no idea. Perhaps look into the Borg.

      • After reading the article again i see:

        > build cohesion, alignment and trust for my team of embedded software developers in this new three-dimensional distributed matrix organization

        I say create a common enemy for those people, and then use that to steer them away from certain things. Fear and anger can accomplish great things together. So any kind of management would do, i guess. As for the three-dimensional distributed matrix organization, i have no idea. Perhaps look into the Borg.

        i for one welcome the new three-dimensional masters of Flatland.

  • 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.

    • 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.

      management technique most popular; stuff them into boxes before you even know what makes them tick; then when you find out what makes them tick, nail the box shut.

  • You can't (Score:3, Interesting)

    by undulato ( 2146486 ) on Monday June 20, 2016 @07:51AM (#52351091) Homepage
    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.
    • As someone who works in such a team, I generally agree. We have a hierarchical reviewer/reviewee structure that allows us to manage performance reviews in a reasonable (if enormously time-consuming) way and enough communication methods to create a sense of community for those willing to get involved but trying to impose common tooling, processes and standards across close to 100 developers working in different locations on different projects for different customers with different attitudes and requirements

      • What is the reason that this is organised as one team instead of multiple teams?

        Developers working in different locations on different projects for different customers sounds like the definition of multiple teams to me.
         

        • People are members of more than one team at any given time. We have project teams and we have discipline/community teams (e.g. a .NET developer team, a JVM developer team, an architect team, a BA team etc.) and each is used for the purposes that make sense such as managing training, pay and performance across all of the comparable developers instead of a single project team.

        • What is the reason that this is organised as one team instead of multiple teams?

          Developers working in different locations on different projects for different customers sounds like the definition of multiple teams to me.

          i was thinking the other day..... about dogsled racing. you know like the iditarod. that started me wondering whether there was a top speed record for dogsleds, that started me thinking about designing a world land speed record dogsled.
          first think i thought of in the design: hook up a hundred dogs.

    • Re: (Score:1)

      by Anonymous Coward

      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.

      What you are assuming is that the Matrix manager is key in the role of these people's work. In fact the key leaders will remain the project managers because they have the money and customers and they are delivering the real results to real people. What is the point then you ask?

      Well, what this guy has to do is to find something useful. The basic expectation is that there will be


      • money saving because projects won't have to keep people idle
      • happier employees because they won't feel that their work is depende

  • Suicide (Score:3, Interesting)

    by Dog-Cow ( 21281 ) on Monday June 20, 2016 @07:52AM (#52351095)

    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?

  • No team (Score:5, Insightful)

    by WPIDalamar ( 122110 ) on Monday June 20, 2016 @08:05AM (#52351145) Homepage

    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.

    • 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.

      I disagree. Even if they're working on different projects, if they're working on similar sorts of things -- similar platforms, tools, problems, etc. -- there's value in collaboration. Cross-pollination of design ideas, factoring out of common, reusable code components, sharing of ideas about what makes code better and more maintainable, collaborative problem solving -- there's a lot of value to be found in applying multiple brains and viewpoints.

      There's also significant strategic value in ensuring that ea

    • I worked on a project that was similar to what was described -- four of us all at different institutions, working on a single project.

      The management mostly left us alone, and we got the project done. As we're in a more 'maintenance' phase now, we just have annual face-to-face meetings to hash out what we think needs to be done and how long it'd take to do it, and then we present it to the 'steering committee' (management / scientists who use the software) who decide what we should or shouldn't focus on for

  • Hands off and let them do their job. (Score:5, Insightful)

    by Lumpy ( 12016 ) on Monday June 20, 2016 @08:11AM (#52351165) Homepage

    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: (Score:2)

      by clodney ( 778910 )

      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.

      Totally agree. The role as you defined it is pure staff management. So the sort of thing you do:
      * make sure that your developers have what they need in terms of equipment, tools, software, etc.
      * ensure that they have the necessary training and opportunity to get training when required (or slack time for self study)
      * don't let the PMs bully them into false estimates, or put them in death march mode
      * work with the PMs to find out if some of your team members aren't getting it done, and take action
      * make sure

  • Three-dimensional? Huh? (Score:3)

    by tomhath ( 637240 ) on Monday June 20, 2016 @08:14AM (#52351175)

    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.

    • 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 could not agree more!!!
      Lots of companies I have worked in seem to treat everything as a secret, or just have really bad communication at any rate. You find out about things happening through the grapevine, and all the broken telephone crap that comes with that.

  • Some advice from experience (Score:5, Informative)

    by Anonymous Coward on Monday June 20, 2016 @08:19AM (#52351187)

    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 themse

    • This matches my experience.

      One of the big things we worked on to make disparate parts work together was facilitating communication. We encouraged senior guys to coach-up more junior guys - offering suggestions and such - but we also encouraged just general communication. So if they felt like having chat sessions about last night's episode and wasting a couple of minutes, nobody said anything. This helps turn "a bunch of guys" into a team.

      The team part is important when the crap hits the fan. There's al

  • Three Dimensions? (Score:5, Interesting)

    by Carcass666 ( 539381 ) on Monday June 20, 2016 @08:25AM (#52351201)

    "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
  • You cannot serve.

  • Be a good project manager (Score:1)

    by Anonymous Coward

    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 f

  • 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.

    • I think there is a world of difference between a manager and a team leader, and in most organisations there is only really one manager, the CEO, everyone else is leading teams and taking resistibility for various roles in support of the manager. As a team leader you should be supporting your team in the first order to be the best they can, not crushing their spirits or micromanaging their every action. People respond better to trust, autonomy and knowledge that what they're doing is valuable and necessary.

    • Indeed it sounds like OP's job isn't defined enough that solutions can be proposed, first problems / obstacles need to be identified. Talk to the people and find out what issues there are, what makes their job more difficult. Then look at how you can help the situation.

      Others have mentioned avoid micro-managing, treat people as adults. That's important.

      One thing the OP can look at is the maturity of development process and provide resources and training to improve it, preferably resources and training that

  • Some suggestions (Score:5, Insightful)

    by swillden ( 191260 ) <shawn-ds@willden.org> on Monday June 20, 2016 @09:54AM (#52351573) Journal

    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 [gerritcodereview.com]. 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

  • Don't (Score:2)

    by flink ( 18449 )

    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

  • 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 answe

  • Manage the PMs, let them manage the devs.
  • 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
  • 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.

  • 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-

  • 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 o

  • 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 mana

  • 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

  • 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-)

Slashdot Top Deals

The use of money is all the advantage there is to having money. -- B. Franklin

Close