Retreaded: PreferFunctionalStaffOrganization

Retread of post orginally made on 02 Aug 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.

reposted on 04 Aug 2014