Subject: how to organize programmers
From: Tom Lord <>
Date: Thu, 23 Aug 2001 15:56:54 -0700 (PDT)

When programmers become dots on an org chart, or items in a budget,
the people that manage org chats and budgets are treating them as
abstract tools.  It is easy, in that circumstance, to make mistakes:
for example, to abuse the programmers, or to organize programmers
in an inefficient way that gives rise to poor engineering.

On the other hand, organization and budget planning are vital tools.
You can't get by without them.

What's needed are strategies for organizing programmers that make
sense from several perspectives: the org chart/budget perspective;
the working-conditions perspective; and the engineering perspective --
at least.

Here's one strategy, predicated on the assumption that software
is naturally regarded as basis sets of building blocks (a strategic
concern) and products that fall within the "reliably constructable"
span of those basis sets (a tactical concern).

Software product development organizations should organize themselves
in terms of special teams: tactical teams, custodial teams, and
strategic teams.

			    Tactical Teams

Tactical teams are on the front line, producing finished products that
are delivered to software consumers.  Tactical teams have two long
zterm goals: flexibility and reliability.  These teams should be
flexible enough to rapidly develop any product for which a market need
is perceived.  They should be reliable enough to make accurate
delivery schedules and cost estimates for the products they develop.

Of course tactical teams may be specialized in particular application
domains, but within those domains they should be maximally flexible.
Flexibility and reliability of the team is achieved by providing
tactical teams with a solid basis set of foundational software and
giving them lots of practice applying that basis.

The idea of tactical teams is in sharp contrast to the mode of
organization we have often seen for front-line product developers: the
``product team''.  In many situations, teams are organized *around a
single product*.  The product is conceived, the team is assembled,
they build the product, and then the team stays with the product for
its entire lifetime.

The conventional approach has serious problems.  Teams invest heavily
to learn to work together, adding significant cost to each product
developed.  Team members have to learn to use the team's particular
basis-set software on the job, adding more cost.  As products mature,
attrition and turnover scatters the original team members and the
prices paid for team-building and basis-learning are thrown away.

A tactical team, on the other hand, acquires the generically applicable
skills of working together and wielding the team's basis to the best
effect.  If the team is continuously applied to a series of fresh
projects, attrition and turnover are likely to be less of a problem.

What then, of product lifetime?  If a tactical team builds a product
and then moves on, what happens to that product?

			   Custodial Teams

Custodial teams are assembled to assume stewardship of one or several
products.  The long term goal of custodial teams is to improve the
robustness, portability, and feature set of the products they own
in a regular series of incremental upgrades.  In the course of their
stewardship, they are well positioned to provide feedback to tactical
teams regarding the quality of their work and feedback to business
planners regarding the projected longevity of each product.

Custodial teams should practice the skills needed to ensure upgrades
of monotonically increasing quality such as: development of regression
tests; software performance measurement; acquiring and applying
end-user feedback.

			   Strategic Teams

The role of "strategic teams" is to provide basis-sets of software to
the tactical teams.  Their long term goal is to provide robust bases
that ensure the tactical teams the largest possible span (the widest
range of easily implementable products).  Strategic teams have both
intra- and extra-organizational components.

Like custodial teams, intra-organizational strategic teams should be
oriented towards making monotonic improvements to the development
tools for which they are stewards.  Monitoring robustness and
performance and adding features is their primary day to day task.

The intra-organizational strategic teams should work closely with
tactical teams, perhaps with overlap in personnel, in order to ensure
that the bases are fully exploited and that improvements to the bases
are properly focused.  Tactical teams will make provisional
improvements to their basis during product development and it is the
strategic team's role to polish those improvements into permanent

Intra-organizational strategic teams should also work closely with
extra-organizational strategic teams.  The role of
extra-organizational teams is to perform software research and
development -- both fundamental and practical.  They perform research
externally in order to provide cost savings to their several
investors, in order to achieve aesthetic independence, and in order to
develop a broad perspective.

It is the role of intra-organizational strategic teams to select
research projects in which to invest and to be the primary point of
technical contact with those projects.  When research projects deliver
positive results, intra-organizational strategic teams have the role
of brining those results in-house.  In some instances, it may be the
role of of intra-organizational strategic teams to contribute to