Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Is it better to assemble permanent teams of developers within the company that always work together, from project to project, or is it better to have dynamic teams that assemble for a project, and then dissasemble afterwards?

My inclination is to treat the entire company as a "platoon" and to assemble "fireteams" for individual projects, choosing from the "platoon" those developers best suited for the project.

share|improve this question
Better in terms of what metric: performance, quality, amount of work done, etc.? – JB King Jun 22 '11 at 20:54
"assemble "fireteams" for individual projects" is the standard matrix organization. This is well-documented in numerous places. Why ask here? Please clarify how we can add anything to the endless volumes of research already done on matrix organizations. – S.Lott Jun 22 '11 at 20:55
people bring different skills - assemble a team with the skills you need for a given project. – user1249 Jun 22 '11 at 20:56
@S.Lott: I have heard of software shops that work both ways. I guess I am hoping for some insight into the subject as it pertains particularly to programming and programmers. – Richard DesLonde Jun 22 '11 at 21:00
"shops that work both ways" since this is an ongoing area of management exploration and research, every conceivable variation on the matrix organization has been tried somewhere. This is covered thoroughly by numerous books on management. Start here for references and links: What would possibly make this unique to programming? – S.Lott Jun 23 '11 at 9:52
up vote 8 down vote accepted

I doubt there is a One True Way. I think there's a lot of pluses and minuses to each. Here's my breakdown:

Static Teams

  • 1 time cost of team gelling ... or at least, team re-gelleing is 1:1 with corporate retention rates.
  • more indepth knowledge of problem and solution
  • can afford to have less consistency across groups and less documentation
  • risk: Skills can fall way behind if the product does not not yeild to technical re-innovation
  • risk: change becomes traumatic when it happens

Dynamic Teams

  • constant cost of rampup as people enter and leave teams
  • everyone gets a chance to keep skills up to date
  • no one is stuck for too long in a project they hate/no one stays to long in a project they love
  • enforces inter-team process consistency, and transfer of good ideas from team to team
  • enforces clear documentation of all aspects of project to minimize ramp-up/ramp-down time.
share|improve this answer
Let me add that sometimes that evaluation and technical training (per developer) are sometimes affected by being too dynamic. Another (kinda less important) thing about Static teams, is it can really be boring sometimes, on the long term – Shady M. Najib Jun 22 '11 at 21:34

You have to consider personalities as well as needs. No all of us are built the same way, some love change and thrive on chaos, some hate it and require stability. Trying to show-horn everyone into the same boxes is bound to end badly.

The best I have come across is stable teams smaller than needed to do all the work, and dynamically allocate developers as projects come and go. People choose, within business requirements, how often they want to move, and what they want to move onto. It provides the best of both worlds, but requires good management over site to ensure it does not end up providing the wost of both.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.