At 08:33 AM 6/6/02, you wrote: >Ronn said: > > > > How about the ability to change policies mandated by government or > > other external entities? > >I don't think this is within the scope of the changes that I'd allow. > > > Define "more productive". Frex, must it be something quantifiable that > > must show up on the bottom line, or can it be something intangible > > that will not necessarily bring in any more money or cut expenses? > > > What about when "happier" and "more productive" are in direct conflict > > with each other? > >I'm making the assumption that I'm dealing with "knowledge workers" or >other creative types who are notoriously hard to motivate by putting >them under more pressure. In that case, it seems reasonable to me that >all else being equal they will be more productive when they find >satisfaction and happiness in their work, and will be less productive >when they find work annoying or tedious. > > > I asked some of these questions to see just how far you wanted the > > speculation to go. > >It might be interesting to talk about the development of new >technologies that will improve productivity too, as long as those >technologies are things that could be brought to market quite soon. > >Rich, who must admit that he is thinking about starting a software >company and is looking for good ideas to help him in his quest to make >it a good place to work and an economic success.
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. 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. 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.) 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.) 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. Make sure the snack machine and the microwave work, and there's plenty of popcorn for the latter. 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. Is that helpful? (PS. Let your tech writers look at anything the programmers write before you give it to marketing, otherwise you, too, will send out fancy four-color sales brochures full of technical neologisms like "pneumonics", which is the same way that particular programmer always spelled "mnemonics" in the comment sections of his code, so everyone knew where it came from . . .) (PPS. When I once taught a class on the theory and principles of operating systems, some of the students asked why I wasn't still working as a programmer and making big bucks rather than teaching. Perhaps you know my answer now . . . ) Now I must run to do a job I really like . . . -- Ronn! :) Ronn Blankenship Instructor of Astronomy/Planetary Science University of Montevallo Montevallo, AL Disclaimer: Unless specifically stated otherwise, any opinions contained herein are the personal opinions of the author and do not represent the official position of the University of Montevallo.
