|
Philip Greenspun founded ArsDigita Corporation and was its CEO from
inception until it reached $20 million/year in revenue. Currently, he
is Chairman of ArsDigita and teaches computer science at the
Massachusetts Institute of Technology.
|
Why an article on managing people? And one written by someone with
training in computer science rather than business administration?
There are thousands of books on the best ways to manage people. Many
of these books are excellent, having been written by people who've
devoted their lives to the discipline.
Software engineering is different.
Software engineering is different because only the best people
significantly contribute to achievement. Traditional management texts
assume a distribution of talent among the workers. Each worker is
contributing something useful and the challenge is to get each one to
perform at his or her maximum potential. In the same factory, the
best worker may produce two or three times as much as the average, but
all the workers are contributing. In software engineering a good
programmer is at least 10 times more productive than an average
programmer (Brooks 1995). If a product is being developed rapidly, the average
programmers will consume nearly their entire work day just in reading
and understanding the new code generated by the good programmers.
Thus the challenges of a software engineering manager first and
foremost are (1) creating a work environment where good programmers
will be satisfied enough to stay, and (2) creating a system via which
average programmers can become good. In an ideal software engineering
organization, there are still some average-quality people but these
should be viewed as being apprenticed to the best people and being
taught as fast as possible.
Software engineering is different because people at all levels of the
organization perceive themselves to be equally intelligent.
Consensus-style management can perhaps work when there is a gradient
of perceived ability. Given enough time, the less able workers will
follow the lead of the more able workers. One of the paradoxes of
software engineering is that people with bad ideas and low
productivity often think of themselves as supremely capable. They are
the last people whom one can expect to fall in line with a good
strategy developed by someone else. As for the good programmers who
are in fact supremely capable, there is no reason to expect consensus
to form among them. Each programmer thinks his or her idea about what
to build and how to build it is the best. (See Kruger and Dunning's
"Unskilled
and Unaware of It: How Difficulties in Recognizing One's Own
Incompetence Lead to Inflated Self-Assessments" for more on this
topic.)
Software engineering is different because a leaf-node worker is more
expert than any manager, even when the manager is a great engineer, in
at least the small portion of the system that the leaf-node worker has
personally built. This makes it difficult for a manager to engage in
a technical argument with a worker. It becomes nearly impossible when
the manager's technical skills are weak. The worker can spin castles
of complexity in the air and come up with impressive-to-the-MBA
excuses for why it has to be done a certain way or on a certain
schedule.
Software engineering is different because the organization can't
afford to lose the individual productivity of the best people by
pushing them into management. A truly great programmer may generate
10 times as much business value as a merely good programmer. Can the
organization afford to take someone who can do the work of 100 average
programmers and push him or her into a pure management role? Probably
not. Can the organization afford to put people with weak technical
skills into management roles? Probably not. Once you give Joe MBA a
title and ask him to coordinate eventually he will be making decisions
that have engineering implications. Thus many of the best programmers
are eventually forced at least to assume project leadership and
mentoring responsibilites. Since they are still expected to produce
designs, software, documentation, and journal articles, the danger is
that the new manager will become glued to his or her screen and never
look up to see how the project team is doing.
Software engineering is different because measurement is notoriously
difficult. The world is full of products that failed due to overly
complex and tasteless designs. Yet all of these designs were
considered tasteful by their architects. Systems that experts
evaluated and found wanting, such as the Unix operating system (1970),
eventually proved to have great utility. It is a bit easier to count
up the lines of code per day produced by a programmer but if the
project was not very tightly specified originally, how do you know
whether or not these lines of code are useful?
At this point a skeptical reader might be thinking that, while
software engineering is different from line production work or any
other endeavor with a manufacturing division of labor, there are
similarities with research and development, management consulting, and
financial analysis. This is certainly true but there aren't too many
interesting books on how to reliably produce results in these fields
(one is referenced in the "More" section below).