Moving People Around

Every few weeks or so you exchange tasks between all of your programmers. By making sure everyone on the project has a chance to work on every section or sub-system you get people who can, and do, work on all parts of the system efficiently. It encourages CollectiveCodeOwnership. The resulting system is better integrated and smaller having less redundant code.

If one person stays with a particular task or sub-system of the project for too long you end up with a single person who knows everything about it and must therefore approve or review any changes to be made. That one person can be a bottleneck. With distributed knowledge you no longer need a ChiefArchitect.

Adding new functionality will, more often than not, involve several sub-systems or classes of the system. With everyone able to confidently modify any class, new functionality is added in an integrated way instead of the usual "stapled onto the side".

This is manager utopia. Being able to assign anyone to any problem or task that arises! And people do leave the project occasionally. The problem is that managers also have the belief that a project will move faster if all the programmers are assigned to what they know best. You don't want to slow down while someone learns something new. They just can't help themselves. They need to be shown that MovingPeopleAround does not in fact involve a schedule delay. Once demonstrated immediate acceptance is inevitable.

Have you tried this? It strikes me as risky in that it demonstrates explicitly that people are interchangeable as far as project management is concerned. Another approach could be to move programmers who've plateaued to a new project where they can grow. One of the people on the team will inevitably grow to fill the gap, resulting in increased capabilities for the company.

What if someone changes something significantly?

I can see in some projects, due to the technology specialization, there will be a Chief Architect to lay down the foundation of the technology, but the point is the company should strive to make sure the programmers has visibility to other parts of the product so you, as manager does not end up with single point of failure, which you often see when someone with critical knowledge leaves the team.