At 06:02 PM 6/6/02, Julia wrote: >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.)
Are those two options of necessity mutually exclusive? ;-) > > 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 Except that these days "administrative assistant" is a PC term for a "secretary" (like "sanitation engineer" for "garbage man"), so that particular title may make him sound less important than he really is when dealing with people outside the company. (This is not to say that secretaries are not important. Who do you think really runs the department at the university? It's just that some people insist on dealing with someone with a big office and a fancy title. If you are not careful, though, give a person a big office and a fancy title and some responsibility and he will begin to think he is more important than the people who actually produce product, which is what seems to happen in such businesses.) >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. Here is something on which Julia and I may differ. All along the way I have met programmers, engineers, tech writers, etc., who are very happy being programmers, engineers, tech writers, etc., and who absolutely do not want the additional stress and busywork involved in managing other programmers, engineers, tech writers, etc., regardless of the fact that they have more experience, more talent, and the necessary leadership skills. I met some like that in the Air Force, where the "up or out" policy states that you have to be promoted to the next higher rank within a certain number of years or get out of the service, and the only available positions for someone with their experience where they could have achieved the next higher rank were positions that involved no longer _doing_ the engineering they loved, but _managing_ other engineers who were doing the engineering they loved, so they got out. Is it necessary to try to force a person who is happy doing exactly what he is doing into a position he doesn't want? As I mentioned in my previous message (quoted above), at one computer company I worked at for a couple of years, they took the top systems programmer, who was talented and happy writing assembly-level code, and made him "head programmer" which meant he now spent the entire workday being a manager and stayed late into the night trying to keep his hand in as a programmer. He would have been far happier, and probably far more productive and useful to the company, had he remained a programmer and someone else been made manager. Though in thinking about it, I think the same thing would have been true of any of the other senior programmers they had at the time (including the one who could not spell "mnemonic" but wrote the text editor program from scratch), so maybe this particular person was forced to take the head of programming job because *someone* had to do it. (I know this was the situation in other departments in that company, where no one, particularly the members of the department with the most seniority, wanted the hassle of being "manager" of the department, so it finally fell on someone who said "Oh, well. If you insist," but wasn't too happy about it.) This is very much the situation described in the Heinlein book, and why the Brooks book refers to it. In fact, it was at about this time that I first came across "The Mythical Man-Month," which may help explain why it made such an impression on me. That was also about the same time I came up with a modification of an old saying that in my experience is far more true than the original: "Those who can, do. Those who can't do, become managers." > > 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. Yes, yes yes. > > 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. At Sperry, it was the *top-level* management who insisted that all communications go all the way up to and through their office, then back down to the person with the answer, even if the person with the question and the person with the answer were located within a five-minute walk from each other. I don't know how they did as much as they did with that system in place. I was going to speculate that maybe such a structure was a holdover from the days when they were primarily a defense contractor, but even in the real military (no wisecracks about the Air Force not being the real military, please), I never had to deal with that kind of rigid structure. >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. Yes, there are some places that prohibit it. The only reason I have heard is because the smell goes all through the building and makes everyone else hungry, even those without access to the microwave (perhaps another tenant of the same building.) Of course, you were going to build your own custom building with all the ideas we came up with, weren't you? ;-) >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.) Not *all* programmers subsist on Jolt. Some do function on bottled water, or Sprite, or fruit juice, or those fruit juice/carbonated water beverages, etc. Just be sure to find out what they want and give them what they want. If some want Coke and some prefer Pepsi, find some way to make both available. To those with a preference, one is *not* a suitable substitute for the other. > > 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. As much as possible, handle stuff like that via e-mail, and don't pick up the phone to call them if they don't answer your e-mail in five minutes. And don't give them the impression that you are calling or even e-mailing just to see if they really are working. As long as they are turning out useable code, it doesn't matter when or how they are doing it. Even if they have figured out a way to put the computer in the bathroom and write code while in the shower without electrocuting themselves . . . >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.) Remember, you hire programmers because they have a special talent, not because they are corporate drones. Like thoroughbred race horses, a pampered programmer is a happy programmer, and a happy programmer is a productive programmer. ;-) -- Ronn! :) In the beginning was the WORD. And the WORD was misspelled. So the WORLD never compiled.
