2 August 2004
For as long as I've been in software there's been a debate between FunctionalStaffOrganization and TechnicalStaffOrganization. The debate occurs within project teams, and across whole IT organizations. It's a constant debate because both sides have good logical arguments to support them, and there's no real way to test which has an advantage in practice.
Despite the fact that I acknowledge this, I greatly prefer a functional organization. I say this knowing there are exceptions and you can't follow one route all the time. But I'd rather side with too much functional orientation than the other way around.
For me the compelling factor is that of the aligning of application teams to business value. I very much believe in the irresistibility of Conway's Law and see the setting of an ApplicationBoundary to be primarily a social construct. Since the whole point of software development is to serve its customers, then the organization should reflect this - yielding teams that are focused on providing business value rather than delving deep into technical esoterica.
Fundamentally the argument of TechnicalStaffOrganization rests on efficiency - that it's wasteful to duplicate systems and that people are more efficient if they specialize. I won't deny that you get duplication if you use a functional organization, but I'm not so convinced it's so wasteful. After all many people believed a centralized, planned economy was bound to be more efficient than the wasteful duplication of capitalist competition. I'm wary of stretching too much of a parallel between macro-economics and software development, but I suspect the same issue underlies each of them - human motivation. When people are focused away from solving business problems, all sorts of factors creep in that introduce inefficiencies far greater than the duplication that a technical organization is designed to solve.
I also think there's an inevitability here. Business units need applications, if they don't get them they will build their own, creating a functional organization by default. After all they have the money and power - essentially the same dynamics as drive the boom-bust cycle of EnterpriseArchitecture.
So I think that most of the time you should organize functionally. But that doesn't mean that you should be blind to the problems of the approach. Duplicate work and lack of technical specialization will be serious problems, and you'll need to do things to counter those problems. They're just better problems to have than the alternative.