Forgot your password?
typodupeerror
The Almighty Buck Books Media Book Reviews

Managing Einsteins 345

Posted by timothy
from the keep-the-brain-jars-upright dept.
In many workplaces, especially high-tech ones, managers and those they manage are operating on parallel tracks, with different sets of motivations, expectations and rewards. How to keep tech workers happy, given that they likely don't want the same things as their bosses, and certainly would choose different ways to achieve them? The long-suffering Jim Richards submitted this review of Managing Einsteins, a book which attempts to inject some sanity into the situation by clueing managers in on what it is their programmers and other tech workers might actually want in a workplace. Read on for his review.
Managing Einsteins: Leading High-Tech Workers in the Digital Age
author Dr. John M. Ivancevich and Dr. Thomas N. Duening
pages 249
publisher McGraw-Hill
rating 7
reviewer grumpy
ISBN 0-07-137500-7
summary Good information for managers of IT workers

This book doesn't use terms like "nerd" or "geek" to describe IT workers: the authors hold that the stereotype of pocket protectors and coke-bottle glasses just doesn't fit any more. This is a book written for managers, and so the terminology and style (almost) always refers to Einsteins as "your workers," to the point that with the summary at the end states:

Referring to super-intelligent, curious, passionate, often introverted, talented individuals as "geeks" is outdated. Although Einsteins can call colleagues "geeks," it is not appropriate or cool for non-Einsteins to refer to computer, technology, systems or software geniuses as geeks. (page 217)

These are the difficult to work with, yet life-saving employees who can come up with answers when most people don't understand the question.

Several themes run through the book, so it can be summarised in a few simple statements. Many of which (to Einsteins) may seem pretty obvious. The book is written by "Management Professionals," though, so there's hope that managers may actually accept some of its wisdom.

The book is divided into three parts:

  1. Realities of the Twenty-First Century - a brief summary covers the basic themes of the book and introduces the concept of an Einstein, the nature of Einsteins and how they fit into the work environment and the world.

  2. Managing Einsteins: Challenges and Actions - this section, the bulk of the book, covers everything from recruiting Einsteins through to managing them on a daily basis, by paying attention to communication, teams and tribes, remuneration, etiquette and discipline.

  3. Building for the Future - includes humour and fun at work, telecommuting and a final summary.

The book describes IT workers as highly motivated, intelligent (often more intelligent than their managers), introverted, tribal and independent.

The mains themes throughout the book are:

  • Managers should be honest with their workers about the company's successes and failures
  • The point of management is to guide and suggest not to be autocratic (the metaphor of herding cats was used to illustrate this)
  • Let the Einsteins have freedom in work environment (location - there is a whole chapter on telecommuting, hours and style)
  • Einsteins are project-focused, not job-focused
  • They value training and education highly
  • They require a stimulating and fun work place.

The issue of remuneration is covered -- and expanded to include the idea that Einsteins are not solely motivated by money (as sales people may be), and that other considerations should be taken into account (such as training, location, work conditions). Also that the traditional notion of promotion does not always work. An Einstein may not want to become a team leader, or move any higher in the management hierarchy. A manager should be wary of their Einsteins burning out, a temporary demotion or other measure may be in order to take the stress off an Einstein for a while.

The book includes short examples and case studies from various workplaces, and excerpts from newspapers and trade journals to help illustrate points. There are also highlighted points categorised as "Influence Tips," "Black Holes" and "Einstein Wisdom." which emphasise important things, such as:

Managers should be very cautious not to introduce projects that have a low likelihood of getting started. Einsteins abhor routine and crave novel projects. But they abhor being misled and crave honest leadership all the more. In staff meetings, when managers talk about upcoming projects, they should attach a probability of launch along with the projected launch date. The common term for this is "managing expectations." (page 70)

One good description of the nature of how Einsteins work is the concept of flow.

Flow is reported by individuals as a satisfying state they reach when they are completely absorbed in challenging yet achievable projects. (page 54)

Flow is an important concept for managers to understand. Once an Einstein starts a project, and becomes fully involved, there is nothing worse than being pulled off to attend a sales meeting, or other time consuming function. It interrupts the flow.

One pitfall: the book seems to have been started before the tech slump of 2000-2001 really started to dig in. So the book wavers between promoting how IT workers are highly mobile, but also that the job market is not that strong.

The other major shortcoming is the chapter on Etiquette and Manners. Now, I can understand the mannerisms and habits of Einsteins can be a little unpleasant at times, but it begs the question, why would a manager take one of these people out to a client dinner in the first place? If the client needs to meet the tech people to be convinced that a company can do the job, why not at the place of work? Or, take an Einstein who you know you can trust to behave and present well.

As this is the only book at the moment that deals directly with managing this class of workers, also get your manager to read Jon Katz's Geeks. Managing people is no longer about direct, micro-management or process line working. The nature of work has changed with the influence of new technology and so a new way of managing people should also be introduced. These books together will help management, or anyone, understand the mind set and working modes of IT workers.


You can purchase Managing Einsteins from bn.com. Want to see your own review here? Just read the book review guidelines, then use Slashdot's handy submission form.
This discussion has been archived. No new comments can be posted.

Managing Einsteins

