Managing Einsteins 345
| 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:
- 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.
- 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.
- 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.
Re:Important point (Score:3, Informative)
Already been done (Score:2, Informative)
In a similar vein, though much more concise (and free!):
Re:Important point (Score:3, Informative)
OUCH, that's a little scathing, but not altogether troll-like. There are some things that senior developers can do that someone just out of school can't (and there are exceptions in both directions).
I have worked for a small business (currently at a 50 person company), a not-so-small business (500 person company), and contracted to some big ones (read SAIC, who acts like the biggest company in the world). Not the best sampling, but decent.
At the 50 and 500 person companies, senior developers bring a lot to the table. They figure out how to solve the customers' problems. They are the subject matter experts--the customer knows they have a problem, but doesn't know what it is or how to solve it. Senior dev mentor the junior dev.
The fact is, there are some problems that hiring a dozen fresh graduates won't solve that a single senior developer can. It isn't always about pumping out code (if it was, we'd write a code generator for it). And for those fresh graduates that can perform as senior developers, they'll get promoted quickly.
Companies that do not see this are going to wind up short on talent. I've noticed this at the big companies. They have a lot of talented programmers--all contractors. They have a lot of junior developers as permanent employees. Any of the junior developers who make the grade jump ship and become contractors, or they go work for someone who treats their employees right.
Re:Practiced before (Score:4, Informative)
They started getting rid of that system some time in the late Seventies or early Eighties, I believe, mainly to clear up any confusion over rank precedence -- e.g., if you've got an emergency and there are no officers around, who takes charge, a Sergeant (E-5) or a Spec-6? The answer was "it depends," and that's the kind of answer with which militaries are very uncomfortable.
However, in my time in (two years Army infantry, eight years Air Force medic) I saw that realistically such a structure still exists. In technical fields such as communications and medicine, especially, there are a lot of high-ranking people (both enlisted and officers) who don't actually have many (or any) people directly under their command -- but they're very good at their jobs, and the service recognizes that and rewards them with promotion. It works out pretty well all in all.
Book sounds interesting but..... (Score:2, Informative)
The Manager FAQ (Score:3, Informative)
Considering the topic this isn't out of place. The Manager FAQ [plethora.net]:-
A handy guide to dealing with management. Also useful for manager's dealing with hackers.
I'm no Einstein... but most managers suck. (Score:3, Informative)
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 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.
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.
mythical man month... (Score:3, Informative)
he worked at IBM, it wasnt an IBM study.
and his book is great.
Re:I know a great way to manage "prima dona"s (Score:2, Informative)
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?
New hierarchies (Score:3, Informative)
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//