Teams of One

Judging from personal experience as well as talking to others in the industry, it seems that many small to medium non-IT companies like assigning a single developer to a project. For a while I attributed this to management's ignorance. When you have 5 developers working on 5 projects, it may seem that you can crank projects out faster than if you had 5 developers working on a single project. In fact I was once told as much by a boss (who got to be a Director of Software Development merely by just being there first, long enough, and knowing how to put together Paradox forms).

While I'm not going to say that ignorance isn't to blame, it won't be at the root of the problem. It dawned at me -- as I was digesting agile wisdoms acquired over the last three days in Scrum talks -- that the actual problem is much more sinister. Managing a team right is tricky: one has to coordinate people, has to make sure everyone's personalities match, has to plan ahead, has to step in and resolve disagreements and conflicts, etc. Since running a team properly is time consuming, the natural tendency for a manager is to fall back to the control-and-command style. But controlling people is easier when they are divided, so in the end, oftentimes subconsciously, the manager will split the department into one-person teams.

This is a problem that oftentimes cannot be solved from below with education. It can only be solved from above by a competent superior either with a reprimand or with a straight out replacement.

Running a team is a tough job, but the reward for doing it right is tremendous: a happy, engaged and productive team cranking out projects like a heartbeat. When searching for a job, any environment where people work on their own projects should immediately set off the "bad management" alarm.