Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!ico!vail!rcd
From: rcd@ico.ISC.COM (Dick Dunn)
Newsgroups: comp.software-eng
Subject: Re: Information Systems is an Engineering Discipline
Summary: middle ground between "promoted engineer" and "nontechnical manager"
Message-ID: <16110@vail.ICO.ISC.COM>
Date: 19 Sep 89 22:49:43 GMT
References: <6429@hubcap.clemson.edu> <10835@riks.csl.sony.co.jp> <6198@ficc.uu.net>
Organization: Interactive Systems Corp, Boulder, CO
Lines: 43

In article <6198@ficc.uu.net>, karl@ficc.uu.net (Karl Lehenbauer) writes:
> > |>       Put senior, nontechnical management in charge of the project...
> > |>... Rubbish!  Managing a large information system development project is
> > |>    a professional skill requiring significant technical and engineering
> > |>    background...
>...When a manager in charge of twelve programmers gets too technical, they
> become the thirteenth programmer in the group, rather than the manager...
. . .
> Inability or unwillingness to delegate responsibility is a common criticism
> of many new managers, usually levied at those fresh from a direct technical 
> job...

Karl's right--and there are practices which encourage this to happen.  The
worst is "promoting" people from engineering to management.  In some com-
panies, if you rise high enough you MUST become a manager--you run out of
room for technical advancement after a while.  The result is then that your
best technical people get turned into managers whether they like it or not.
It may be overt--"If you want to advance your career, it's time to take on
some management responsibilities"--or relatively subtle.

The saying some of us use for this is "It's always possible to turn a good
engineer into a bad manager."  Promote someone who likes engineering but
not managing into a management position; the person will find a way to
neglect the management and dabble in the engineering.

(More enlightened companies have a nearly-complete "dual ladder" structure
for advancement, where you can stay technical if you want.)

>...Once they "correctly" start delegating stuff, they lose direct contact 
> with the technical end, and in a few years, their technical knowledge is out 
> of date, unless they are very, very committed to maintaining it...

This is mostly OK; they'll retain some of the important understanding of
what sorts of tasks are inherently easy or hard.  You won't have to explain
why finding a timing-related bug (critical-section failure, deadlock, etc.)
with new hardware and new software might take anywhere from an hour to a
week.  That's (one example of) the sort of knowledge that a former technical
person will retain through a lot of management.  It's very hard to teach a
completely non-technical manager (i.e., a never-technical manager) this
sort of thing.
-- 
Dick Dunn     rcd@ico.isc.com    uucp: {ncar,nbires}!ico!rcd     (303)449-2870
   ...I'm not cynical - just experienced.