Best Way to Manage Geeks?

drummerboy195 writes to tell us that he recently read a 1999 interview with Eric Schmidt, then CEO of Novell, and wondered how applicable the information was today. How much have things changed since the dot com bust in terms of management? What other good and bad techniques have Slashdotters seen evolve from both supervisory and supervised positions?

Comments

IT Managment as Beekeeping

[daveb]

I like this article by Orson Scott Card titled "Why software companies die". It's really short (and really old - 1995) - go read it.

Geek management tips from the trenches

[ciurana]

Greetings,

I manage a small but important team. The guys who report to me are, by the definition of their jobs, highly technical. Whenever something complicated needs to be researched and/or implemented, my guys get to do it, especially if it has to do with the adoption of new technologies.

We had our quarterly review a few weeks ago (it goes both ways; they evaluate me, I evaluate them) and the results were excellent. Here are the overall management techniques I employed with them:

1. Hold everyone in the team, including myself, to the highest
standard.

2. Define what 'highest standard' means as a part of the requirements
specification.

3. Once a decision has been made, by the team, business owners, etc.
there is no arguing. Part of my job is to keep the business guys
from becoming a distraction. The other part is to ensure that
the engineers deliver (1) and (2).

4. Go through a quarterly review with them; divide a sheet of paper
in three columns labeled as follows:

a) Desired outcomes (projects, training, coaching of others, etc.)
b) Achievements
c) Areas that need improvement

At the beginning of the quarter first quarter ever that you
implement this, fill-in only items in the first column. At the
end of the quarter, fill in the other two columns. A person is
doing great if they had, say, four desired outcomes and wind up
with four or more achievements. Last, review things that need
improvement (mine is "needs to attend relevant meetings" for this
quarter). Discuss those AND FOCUS ON BEHAVIOUR, not on
personality. Explain why the improvement is needed. After you
negotiate what this means, add it both as a thing to improve and
as a desired outcome for the next quarter. Repeat every quarter.

5. Respect your engineers' decisions. Combined, they know more than
you do, regardless of how technically capable you are. If that's
not the case, you shouldn't be a manager and you're probably not
meeting 1-3.

6. Leave your engineers alone to do what they do best. Don't invite
them to too many meetings or have them do tasks unrelated to their
charter. Engineers hate distractions, and distractions prevent
the team from achieving 1.

7. If the business folks start coming up with eleventh hour changes,
ensure that the engineers are part of the discussion and reason
WITH BOTH SIDES to figure out which changes make sense and why, which
don't, and how to come up with a solution that will meet everyone's
goals. NEVER just inform the engineers that a decision that affects
what they've been working on for three months has been made.

8. As a part of 4, create an environment where you are constantly training
your team, exposing them to new technologies, etc. Reward the intro-
duction of new techniques, procedures, etc. In 4, suggest that they
read at least a new book ON SOMETHING NEW NOT USED AT WORK every quarter.
If you work in a Java shop, they should be reading about Ruby or .Net.
You never know when a better mousetrap is available if you aren't informed.

9. Reward excellence whenever you see it, from solving the thorniest algorith-
mic q