Teams Versus Pools

There is an idea floating around out there in the nebulous ether that what an organization needs is a group of talented people and when a project starts up you pick and choose whomever you want from that pool of talent and assign them to the project. When maintenance kicks off on that project you build another team. And when you do more maintenance? Yup, another team.

This, on the surface, seems like a wonderful idea. Every time a project starts up you pick up the best people for the job and they work on the app. Reality is a little different than fantasy, however, in that every new person that you bring in to the team needs to come up to speed on the application. Every time you get a number of people together, who have never worked together, they need to figure out how to work with each other. And let’s not talk about the matter of ownership. How can a developer generate ownership, the feeling of responsibility for an app, if they know they are only there for a couple of months at most before moving on to something else?

In the Amazon environment, whenever a team builds a service that team is responsible for the ongoing maintenance of the service. No one else. There are no SWAT teams brought in to apply a patch. The same group of people work on the service. It gives them a sense of ownership, a sense of pride. A team usually doesn’t support a single service, rather a group of services. When someone leaves a team they fill it with someone who fits within the team. Like family.

No one recommends, in the long term, just tossing people together on a willy-nilly basis to work on something. This isn’t to say that you never do this. In some environments, you may want to “mix it up” and get different people working together in an effort to find some synergy amongst people. I remember, back in the old days, that I developed applications better with some people than with others. I “clicked” with them and ideas were generated faster and better quality code was written faster. You want to find and foster those teams. For that reason, you may want to mix-and-match on a project by project basis until you find a combination that works well together.  And then you stick this that group.

The idea of a pool of resources that get blended together for different projects and you do this for everything? No, not a good idea at all.

Leave a Reply