Comments Filter:
  • Ummm... (Score:4, Funny)

    by nomadic (141991) <nomadicworld@NOSpam.gmail.com> on Thursday April 04, 2002 @11:18AM (#3284591) Homepage
    Alright, I know tech workers tend to have absurdly high opinions of themselves, especially on slashdot, but EINSTEINS? That's going a bit far, don't you think?
    • Re:Ummm... (Score:5, Funny)

      by Anonymous Coward on Thursday April 04, 2002 @11:21AM (#3284607)
      No, the book is specifically about managing Einsteins. The decendants of the great physicist have spread throughout the world and are working in most major corporations. Unfortunately, they are notoriously difficult to manage, and this book aims to rectify that.

      Or something.
    • Re:Ummm... (Score:4, Funny)

      by Noctivago (216743) on Thursday April 04, 2002 @11:22AM (#3284625)
      No kidding, i work with techs all day long and there are no einsteins that i can see. When a sysadmin is asking you what "ping" means, then i'm afraid the boundaries of astrophysics are not even within sight.
      • Re:Ummm... (Score:4, Funny)

        by Tackhead (54550) on Thursday April 04, 2002 @01:14PM (#3285466)
        > No kidding, i work with techs all day long and there are no einsteins that i can see. When a sysadmin is asking you what "ping" means, then i'm afraid the boundaries of astrophysics are not even within sight.

        In keeping with the Einstein / astrophysics thread, "your admin is so far beyond clueless that he couldn't find clueless with very-long-baseline interferometry" :)

        • In keeping with the Einstein / astrophysics thread, "your admin is so far beyond clueless that he couldn't find clueless with very-long-baseline interferometry"

          Optical or radio interferometry? Make a difference... ;)

          Al.
    • Re:Ummm... (Score:5, Funny)

      by Reality Master 101 (179095) <RealityMaster101@noSpAM.gmail.com> on Thursday April 04, 2002 @11:32AM (#3284695) Homepage Journal

      I think he means that techs are Einsteins "relative" to the management.

      (sorry)

    • It's relative (Score:3, Insightful)

      by Da VinMan (7669)
      When you consider the book's intended audience (managers), then you might appear to be an "Einstein". In fact, it's a sign of "Einstein-ity" if you know just how much of a *real* Einstein that you are not.

      In reality, your manager may be just as smart as you, or even smarter. But because of the technical nature of our work, we often get the "witch doctor" mystique to go with the job. That's useful, because it can give us the leeway we need to get the job done.

      Don't abuse it.

    • I think I'll write something like this in my resume:

      Some people may tell you that I'm insane or that I lost contact with reality long time ago and I have problems with human-human relationships since I was a kid, but don't believe them, that's not true. By the way,
      please read the book "Managing Einsteins" before contacting me, thank you.

      Everyone will want to hire me.

  • by Anonymous Coward on Thursday April 04, 2002 @11:20AM (#3284605)
    I'm waiting for the sequel:
    "Managing Programmers who Think They're Einsteins
    (but who are really idiots)"
    • I could use this (Score:2, Interesting)

      by Anonymous Coward
      I could use this. I'm in charge of the tech group at work. Given, this is a small company and the tech group just consisted of me up until 4 months ago. Now I've got 3 people under me. I'm always inclusive and I always talk about "us", "we", etc... One day I said something like "Yes, the owner should be able to call on any one of us to perform a given task and we should all be able to do it with no problems." And this one guy pipes up "Yeah, tell me about it. John doesn't seem to trust me, but he has to understand that I'm just as good as you." To understand the irony here, you must understand that he said this despite the fact that every time there is an issue that requires a little bit of critical thinking skills or that is not already spelled out in easy-to-understand steps he comes to me, out of breath and panicking, asking "what do I do now? How does this work? I don't know what to do. Please tell me how to fix this." Even worse on top of that, he takes the credit afterwards. I've been trying to play nice, but I'm going to need to beat him with a cluestick real soon.

      So I guess this whole long story was to validate a need for your book.
    • Or better yet:

      "Managing Programmers for Dummies"
  • Makes sense (Score:2, Interesting)

    When dealing with highly intelligent employees, it's counter-productive to put them on a regimented schedule, in a cramped cube and expect them to turn out quality work.

    Though I'm not an "Einsein" in the typical sense used in the review, I find that a lot of the ideas presented can apply to people in my field of accounting. It's another highly specialized field requiring a certain type of worker, and a quirky lot at that.
  • by L-Wave (515413)
    But could you imagine managing a bunch of cloned einsteins?? This could be in interesting project, perhaps collectivly the beowolf cluster of einsteins could figure out many of the worlds perplexing questions =) anyways, thats my random thought for the day...
  • 4 Posts in one! (Score:5, Insightful)

    by dmorin (25609) <dmorin@[ ]il.com ['gma' in gap]> on Thursday April 04, 2002 @11:21AM (#3284619) Homepage Journal
    Moderate at will.
    1. Recruit Einsteins? How old is this book? Who the hell is recruiting anybody anymore? :)
    2. Exactly how much of a cocky bastard does it make me if I tell my boss we should get a copy of this book?
    3. Didn't seebs write something about managing hackers (and/or herding cats) that has much the same advice, has been around longer, and is more "truer to the cause" since it was written by one of us instead of a bunch of management professionals who claim to understand us?
    4. Is there a chapter about how we still want beanbag chairs and free soda?
    • Is there a chapter about how we still want beanbag chairs and free soda?

      I hope so, I won't work anywhere that doesn't have free soda.
      • Is there a chapter about how we still want beanbag chairs and free soda?
        I hope so, I won't work anywhere that doesn't have free soda.
        I started working at my current employer in part because they had free soda. A couple of months after I started, they stopped stocking the fridge.

        So now I make a trek (during work hours) to the local mega supermarket and stock my group's private mini-fridge with our choice of soda cans. Everybody who wants 'free soda' has to chip in five bucks once every few weeks.

        $5-$10 a month is cheaper than quitting and trying to find a new job.

        OTOH, it kind of pisses me off when management takes away perks without any sort of explanation or notice, and with little or no chance of ever getting them back when things get better.

        Little things have all been cut off over the past year or so. Things like free soda, the office plant rental service, annual raises...

    • Didn't seebs write something about managing hackers (and/or herding cats) that has much the same advice, has been around longer, and is more "truer to the cause" since it was written by one of us instead of a bunch of management professionals who claim to understand us?

      Managment types don't listen to geeks. If they did, we wouldn't need books like this in the first place.
    • Didn't seebs write something about managing hackers (and/or herding cats) that has much the same advice, has been around longer, and is more "truer to the cause" since it was written by one of us instead of a bunch of management professionals who claim to understand us?

      Perhaps the Seebs book is "truer to the cause" (I haven't read it, so I can't comment), but assuming that the majority of this new book is accurate (and the review makes it look pretty good), wouldn't you rather have a PHB read a book from a source they trust?

      A book written about a geek by a geek will be suspect in management's eyes... a book written about a geek by a management professional will have much greater credibility.

    • How old is this book? Who the hell is recruiting anybody anymore?


      Go on Craig's List or some other job board and place a bogus ad for Java or VB coders, or some other mid-range skill position.

      You will receive one hundred resumes within six hours.

    • Exactly how much of a cocky bastard does it make me if I tell my boss we should get a copy of this book?
      Seven. It makes you a cocky bastard to the amount of seven. (Note this is on the Williams-Kerner Normalized Cocky Bastard Scale (WKNCS) , not the Stanford Centered Cockiness Measure (SCCM))
      Is there a chapter about how we still want beanbag chairs and free soda?
      No, but there is a chapter about how we will want a chapter about still wanting beanbag chairs and free soda. And hammocks. I could really go for a hammock.

      --
      Damn the Emperor!
  • Important point (Score:5, Insightful)

    by jlower (174474) on Thursday April 04, 2002 @11:24AM (#3284635) Homepage
    The review touched on it but I think it's important to note that being smart doesn't make you a good manager. In my career I've seen great programmers promoted to management positions simply because they (the company) couldn't think of any other way to reward them for being good.

    In a department I used to work for, the best programmer is now riding herd on all the programmers. He's a great coder but not a great manager. But, the culture is that you have to keep getting promoted or there must be something wrong with you so up the ladder he went.

    Now, when he fails as a manager what happens? He can't really go back to being a coder - too much like a demotion.

    The root of the problem is the concept of a salary range for a given job. People can't get a raise because they are max'd out for their job. Want to make more? Leave the job you're good at and move to management. It ain't right but that's the way it is.
    • Re:Important point (Score:3, Informative)

      by psin psycle (118560)
      You've just described the Peter Principle [vub.ac.be]
      • Dogbert's corollary to the Peter Principle: most people in management were never competent at anything to begin with. That satisfies my cynical side, but in the real world, of course, you get a mixture of both -- as well as those more-precious-than-rubies managers who were really good at the grunt work and are good managers as well.
    • Need a raise? (Score:5, Insightful)

      by ccoakley (128878) on Thursday April 04, 2002 @12:12PM (#3284983) Homepage
      Want to bust the salary cap for being a programmer? Learn to write! If you can write proposals that get contracts, you can charge whatever the hell you want. Every place I've worked, management only thought with dollars. If you bring in more dollars and budget a higher salary for yourself, there's no reason to prevent you from making more. A side benefit is that you can often remove layers of management and bring in projects with less overhead costs. Think of it as running your own company from inside your company.

      Where I work, junior developers work with senior developers on a project. Both groups get their timesheets signed by and assignments from the tech lead, who is a programmer. The tech leads report directly to the president of the company. Project managers exist, but as a support function (and they earn their keep by shielding developers from the customer). Our R&D team spends about 8 hours a week writing proposals (on average). For a 50 person company, this seems to work.

      That said, I feel obligated to point out that we didn't build this hierarchy first. We had a director of development who was a micromanaging PHB. We had a CTO who did absolutely nothing. That was our analogy to the promoted programmer you had. First he was promoted to Director of Development, but he sucked. So they promoted him to CTO. Then he sucked. The DoD they replaced him with was terrible. Now the DoD is gone, and the CTO is a developer again (at the same CTO salary), but because he was out of the loop for too long, we have him writing VBA in MS Excel. Aside from the fact that a programmer who is effectively a junior developer is making more than the tech leads, we seem to have reached a nice equilibrium.
    • The root of the problem is the concept of a salary range for a given job. People can't get a raise because they are max'd out for their job.

      That's absurd. If the company thinks an employee is valuable doing what they're doing, and they want to keep them, then just give them a raise.

      First off, the idea of a set range for a given job role is arbitrary to begin with. But who's the "audience" here? By that I mean, who's watching their salary range, and who notices when it's been exceeded? Do they get their knickers in a twist when it happens? And why should it matter to them?

      Hell, if the company feels constrained by an arbitrary salary range, then why not just create a new position (Grand Digital Poo-Bah) with no established range. If it's the semantics that's standing in your way, then hack around them.

      Schwab

  • by DohDamit (549317)
    I was looking for something, anything, in the review that said this advisory text was specifically targetted at a super-intelligent audience. Not a bright audience, mind you. After all, Einstein wasn't merely bright(like me.) He was a genius for the ages. Of course, I was curious as to where all these super-geniuses were when the business plans were being drawn up, but ahh well, who am I to question them.

    There was nothing that was targetted specifically at said employee subset. Not a thing was said that wouldn't apply to every employee.

    On the plus side, this book doesn't even have to be read to be helpful. This book is a standard management text with the marketing built into the title of the book and nowhere else.
  • by knewman_1971 (549573) <kris.newman@NoSPam.khaosx.com> on Thursday April 04, 2002 @11:26AM (#3284658)
    1. Please don't micro-manage me - give me a goal, set my paramters, then get the hell out of my way. I promise that I'll amaze you in short order. 2. Don't lie to me about the state of the company. If we're in the crapper, let me know. I know you're scared that if you paint a less-than-rosy picture, I might just leave. But if you paint a rosy picture, and I find out that you're blowing sunshine up my ass, you can rest assured that I'm going to leave. 3. Remember the cardinal rule - if you hire adults, and treat them like adults, they'll probably behave like adults. (Of course, if you tell me that I can shoot Nerf guns at my cube-neighbor, don't be surprised when I do...) 4. Don't make me play any of those stupid touchy-feely games at meetings. I'm not at work to bond by force. If I need to get in touch with my deeper self, I'll do it on my own time. See rule 1. Course, that's just my opinion...yada yada.
    • I am curious to hear how others respond to meetings or 'parts of meetings' requesting you to imagine things such as: "a circle, with the line colored in your favorite color, but not red because red is too negative. Now, think of the moment of your life you felt best where you felt like you were number one! You felt confident and ready to challenge anything in the world. Now, insert that moment in the circle. The circle with your favorite color, other than red or, I forgot to mention, black, is in front of you. Go ahead and take a step forward into the circle. Go ahead! Now, how do you feel!?!"

      This is the type of shit I must confront in the work-place and entirely agree with parent: " I'm not at work to bond by force. If I need to get in touch with my deeper self, I'll do it on my own time." But, how do I respond to such requests, instead of taking a deep-breath and doing it, again? Any template responses to share?
      • I was in this situation once at a company I no longer work for. My response was "I have way more important things to do than bond with people I don't even work with. Want this product shipped this quarter?" Many other people followed suit after I broke the ice, and soon the "Rah-Rah" sessions were optional (and mostly empty).
      • > Now, insert that moment in the circle. The circle with your favorite color, other than red or, I forgot to mention, black, is in front of you. Go ahead and take a step forward into the circle. Go ahead! Now, how do you feel!?!"
        >
        >Any template responses to share?

        For your particular touchy-feely game, I came up with:

        "I still feel like a complete idiot, sitting around new-agey mindgames with you, when I could be having fun developing code that you could be selling for a profit!"

    • by awol (98751) on Thursday April 04, 2002 @12:12PM (#3284984) Journal
      A few years ago, I stole a question from a job interview (in which I was participating as an interviewer). I now ask it of every "technical" candidate I interview:

      "What do you want from your manager"

      The actual answer to this question is not all that important. What is important is that the answer is not a cliche (that what they want is something that the candidate _will_ be able to get from the person in my organisation who will manage them) and most of all, it must show that they have some idea of what a manager does that helps them.

      In other words, if someone cannot see something of value in the role of their manger then they will be difficult to manage, geek, einstein or asshole. The "value" that shows the most insight is the filtering of the mundane (or inconvenient)so that they can get on with the "work", whilst accurately reporting progress to cheque signers.

      $0.02
    • I had a tech lead who came from a military background. At first I though It would be a pain to work with this guy (coming from the military as he did), but he had some great insights about dealing with bureaucracy.

      On rather crude but insightful tidbit he had, went something like this.

      All upper management is looking for is a nice plush behind to stick it in. Its the job of your middle-manager or tech-lead to wave his/her butt around, intercept the phallus, and shield the techs so they can get their job done in comfort.
  • replace (Score:4, Funny)

    by zephc (225327) on Thursday April 04, 2002 @11:29AM (#3284670)
    s/Einstein/People obviously smarter and more talented that you/g

    Stick THAT in your MBA PHB pipe and smoke it, Mr.!

    Not that I'm bitter =]
  • by Johannes (33283)
    While I'm not sure I would qualify myself as an "Einstein", I would say that I'm a geek.

    While I can agree with some of the themes, I generally view training and education as worthless most times. I'd much rather have a piece of software dropped in front of me and give me 2 days to play with it than go off to some training course somewhere else to have it explained to me like I'm a toddler.

    Am I the only one?
    • That's training and education. What you need is 2 days where no-one's going to bother you with other work so you can train yourself.

      I hate those training classes where by the fourth day you know more about the subject than the instructor, or where the examples just plain don't work (like using Word97 as a COM container). Others have been really useful (Guerrilla COM springs to mind).
  • by Ars-Fartsica (166957) on Thursday April 04, 2002 @11:34AM (#3284716)
    And thats the crux of the problem. Often you have to deal with people who are not only immodest about their own abilities, but are often falsely immodest. I cannot begin to tell you how many Valley types think they are precious, irreplacable little snowflakes who wake up every morning knowing something new that us mere mortals simply could never divine.
    • I'll drink to that. The bloke I replaced thought he was god's gift, and far more clever than anyone else could ever possibly be.
      I thought he was a useless tosser who was all mouth and no trousers, and everyone hated him.
      Once I came to go through some of his work, I discovered that he'd spent the majority of his time adding pointless non-functional complexity to his scripts to make things look more difficult (and himself more clever) than they really were.
      Arse!
      • The funny thing is that I hate all the code ever written by everyone on the planet. The only good code is the code I am working on right now. In fact, code from last month is complete crap. Even (especially) the stuff I wrote myself. It's funny how judgmental I become when I look at code.

        For more information, refer to the "Not Invented Here" anti-pattern. I am a long-time sufferer.
  • His advice: Managers should be honest with their workers about the company's successes and failures, the point of management is to guide and suggest not to be autocratic, let the Einsteins have freedom in work environment, Einsteins are project-focused, not job-focused, they value training and education highly, they require a stimulating and fun work place.

    So how does this advice apply to Einsteins more than any other kind worker in any other department?

    This advice could be summarized by the Golden Rule of Management: Do unto your staff as you would have your manager do onto you.

    He could have also said, when all else fails, raise their salary.

  • the best managers (Score:3, Insightful)

    by dolphin558 (533226) on Thursday April 04, 2002 @11:37AM (#3284738)
    The best managers(especially in this field) are probably those who listen to their employees and actively work with them to find the best solutions. To all managers: stop asking other managers on tips on the most efficient ways of finishing projects...ask your own employees!
  • by SirSlud (67381) on Thursday April 04, 2002 @11:38AM (#3284750) Homepage
    My main pet peeve with the IT generation of managers is that they equate what is technically possible ("Hey, programmer, can we do this?") with what their minions actually want to do.

    I dont think you'll find many construction workers that like to build useless buildings (where the mgmt. in this scenario would cry, "Why not! You're building stuff! You're a builder!". In my mind, management tends to ignore the social aspects of project planning. I always like to say that I could write a scalable distributed inventory management solution in binary, if I really had to, but because of how utterly soul sucking and unfun that would be, I promise no matter how self-disciplined I might be, it will suck. Simply because I won't believe in _what_ I'm building, and thus my work will reflect that.

    Management needs to do a better job of understanding why programmers and techies often seem to resentful when being assigned projects - as the .com flop showed, those grumblins and skeptical snide remarks by your programmers are often going to be the first sign that what you're building might not be worth the social and technical trouble that the project will cause.

    Now, much of the IT industry is about spurring people against their will using rewards such as high salaries and job perks (nerf guns anyone?) to entice them to building things that businesses want. Programmers and techies can spot and sniff the 'empty promises' in technology (and there are tons), and it is a sign of bad management that ignores those types of hesitations and flies on the basis of what is 'techically possible' alone.
    • dont think you'll find many construction workers that like to build useless buildings

      Actually, builders seem to have absolutely no problem with that. They get a contract, they do the work, they get paid, they move on, without obsessing over whether the project is interesting or challenging or sexy like programmers do.

      as the .com flop showed, those grumblins and skeptical snide remarks by your programmers are often going to be the first sign

      Let's not rewrite history, OK? The techies were in the vanguard for that debacle. They were the ones leading the way, yammering about new economies grumbling about how those old-school types just didn't get it, yadda yadda yadda. They were rampant optimists. The skepticism was coming from above, and turned out to be well justified.

      Now, much of the IT industry is about spurring people against their will...to entice them to building things that businesses want.

      Sounds like a pretty fucking good business model to me. Much better than building things that nobody wants, that's for sure.

      Programmers and techies can spot and sniff the 'empty promises' in technology

      No, it's the people running the businesses who've learned to spot empty promises, like the "if you let us build it, they will come" promise of the dot-bomb era. The techies are more often the ones making the empty promises.

      • >The techies were in the vanguard for that debacle

        Um, maybe the opportunitists who knew enough about the technical side to hire programmers and such.. I'd say that generally, the programmers were not the 'techies' you're referring to. In fact, those 'techies' were simply one part pseudotechie (enough to sound like a technie to non techies, ie investors), one part management, and nine parts blind opportunists. In my experience, there were years there were management of people was completetly incidental to the management of perceived opportunities.

        I dont have a difficult time concurring that lots of young technical saavy management types fooled alot of other types into thinking that headstones.com was a surefire money maker. However, I really dont think you'll find lots of hardcore programmers who honestly believed that the very knowledge and technology that ostracized and isolated them from relating to much of the non-techie society (ie, like when using websites to buy stuff was considered very 'geeky') would be the template for mainstream business money making tommorow like those pseudotechie opportunists.

        And my parent post, in commenting about management, was more in reference to the young, new breed of manager rather than the older, admittedly more sane and skleptical manager. I find that managers with much more experience dont have near as much touble accepting my original contention (that its a bad idea to have people building things that they cannot comprehend the value of) than the younger set. The younger set seems to believe that the majority of talented, perceptive, well adjusted programmers are in it solely for the paycheque, instead of (what I believe from what I've seen) wanting to be able to better their world using the skills they either developed or were born with.

        There may be a greater number of people than ever who can justify working only for the dough involved, but I think its a frighteningly reductionist generalization about a group of people who may be representing and developing the next major chunk of infrastructure that your society and economy depends on. History is rife with examples of how the morals, ethics, and values (where values is the most important factor in the context of this discussion) of specialized skilled workers cannot simply be bought, no matter the cost. Anyone who suggests programmers should just be able to show up, code, go home, and no give a damn is either going to find themselves with a very unloyal, costly group of people to support, or forced into admitting that despite there being a need for something, if nobody wants to build it, it may benifit society as a whole to face the reality of unrequited demand.

        > Much better than building things that nobody wants, that's for sure.

        Obvious rhetoric of the week award, just for you! My point was its still not as good (both for society, and for the quality of production) as when the builders value what they're building in the same manner as those demanding the product do. And my point was that that factor is often ignored in this day and age; I think the quality of things being built is suffering for it.
        • I'd say that generally, the programmers were not the 'techies' you're referring to. In fact, those 'techies' were simply one part pseudotechie

          Nope, that's just denial. As unwilling as we true techies are to admit our own group's complicity, many of the people helping to inflate the dot-com bubble were from our ranks. They knew about some cool technology, and they were too naive too realize that cool technology is only one ingredient in making a successful business. The managers and marketers weren't alone in screwing things up, not by a long shot.

          My point was its still not as good (both for society, and for the quality of production) as when the builders value what they're building

          And that's a good point, but not one that anybody except a mind-reader might have taken from your previous post.

          • > Nope, that's just denial

            Or maybe my lack of experience (only about 5 years in this industry, 2 as a techie, 3 as a programmer). Here, I'm pulling from my past two bosses. Both were someone that our investors, and my mother would call 'techies'. They wern't programmers, tho. And talented programmers in both jobs got up and left at cruicial points - not because they wern't getting paid high enough to sell their skillset souls, but because their skillset souls were unavailable at any price.

            > And that's a good point, but not one that anybody except a mind-reader might have taken from your previous post.

            Thats why I always enjoy taking these discussions so far ... I find useful, valuable and new perspecives only once I find some context for someone's position and once I've been able to present them with how their message should be packaged, and because I know my messages dont always come across the first time either. :)

            I'm still gunna stick with my distiction between techies and the programmers tho. I think the techies screwed shit up (including those able to program), but I stand firm that born-and-bread-I-made-choose-your-own-adventure-ga mes-when-I-was-7 programmers were always hesitant to oversell a technology who's shortcomings and differences between reality and brochure were only intimately and truely known by them.
  • by garver (30881) on Thursday April 04, 2002 @11:42AM (#3284773)

    Where's the book "Working for PHBs"? Seriously, isn't that the other half of the problem? The word "Einstein" is used derisively, I think, to say IT workers are arrogant asses that assume all those above and around them are idiots. So, "Managing Einsteins" would be a book about appeasing these Einsteins while getting them to do what you want (e.g. herding cats).

    On the other hand, the Einsteins derisively refer to management as PHBs because they don't completely understand technical issues and make decisions on loose technical-ground. Sure, we could blow this issue off as management being stupid, or we can learn, for example, how better to comminucate the issues so the PHBs can make better decisions. It might also enlighten us to the fact there is more to a decision than just the technical side, such as marketing, customer acceptance, product portfolio, etc.

    Bottom line, its two different cultures. To get them to work together requires efforts and respect on both sides.

    • Bottom line, its two different cultures. To get them to work together requires efforts and respect on both sides.

      That is why Dr. John M. Ivancevich and Dr. Thomas N. Duening, the authors of "Managing Einsteins", are writing their next book entitled "Working for Rockefellers".

  • I know it's a cool Dilbert-esque thing to make fun of salesmen, but it's a rather stupid assumption to assume that salesmen are any more or less motivated by money than "Einsteins".

    The last time I checked, salesmen are human too, and as such have a fairly wide range of motivations, from workplace comfort to a good peer group to flexible hours to money.

    Or maybe the sales guys at my company are just weird...

  • Only IT workers? (Score:4, Insightful)

    by zeus_tfc (222250) on Thursday April 04, 2002 @11:45AM (#3284785) Homepage Journal
    At the risk of reminding people that there are more ner...ah, "Einsteins" out there than Computer "Einsteins", I think this has more applications than just in the IT industry. The IT industry has been heavily stereotyped, but so have engineers. I work in the Plastic Injection Molding industry, designing automotive parts. How much less does this apply to me? Our Engineers need to feel at ease in office. We need the freedom to be creative and imaginative. This benefits the company as well as the engineers. How?
    1)Patents. The company gets a patent with the Engineer's name on it.
    2)Money. Our new ideas could potentially save tooling costs, material, or cycle time, all of which means we can save our customer money, and make more money.

    Slashdot may be "News for Nerds", but I think people need to be reminded that all nerds aren't computer nerds

    just an opinion
  • Holy moly! What a pretentious load of wank this book is. 'Managing Einsteins', indeed. I love this bit: "a stimulating and fun work place" No. Stimulating and Fun is what I do when i'm NOT at work!
  • Who doesn't hate it when a promised project get's shitcanned?

    Who likes to be constantly interrupted from productive work?

    What percentage of *all* employees are interested in promotion management? In my experience IT people are no less likely to want to be promoted to management.

    Who doesn't like work that is challenging, but achievable?

    And as far as IT workers enjoying a "project focus" - doesn't everyone? It's nice to have some structure, a beginning, a middle and an end. I don't think a desire for such structure is unique to geeks.

    The points the book makes are very general management principles, and don't apply to only "Einsteins".

    -josh
  • bu? (Score:4, Funny)

    by nomadic (141991) <nomadicworld@NOSpam.gmail.com> on Thursday April 04, 2002 @11:47AM (#3284801) Homepage
    tribal and independent.

    But that..err..

    Wouldn't--?

    Nevermind.
  • by Infonaut (96956) <infonaut@gmail.com> on Thursday April 04, 2002 @11:56AM (#3284864) Homepage Journal
    Here's something about managing: the people who take the discipline of leading an organization seriously (yes, it's a discipline, and a difficult one) are always searching to learn more. They want to be better managers.

    Most managers, however, are not necessarily trying to become better managers. In organizations both large and small, management training often consists of a 30-minute exit interview with the person you're replacing (if you're lucky).

    Someone's a good accountant? Make them head of accounting. Got a really kick-ass salesperson? Make her head of sales. One of your Java programmers knows more than the rest of the team? Make him your CTO. After being promoted to such a position, with no real leadership training, how could you not assume that you're just a natural born leader?

    Unfortunately this approach just doesn't work. Cultivating leadership in any organization is difficult, time-consuming, and doesn't offer immediate dollars-and-cents results that the bean-counters can quantify. The fact that there is so much literature on leadership shows the very real dearth of good organizational leadership training in the corporate world.

    The managers who read this book are likely improving their management skills, but they're not the ones who need to read it. Unfortunately, the ones who do need to read such books never will, because they know they've already got that "management thing" all figured out.

    • Let me share my personal experience of moving from a tech position into middle-management.
      I was hired for a development dotcom as team-leader for the internal IT-group, but since we had no IT-manager my role more or less shifted into that of a IT-manager.

      One of the things I came to realize is that being a manager, whether for smart och not-so-smart people, is a rather difficult thing which should be viewed as any other discipline which requires high skills and strong people skills.
      This didn't exactly come as a shock to me, but I hadn't really thought that much about how much it would tear me down personally.

      I think my problem was that I lacked good management skills and insight into what motivated my staff. While I realized this quite fast I really tried to do a good job and keep everyone happy.
      I got pretty mentally exhausted after this period and I'd probably think twice about taking up any job which involves managing peolpe again, but I'll probably do it at some point in the future since I got the feeling that it can be a highly rewarding job, and not just in terms of economic compensation (I could probably earn more as a database developer than manager anyway).

      Coming from a tech background my personal belief now is that tech jobs, while often demanding strong intellectual skills, usually deal with logical problems with tend to have logical solutions, but management (at least of human resources) deal with highly illogical humans and therefore is a much tougher discipline to master. Another thing that adds to the difficulty of management is that managerial positions often demands you to be proficient in multiple disciplines (much like developers...)

      For all you people who're dissing managers and sales people (and all other non-cool positions) I only have one thing to say:
      Treat them with the same level of respect as you want to earn yourself and by all means, if you think you can do the job better give it a try!

  • by thesparkle (174382) on Thursday April 04, 2002 @11:58AM (#3284882) Homepage
    I have been a manager in different capacities for the past 5 or so years and here is my take on this:

    1) Treat people the way you want to be treated. Nobody likes working for a taskmaster or driven to the point of burnout. Treat people (especially people you are responsible for!) with respect and they in turn will respect you and the organization.

    2) Make goals, plans, project, expectations, etc clear. Vague, mushy, "changing target, shifting paradigm BS" does not encourage or motivate people.

    3) Be flexible in what you do and your people will be as well. If you want someone to fix something at 2 AM, offer them the opportunity to work business hours from home, or from another suitable remote location on a regular basis.

    4) Train, educate, teach. Send people to offsite classes. Buy them books and software if they request it. Subscribe to magazines and journals. Send people to conferences and conventions. Invest in your people and they will bring back knowledge and stay for more. If you are worried that CCNA you just paid for will leave after certification than you either hired the wrong person or you have a crappy workplace. Good people stay at good places for more good training and investment.

    5) Be honest. If things are bad at the company and there will be layoffs or bancruptcy, let your people know as soon and with as much information as soon as possible. People have mortgages, families, bills. Show some respect.

    6) Remember personal lives. Tech workers are no different than other people. What we have all found out in the past few years is that tech workers don't want to sleep under their desks for 10 years. Send them home. Let them spend uninterrupted time with friends, family, and other non-work beings.

    7) Free cokes, toys, games, and other fluff is just that - fluff. In today's "Enroned", recessionary times, people want stability, reliability and honesty more than a foozeball table, rollerblade court and hiking trips. Tech workers (for that matter all workers) should not have to worry if paychecks will bounce or be non-existant, if their 401k or pension scheme is solvent, or if their payroll taxes are being filed correctly.

    8) Finally, have technical people with leadership qualities lead. I was a sysadmin and network admin before being tapped for a management role. I understand what my people are talking about from experience, not from a book or training class.

    Just some thoughts from the last few years. All lessons learned from experience.

  • by revbob (155074) on Thursday April 04, 2002 @12:01PM (#3284904) Homepage Journal
    I may or may not be an Einstein, but forget about not lying to me about the health of the company. I can figure that out by myself. But never lie to me about a deadline.

    If you say "I absolutely have to have this by such-and-such a date," I'll sacrifice my mind and body to make the deadline.

    But if I turn my work in and discover that you weren't serious about the deadline, it'll be a cold day in hell before I do it for you again.

  • 1. Einsteins ? What the hell ? OK, so the author wanted to avoid "geeks", and "tech workers" is too long, but honestly ...

    2. Most of the advice is applicable to managing *anybody* not hopelessly demoralised and/or terminally stupid.

    3. "Peopleware" already tackled many of these issues without having to flatter its audience so much.
  • Already been done (Score:2, Informative)

    by Lauri Alanko (66)

    In a similar vein, though much more concise (and free!):

  • by ppetrakis (51087) <peter.petrakis@gmail.com> on Thursday April 04, 2002 @12:49PM (#3285288) Homepage
    FIRE THEM.

    Or don't hire them to begin with and instead hire a compitent engineer or two who can can stick to the most important schedule. The managers.

    As rude as I may come off. Einsteins or whatever you want to call them are NOT dependable. They do what the want, when they want, and how they want. Most of the ones I've had the displeasure of meeting are so self absorbed and into self-gratification so much that it makes working TOGETHER AS A GROUP with them in a structured development environment unbearable. They often work ALONE and the work that they do which others depend on go by their clock, not the companys.

    The few I've had to work with whom are considered "oracles" did not have the ego tripping the others and could work well with groups but alas their communication skills where lacking. While they could do anything you asked them to. Ask them to describe something acute to you that would normally take a few moments and you could end up being there 15x longer than expected. OMG forget about meetings.

    While the later I can bear and bridge the communication gap to achieve OUR goals because it is worthwhile. The former can take a hike. There is nothing any compitent engineer cannot accomplish given a reasonable amount of time and resources. The rest are wildcards which begs the question. Would you bet money on that schedule or better yet, your job?

    Peter

    • Most of the ones I've had the displeasure of meeting are so self absorbed and into self-gratification so much that it makes working TOGETHER AS A GROUP with them in a structured development environment unbearable.
      I work fine in a group, as long as I'm not forced to put up with incompetent idiots, either as cow-orkers or management.

      I won't slow down my production or tolerate laziness just to avoid hurting the ego of others -- generally I work best when my peers are at least as smart as me, if not smarter. I've had the luck to work with some very bright people, and we work together as a group, and meet our deadlines -- not following the company clock on any given day, but still putting in a solid work week in the end.

      They often work ALONE and the work that they do which others depend on go by their clock, not the companys.
      I work very well with a small team of equally bright people. Some members of my team are morning people, some are not. But at the end of the week, we still get the work done.

      I contribute much more value to the company than "any compitent engineer". I also am not a morning person, and making me follow a strict 8:30-5:00 schedule might make my manager look good to his superiors, but is only going to hurt my morale and productivity.

      The worst possible manager is one who is more interested in looking good to his superiors than keeping his direct reports happy. My team has no problems with me starting later in the day and leaving later in the evening... the only people who complain are members of other groups who see me wander in at 10:30 and feel like I have a privilege they are missing. Of course, they go home at 4:30, and never see how late I stay.

      While the later I can bear and bridge the communication gap to achieve OUR goals because it is worthwhile. The former can take a hike.
      Sounds like you have some problems of your own.

      There are way too many people in I.T. who are either stupid or lazy, and only put in the minimum amount of effort (plus plenty of sucking up to the boss) to avoid getting fired. This is encouraged by the tolerance of this behavior by management, who see a quiet employee who doesn't make any waves and value them as much or as more as the "Einsteins" who accomplish 10x as much in a given week, but also require a bit more flexibility and perhaps even a few perks every now and then.

      • work fine in a group, as long as I'm not forced to put up with incompetent idiots, either as cow-orkers or management. I won't slow down my production or tolerate laziness just to avoid hurting the ego of others -- generally I work best when my peers are at least as smart as me, if not smarter. I've had the luck to work with some very bright people, and we work together as a group, and meet our deadlines -- not following the company clock on any given day, but still putting in a solid work week in the end.

        I wouldn't ask you to slow down. What "I" want is to get the job done. I don't care anymore to impress anyone and ego fluffing is not something I care for either. You're here because you can do the job, so get it done. You don't have to wear a tie or nice pants or go to meetings unless I ask you to accompany me.

        They often work ALONE and the work that they do which others depend on go by their clock, not the companys. I work very well with a small team of equally bright people. Some members of my team are morning people, some are not. But at the end of the week, we still get the work done. I contribute much more value to the company than "any compitent engineer". I also am not a morning person, and making me follow a strict 8:30-5:00 schedule might make my manager look good to his superiors, but is only going to hurt my morale and productivity.

        Right, that point doesnt apply to you since you do get it done in the work week which is what most projects are measured by. Look. I understand if someone isn't a morning person and rolls in around 10, but the ones I knew who did that also stayed still 7. They we're also available during the work day as a resource to their colleges. The ones who are unacceptable are the 1PM to 4PM, oh I missed the morning meeting and I knew they wanted me there, correspond by email more than a telephone (from home), are not available as a resource when their colleges need them, and get the job done at the last possible moment because they can (doesnt always mean they got it right). Those are the ones I don't like.

        The worst possible manager is one who is more interested in looking good to his superiors than keeping his direct reports happy. My team has no problems with me starting later in the day and leaving later in the evening... the only people who complain are members of other groups who see me wander in at 10:30 and feel like I have a privilege they are missing. Of course, they go home at 4:30, and never see how late I stay.

        Right see above, as for the the whiners. They'll get the message when they don't get the raise or promotion they 'think' they deserve.

        While the later I can bear and bridge the communication gap to achieve OUR goals because it is worthwhile. The former can take a hike.

        Sounds like you have some problems of your own. There are way too many people in I.T. who are either stupid or lazy, and only put in the minimum amount of effort (plus plenty of sucking up to the boss) to avoid getting fired. This is encouraged by the tolerance of this behavior by management, who see a quiet employee who doesn't make any waves and value them as much or as more as the "Einsteins" who accomplish 10x as much in a given week, but also require a bit more flexibility and perhaps even a few perks every now and then.

        :-), It's not computers, or .com crap , or technology anymore. It's about people and communicating effectivly. The majority of tech guys get any given job because of their tech skills not their people skills. Take the IT example. If the IT tech can solve a customers problem but has 'not' left that situation with that user being a 'better' user than they we're before, Then they have failed. It will happen again and IT will be called upon to fix it AGAIN. Why is this? They are not communicating effectivly with the other end.

        I don't suck up to my bosses. I will be the first one the vigoursly disagree with an authority and ask the hard questions. I am the FIRST one to roll up my sleeves and get into a problem. I lead by example , not lip service. I do not comprimise myself or my integrity nor will I ever comprimise any member of my team to outside influences. I've been accused 'many' times of being former military which isnt true but given my style, I can understand why people may think that.

        Bottom line. Any given 'smart' person can do XYZ faster than a 'plain jane' engineer. My challenge to you is to take that vast intellect of yours that is so effective at solving problems in the tech arena and focus just a portion of it on your communication skills. The results are impressive as they are rewarding when by your hand, Make the people around you better at what they do. Which in turn will make the group more effective and efficient.

        It's called teaching and someday when I've had enough of the industry. My title will have the words "Prof." instead of "Engineer".

        Peter

    • "...did not have the ego tripping the others and could work well with groups but alas their communication skills where lacking. While they could do anything you asked them to. Ask them to describe something acute to you that would normally take a few moments and you could end up being there 15x longer than expected."

      It takes time and training to develop a skill which is not innate. Everyone has their different apptitudes. I don't expect my manager to code like me and he shouldn't expect me to communicate as well as him. The real question is how good do your employees programming skills have to be to justify the time investment necessary to manage them properly? If those guys waste meeting time it's just part of their management cost. Its possible that its worth your wasted time in a meeting. Really, what portion of time are coders in meetings anyway?
    • You had "prima dona"s, not Einstiens. There is a difference. I'm not an Einstien, but I have worked with some of them. I worked with a couple of guys briefly in the past. They worked odd hours, and they worked a ton.

      At times they were unpleasent to be around, but they could get the work done. They told customers the God's honest truth every last time. So they didn't get to work with customers any more. The two guys formed the core of a 30 person company. Pretty much everybody else there was to support the business of collecting the money and organizing requests for new development. That was it.

      They worked 90 hours a week when needed. They didn't miss deadlines. They made star trek jokes, and weird references to esoteric math problems.

      There is a difference between somebody who has jacked with technology, and a small crew of people who can get the work done on time everytime. The reason they were so incredibly valuable, was they avoided the single largest time consumer of developers. Communication, go read the mythical man month by Fred Brooks.

      Working alone is a huge boon. Working with people who are highly focused and like to work along is quite a trick. Once you get good at it is extremely efficient. The couple of guys I saw working together would divide up the work and run off and work without much in the way of communication for a week at a time. They agreed on the fundamental interactions between the seperate parts, met that interface, the rest were details. They work alone because they don't need to communicate.

      Most work is actually done alone, with infrequent reports. If communication skills are a problem, there is a problem. Your spending too much time communicating, more then likely. Great technical people don't communicate much inside the technical group because they shouldn't have to in a good group. They don't communicate with people outside the group because they consider the rest of us boring. Getting together in a big meeting to discuss progress is a waste of time. Having a manager who walks around and discusses individual progress is the way that is done. Having a meeting if they aren't getting it done to regroup in relatively dire situation is a good idea.

      Having discussions with poeple who are lying about progress is a good idea. Firing people who continue to lie about performance, yep should do that. The best technical people never ever lie, no need to, they have valuable skills and understand that lying is a cardnial sin that will hurt thier professional reputation. All you have to do is ask, are you making progress. You'll have your answer, if they lie, fire them on the spot. If they don't make work on the assigned tasks, fire them, they aren't professionals.

      Motivate them by giving them projects interesting projects. Give the multiple projects to work switch between if they are all boring, just to get a change of pace. Meet infrequently to discuss high level goals. Ensure the techincal lead is somebody who can bridge the gaps between the Engineering side, and the rest of the group. Make sure the lead does bi-weekly rounds, and keeps you informed of problems. The internals of a good Engineering department isn't something most people would like if they saw it. Just like I wouldn't eat sausage ever again if I saw how it got made.

      Sounds like you had some bad employees who thought very highly of themselves. You probably had a couple of Einstien's and didn't know it. Not all of them are incapable of communicating. Quirky people who work odd hours aren't bad if they make progress and do the work.

      The rest of them are slackers trying to pass themselves off as hard workers... Uhh, welcome to management. You get that if you work in an IT department all the way down to your local fast food place. Prima Dona's are a dime a dozen, Einstien's are a diamond in the rough. Keep the valuable stones return the high matiences low volume employess.

      If you're secretary is a slacker, probably not much of a deal. If the guy who watches the database that is the heart of your company, is a slacker you have problems.

  • There was a book I read many years ago called Peopleware (even before review [slashdot.org] by Hemos ). I think this book is most excellent and even applies to today's situations.
  • The Manager FAQ (Score:3, Informative)

    by Dusty (10872) on Thursday April 04, 2002 @01:18PM (#3285520) Homepage

    Considering the topic this isn't out of place. The Manager FAQ [plethora.net]:-

    The following list is an attempt to cover some of the issues that will invariably come up when hackers without previous experience of the business community first start working in it. Other workers may also find it informative.

    A handy guide to dealing with management. Also useful for manager's dealing with hackers.

  • No book, no matter how "on the mark" it may be (and I'm not saying that this one is, as I haven't read it), can teach a manager how to earn the respect of the people reporting to her. The problem with most IT managers is that they are either:
    1. Non-technical people with MBAs who probably can't write a "Hello World!" program.
    2. People who were tech people at one point, but are so far removed from it that their experience is not useful or applicable.

    That's the problem. The solution is to have your managers be tech people. A lot of tech people are not giong to make good managers due to lack of leadership ability, social skills, etc. However, some tech people will make good managers. Also, teams should be 4-5 people at most, with one of the team members managing the project. That is, the person managing the project should still be writing code.


    One other thing I've noticed ... Having a hierarchical organization for tech people generally doesn't work. All of the aforementioned tech managers should report in to one high-level person who knows the goals outside of the tech organization.


    When I run the world, things will be different ...

  • Speaking as someone who's traveled the geek-to-management chain (by accident rather than desire), I disagree with the 'only book' sentiment. I work in an industrial research community and manage a small (dozen or so) team of researchers - some of whom certainly are more qualified to be dubbed Einsteins than your typical programmer (no offense!).
    Intellectual egos have long been extant - look at Rutherford. I'd be doomed if I worked anywhere near him! We have tons of experienced, genuinely brilliant PhDs in our organization, and they range from the pleasant humble mannerism of Einstein to the brash obnoxiousness of Rutherford. Yet as a member of the management community, I need to help drive all these folks towards common goals while sharing the same resources and space. Sure it's not easy, but I think the right route to address this for IT folks is similar to what we do in science. Waving my magic wand, I'd make these recommendations for what most IT related workplaces need to learn:

    1) Management and promotions are two different things.
    2) Managers DON'T have to make more than those they manage.
    3) You cannot and should not treat everyone 'equally'.
    4) There are others, but I'm lazy

    To be more verbose (okay, really verbose):
    1) Management and promotions are two different things.
    We have three career tracks in our R&D community - Technical, Project management, and Leadership (an aside - being a leader and being a manager are two very different things - there's overlap but not anywhere near as much as most companies treat the roles and everyone uses the words interchangeably - but we shouldn't. I feel my own company falls short on this one).
    -Technical is just that - at the top of the game, you're one of the world's authorities on Boise-Einstein-Pies, and get both recognized (and compensated) as such. You're encouraged to educate yourself to stay that way.
    -If you move up the project management chain, you may coordinate projects across divisions involving dozens if not hundreds of people to pull a program together, basically exercising responsibility with no direct authority over the managers - this involves a lot of leadership skill.
    -Finally, the 'leadership' track is the classic managerial path that leads towards the corporate management food chain and business practices. Note that this take you OUT of that techie/science chain if you go far enough up. Setting aside the discussion of overcompensated CEOs, each of these paths can bring both strong job satisfaction in the role and financial recognition, INDEPENDANT of the actual managerial structure.
    2) Managers DON'T have to make more than those they manage - I certainly don't make more than some of the folks on my crew, and I shouldn't. They're more skilled technically, they have much more experience, and they have far more education. A lot of companies seem to have some problem with this, and that really prevents them from focusing on the right skillsets for a given job.
    3) In our litigious society we're encouraged to apply the same rigid standard to everyone - unless they fall into a large collection of legal categories. As a result, it takes a little more courage to publicly say 'sure, you can always have Friday afternoons off with comp time' without offering it to everyone. Or giving very different pay raises to people based on the work that they've done, and then explaining to someone why they've gotten a below average raise. Some people can be very self sufficient, and others need a great deal of guidance. This means different people need different tool (one needs a PDA while the other needs some 3x5 cards and a crayon (ala CoyboyNeal)). Companies need to foster an environment where petty bickering (usually through envy or jealousy) isn't an issue. In the above example, if someone's upset because someone has a PDA, it's usually not because they want a PDA, it's because they want some form of recognition or visible acknowledgement for themselves - comes back to that whole ego thing. If they're just petty, you may want them to find a job elsewhere.

    Enough! If you're still reading, then I'll make a suggestion. I'd look at Buckingham and Coffman's books from the Gallup organization (First, Break all the Rules and Now, Discover your Strengths) if you're interested in tech management yourself, or want to help your PHB (euthanasia is usually out). The books are chock full of interesting data, which the authors use to derive their philosophy from. Sure some of the stuff they say is obvious - but I think it's the first decent explanation of why TQM usually fails other than 'management screwed it up'. TQM is a nice idea, but the practice is based on some assumptions about organizations that are often false. There are lots of good examples that apply to every environment whether you're looking for excellent people in a dynamic (read: chaotic) environment or mediocre people in a rigid bureaucracy. Even if you don't agree with everything they suggest, it's good brain food.
  • Autism and Coding (Score:3, Interesting)

    by oGunner (571210) on Thursday April 04, 2002 @02:00PM (#3285865)
    I know, Autism is a beneficial trait for getting the bits and bytes right in code. How do you manage these people. How about manageing complexity? This is what "Einsteins" do. Managers of people have to consider the narrow focus and blinders IT folk put on when managing complexity. It requires a bit of a pull and a lot of push to get in and out of context (context used here as diving into the problem, scoping out its bounds and mapping it to code). Temporary Idiot Savant if you will. It is the real programmer who can quickly change levels when asked by marketing, what that new algorithm means to his customers. I've just been dropped into a position that has no management, no real marketing and a unfamiliar product market. Now I have to come up with a product that will make money. I used to be a programmer. Now what am I? I'm not sure, but I enjoy the rollercoaster ride when I think from the level of the customer, through the product features to the architecture to the outsourcing and if I can find time to write the drivers.
  • New hierarchies (Score:3, Informative)

    by Courageous (228506) on Thursday April 04, 2002 @02:59PM (#3286313)

    Where I work, techies and management dual-track
    all the way to the top. Furthermore, the higher-echelon techies earn significantly more than middle to senior management, except for those management personnel in executive tracks.

    For example, we have "division engineers" and "division scientists" and "principal engineers", "distinguished engineers", and so on. These are all very high-level high-paid technical positions. In these top tracks, you usually have additional responsibilities to your organization above and beyond simple coding, but you are still not a manager. You are likely a tech lead; you probably help write proposals; you likely contribute to organization-wide technical decisions, and so on. But you're still not a manager, and generally speaking, people don't report directly to you.

    Most every one of our larger efforts has one manager and one senior technical person who run the project bicamerally. This is a very good model, IMO.

    C//
  • by John Murdoch (102085) on Thursday April 04, 2002 @03:29PM (#3286577) Homepage Journal
    Now, I can understand the mannerisms and habits of Einsteins can be a little unpleasant at times, but it begs the question, why would a manager take one of these people out to a client dinner in the first place? If the client needs to meet the tech people to be convinced that a company can do the job, why not at the place of work?

    That statement makes sense. Which proves something:

    You will never make it in sales.

    Sales people are full of, well, effluvium. And there is always a point at which your sales guys rise to the level in the organization where they need to make deals with other sales guys at that level in another organization. Both sets of uber-sales guys know that they're all sales guys--and thus full of effluvium. In consequence, the other guys recognize that your sales guys' presentation on your hot new technology is, well, effluvium.

    No effluvium, really...
    Faced with a customer who knows you are full of effluvium, what can you do? You bring the tech folks along. You don't sponsor a meeting where our techs meet with your techs (or even better, a Quake death match LAN party where our clan cruelly destroys your avatars and every morsel of self-respect you may have fooled yourself into...well, maybe that's not such a great idea). The idea is that your techs impress the daylights out of their uber-sales guys--who, being full of effluvium, are easily impressed.

    That's how I ended up playing golf, once...
    Being a 4-H leader, I view the game of golf as a waste of good pasture land [eventingusa.com]. I was at a client's, installing a new application on their servers, when the company president dragged me into his office, picked out a golf shirt, and told me we were going to Pensacola, Florida to "do a little bidness." Right then.

    I ended up doing an off-the-cuff presentation on the new product, with commentary on some of the features of the database schema and our techniques for automatically updating pricing. Based on the blank stares from the audience I doubt they understood one word in twenty. "But thass all raht," said the client, "in fact, that was kinda the point." To thank me for this, he subjected me to 18 holes of golf at some allegedly-exclusive golf course with all the sales types I'd been lecturing. Who, of course, knew how to play golf. The fact that I clearly did not seemed to further establish my technical credentials.

    Learn from this, young Jedi...
    Don't try to understand sales people. They are clannish, socially disfunctional, and have a tribal suspicion of outsiders.

  • How about a book on how tech workers should treat their managers? As a former tech worker turned manager I would be more than happy to see the developers get "purks" above and beyond all the "less" intelligent people --- however at that point they better earn it....Don't rest on what you know today -- go home and hack away and learn the new technology and toolsets....Einstein was not a one trick pony that came up with 1 good idea and lived off of that the rest of his live --- he continued to invent.

Chairman of the Bored.

Working...