Ronn Blankenship wrote:
> Okay, with that additional information, I recommend that you get hold of
> the book "The Mythical Man-Month" by Frederick Brooks and learn from
> it. He makes reference to the organization that the protagonist in
> Heinlein's "The Man Who Sold the Moon" sets up to build the first Moon
> rocket, so you might want to go back and reread that, paying particular
> attention to the way he sets up the organization.
It's fairly readable, and even if you *don't* have to read it for
whatever reason, you might enjoy it. (Either that, or I'm really
weird.)
> Other than that, I'd say, based on my experience in the software industry,
> let your programmers and other creative and technical types spend their
> time programming or doing whatever it is they do, not attending meetings
> and filling out paperwork. IOW, hire someone who likes that kind of thing
> to deal with all the government, etc., Mickey Mouse, which is what I was
> referring to with my question about changing policies imposed by external
> entities. And for goodnesss' sake, don't call that paper-pusher a
> "manager" or make him the "boss" of the programmers: instead, he is there
> to help them and free them up to do what they do best.
Call that person an admistrative assistant to the programmers; put the
admin under the same boss as the rest of the group. And get someone
sharp. If anyone were thinking of such a startup in Austin, I could
make a recommendation. (A former co-worker, good at dealing with techie
guys.)
> And, no matter what
> you do, don't "promote" your best systems programmer to "management" where
> he will be busy twelve hours a day doing that kind of crap and either never
> get to write code again or stay late every night trying to write a little
> code in addition to all the Bravo Sierra until his health and marriage go
> down the toilet. (In case you are wondering, yes, I am thinking of
> specific cases I have seen in real companies.)
However, encourage some of the better programmers who have leadership
skills to take care of the coordination of *projects*. Encourage those
who are not ready to take charge of whole projects to do things to
improve those skills they'd need for it.
> Keep your programmers in a
> back room away from public view so they can wear t-shirts and sandals and
> listen to heavy metal music while programming, and let them come in at noon
> and work until 3 am if they want to. (The day you install a time clock or
> implement security key cards with chips that tell you where every employee
> is every minute of the day you might as well kiss your truly creative
> people goodbye.)
If telecommuting is an option for some, and it works for those people,
encourage it at times. Some people don't do well with telecommuting
(the wrong sorts of distractions at home) but others do very well on it
(avoiding the wrong sorts of distractions at the office). If it works
for someone, see what you can do with it.
> No matter how big your company gets, don't put anything
> in the way of your programmers and similar types talking to each other
> whenever they need information, such as making a person in one division who
> needs information that a person in another division has submit his
> questions in writing to his boss, who will give them to his boss, who will
> give them to the vice-president, who will give them to the head of another
> division, who will give them to one of his assistants, who will finally
> give them to the person who knows the answer . . . who must then submit his
> answer in writing for it to follow that entire chain in reverse order, as
> was the procedure at Sperry Univac when I did some consulting for
> them.
Also, watch out for managers that put themselves in the way of their
programmers talking to anyone outside the group without going through
that manager. In all likelihood, that group will not do well when
compared to the other programming groups.
> Make sure the snack machine and the microwave work, and there's
> plenty of popcorn for the latter.
Find out before you lease office space if there's a prohibition against
microwaving popcorn.
Also, keeping the fridge stocked at company expense with caffeinated
sodas may be a good idea. (Having bottled water for non-programmers is
a nice thing, as well.)
> Don't tell your programmers and other
> creative techies how to do their jobs, but listen and help them when they
> tell you what they need in order to do their jobs. Then get out of their
> way and let them write code. And when they go home, don't bother them for
> anything short of the Second Coming. Most programmers and similar types do
> their best creative work, such as coming up with solutions to seemingly
> intractable problems, while standing in the shower or just before falling
> asleep, not while sitting in the office.
If you have telecommuting programmers, have them set hours which are
good for them to be contacted by folks at the office, and try to
minimize any possible interruptions at other times.
All my comments are based on personal experience of people I know well.
(I'm not kidding about the microwaving popcorn prohibition in one
building. I just wish I could remember which one, now.)
Julia
