Slashdot Log In
Managing Einsteins
from the keep-the-brain-jars-upright dept.
| 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.
Ummm... (Score:4, Funny)
Re:Ummm... (Score:5, Funny)
Or something.
Re:Ummm... (Score:4, Funny)
Re:Ummm... (Score:4, Funny)
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" :)
Re:Ummm... (Score:5, Funny)
I think he means that techs are Einsteins "relative" to the management.
(sorry)
Re:Ummm... (Score:5, Funny)
My dog is an Einstein relative to the management...
Re:Einsteins defined (Score:5, Funny)
Well, there was the new order-N sort algorithm that was described recently.
It was based on the concept of a quantum computer. The idea was that in to sort N items, you use quantum indeterminacy to choose a random permutation of the items. This will cause the universe to split into multiple copies, one per permutation. You test the resulting list (an order N operation), and if it's not sorted, you destroy the universe. In the remaining universe, the list will be sorted.
Destruction of the universe was left as an exercise for the reader.
If this isn't on a par with nuclear physics, I don't know what is. And it's Just a Matter of Programming
What about the sequel? (Score:5, Funny)
4 Posts in one! (Score:5, Insightful)
Re:What tech workers want? (Score:4, Interesting)
1) Upper quartile pay for my work location and expertise.
2) Pension scheme.
3) Health insurance.
4) Bonuses/options.
5) No dress code.
6) Novel and interesting work domain.
7) Access to powerful development and test machines.
8) Choice of technologies for projects.
Important point (Score:5, Insightful)
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.
Need a raise? (Score:5, Insightful)
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.
All I ask from my manager: (Score:5, Insightful)
Re:All I ask from my manager: (Score:4, Insightful)
"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
replace (Score:4, Funny)
Stick THAT in your MBA PHB pipe and smoke it, Mr.!
Not that I'm bitter =]
Re:I'll tell you how to keep us happy (Score:5, Insightful)
I don't want free sodas at work (I do like the subsidised canteen to be decent quality though), I don't want junk food, I don't want trash all over cubicle, I don't obsess about [Monty Python|Star Wars|LoTR], I don't want to fire Nerf Guns at fellow employees - I want to be treated like a mature professional doing a professional job.
I want money not some novelties scattered around the room. I want a quiet office, not a playpen. I agree that I want to know when the business is on the slide. I want influence and respect from people in suits. I want to be understood when I talk at project meetings. I want an understanding in the manager's head of why what I'm telling matters.
Tricking out your cubicle with action figures etc is just begging to be treated like a child. No wonder your boss seems like the PHB; to him/her you probably seem like a child. Or worse, a social misfit, a weirdo. Someone who's useful but fundementally unreliable.
Secondly, I don't see much "geek attitude" or reviews of Episode II trailers in mainstream trade journals (Dr Dobbs, Appication Development Advisor, Software Development) or in more seriously coding forums. In my experience, and I know this is pressing buttons, those who most loudly beg for ping-pong tables in work are those with the most inflated egos and least developed skills. Lets face it
More like "Think They're Einsteins" (Score:4, Interesting)
the best managers (Score:3, Insightful)
Just because you _can_ doesn't mean you _wanna_ (Score:4, Insightful)
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
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.
Re:Just because you _can_ doesn't mean you _wanna_ (Score:4, Insightful)
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.
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.
Sounds like a pretty fucking good business model to me. Much better than building things that nobody wants, that's for sure.
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.
What about reverse? (Score:5, Insightful)
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.
Only IT workers? (Score:4, Insightful)
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
bu? (Score:4, Funny)
But that..err..
Wouldn't--?
Nevermind.
Those who read it area already clued in (Score:5, Insightful)
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.
Managing technical people (Score:5, Insightful)
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.
Don't lie to me about deadlines (Score:5, Insightful)
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.
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.
I know a great way to manage "prima dona"s (Score:5, Insightful)
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
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.
This is an old problem, IT is just a new context (Score:5, Insightful)
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)
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//
Don't try to understand sales people.... (Score:3, Interesting)
That statement makes sense. Which proves something:
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.