There are three main theories that I occasionally hear people expound for how to organize developers: 1) organize resources around technology layers, 2) organize resources around business areas, and 3) let everyone do everything. There are a number of fancy names for these approaches but they all escape me now. Actually my mind almost never remembers the names for things; it seems to just hook notions into my brain somewhere and then later when I need to discuss them with people or blog about them I usually have to look them up on the web, but I digress.

The first theory assumes that the complex thing is learning the technology skills and so you need only know about how the UI works or how the database works or how the middle-tier works, etc. You may still need to understand the whole of the business problem, but by having resources dedicated to a technology ring the feeling is that people can be more efficient. It is usually proposed by good business people or bad technologists.

The second approach is the same as the first but with a ninety degree change in orientation. It presumes the complexity lies in the business domain and so resources are aligned along business problem boundaries. For example, some people will be experts on the calendaring components (but be able to work on databases, UIs, APIs, etc.) while others will be experts on the todo list and others on the analytics. It is usually proposed by good technologists or bad business people.

Sometimes these models are combined.  The end result being an extremely high degree of specialization so that resource number 57 (with the arbitrary designation of Hank) works only on UI elements of the calendar component. This hybrid approach is universally proposed by people who work on very large projects and are successful MBA graduates. It is the manufacturing specialization model and can be taken to any arbitrary degree of specificity given enough resources. I remember a friend of mine who was working on a project for the fly-by-wire systems for the Joint Strike Fighter. I asked him what he was working on and he said he just worked on a set of language elements for the simulation language. He had been given the maintenance responsibility for the commands numbered 31-60. Apparently they were considering moving each resource to manage only 29 commands instead of 30 in which case they would move him to manage commands numbered 30-58. I'm pretty sure he was joking but he never cracked a smile.

The last model is that projects should be organized to be simple enough that the resources assigned to them become completely interchangeable. In this model the code is so well factored that anyone can read it and the business problems are so well thought out that anyone can understand them. This model is frequently proposed by really-really smart people, by somewhat less smart people who have never worked on large projects, by escaped sixties radicals and by my Uncle Sid in Chattanooga who just bought a Commodore 64 off EBay so that he could "do some larnin bout them thar computer things."

I actually have a fourth theory. My theory is that software isn't written by resources it's written by people, and people are a lot more different than these theories would have you believe. My theory is that you figure out what people are good at, what they WANT to be good at, and what they CAN be good at, blend it all together along with three tablespoons of information about people's personal lives, a massive grain of salt about the future project requirements, as much tortured brain extract as you can squeeze out of your ears, and a dose of informed opinion from your best friend down the street. This mixture should be beaten thoroughly every three to four days until a smooth and even consistency is achieved at which time more people can be added to the mix. Oh, wait; somehow I've confused my instructions for team management with a recipe for fudge brownies. Anyway, the point is that while these theories may make nice diagrams that impress your boss they should never be confused with reality.

Here are some examples of the KINDS of things that you might find yourself doing when working with people instead of resources:

It turns out that when Marty is given a new piece of code to write he bogs down and it takes forever, but he can refactor code like there is no tomorrow so you have Susan (who can blast out a working prototype faster than a Volkswagen Beetle with a five-hundred-horsepower engine but can never bring a project to actual closure) whip out a roughly working prototype and then ask Marty to turn it into a well polished gem.

You might ask people what they want to work on. Then when no one in the company is willing to sign up for the Wandering Whistle widget you can take that as a bad sign for that widget and spend a little bit of work determining that if you give Methuselah an extra week for refactoring he would be willing to bring the widget back from the depths of hell where it seems to have found itself.

Sasha is the expert on the build tool but she's getting sick of spending time working on it and can't come up with a good way to hand it off (maybe it's too complicated), so you have Frederick (who seems to have a knack for making things easy to use) work with her to change it so that it no longer needs an expert to work on it.

Anyway, these are the kinds of things that you do when you have people on your projects instead of resources. Of course, you actually do need to divide up tasks and build separate teams and all of these things, but when you do it's best if you leave your engineering hat at the door and put on your people-first button and attend the party as a friend of those that work for you rather than someone who views people as cogs in the wheel.