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.
Ummm... (Score:4, Funny)
Re:Ummm... (Score:5, Funny)
Or something.
Re:Ummm... (Score:2, Funny)
---
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:2)
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)
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...
It's relative (Score:3, Insightful)
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.
My new resume (Score:3, Funny)
I think I'll write something like this in my resume:
Everyone will want to hire me.
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
Re:Einsteins defined (Score:2)
/Janne
Re:Einsteins defined (Score:2)
With parallel tests it is of course O(N). My bad. But why stop there? Why not split each list into overlapping pairs: [1,2], [2,3], [3,4]... and let each 'sub' universe destroy itself if the pair is sorted. If there are no sub-universes, this usiverse stays (as it is sorted). If there are remaining sub-universa, we destroy them, and ourselves. This makes it an O(1) algorithm (assuming the creation of all these parallel universa is in constant time and in parallel).
/Janne
Re:Einsteins defined (Score:2, Insightful)
Re:Einsteins defined (Score:2)
Well, of course not. I was just repeating someone else's algorithm. They deserve the credit for the humor, not me.
What about the sequel? (Score:5, Funny)
I could use this (Score:2, Interesting)
So I guess this whole long story was to validate a need for your book.
Re:What about the sequel? (Score:2)
"Managing Programmers for Dummies"
Makes sense (Score:2, Interesting)
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.
Way offtopic.... (Score:2, Funny)
4 Posts in one! (Score:5, Insightful)
Re:4 Posts in one! (Score:2)
I hope so, I won't work anywhere that doesn't have free soda.
Free Soda? (Score:2)
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...
They only listen to each other (Score:3, Insightful)
Managment types don't listen to geeks. If they did, we wouldn't need books like this in the first place.
Re:4 Posts in one! (Score:2)
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.
Amen! Try this exercise: (Score:2)
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.
Re:4 Posts in one! (Score:3, Funny)
--
Damn the Emperor!
Where are you? (Score:2)
We are!
So where are you located, and where do I submit my resume?
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.
Re:Important point (Score:3, Informative)
Re:Important point (Score:2)
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.
Re:Important point (Score:2)
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
Re:Important point (Score:2)
The Peter Principle, yes.
Unfortunately it's not entirely true: I know a number of people who have risen far beyond their level of incompetence.
This is typically because the manager doesn't want this person working for them --- the employee is a total idiot, of course, and usually grating, too --- so the manager gets said employee promoted to the same level as him or herself, thereby no longer "getting" to manage said employee.
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:Important point (Score:3, Insightful)
mythical man month... (Score:3, Informative)
he worked at IBM, it wasnt an IBM study.
and his book is great.
Re:True enough. (Score:2)
A few countries in eastern Europe tried out that philsophy, it didn't work so hot.
Elitism, oh so tasty (Score:2, Insightful)
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.
Cryptonomicon (Score:2)
Randy, Lawrence's grandson, grows up to be a moderately badass hacker. He explains that there are tough problems to solve, and there is everthing else. He calls everything else "making (or was it punching?) license plates." The exceptional intellects don't want to get near making license plates. It is too boring for their creative and hard to focus minds - it takes something really cool to make them discipline themselves to think through a problem.
All I ask from my manager: (Score:5, Insightful)
How To Respond to 'Touchy-Feely' Games @ work? (Score:2)
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?
Re:How To Respond to 'Touchy-Feely' Games @ work? (Score:2)
Re:How To Respond to 'Touchy-Feely' Games @ work? (Score:3, Funny)
>
>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!"
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
Re:All I ask from my manager: (Score:3, Funny)
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)
Stick THAT in your MBA PHB pipe and smoke it, Mr.!
Not that I'm bitter =]
Training and Education? (Score:2, Insightful)
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?
Re:Training and Education? (Score:2)
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).
More like "Think They're Einsteins" (Score:4, Interesting)
Re:More like "Think They're Einsteins" (Score:2)
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!
Re:More like "Think They're Einsteins" (Score:2, Funny)
For more information, refer to the "Not Invented Here" anti-pattern. I am a long-time sufferer.
The Golden Rule of Management (Score:2)
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)
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.
Re:Just because you _can_ doesn't mean you _wanna_ (Score:2)
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.
Re:Just because you _can_ doesn't mean you _wanna_ (Score:2)
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.
And that's a good point, but not one that anybody except a mind-reader might have taken from your previous post.
Re:Just because you _can_ doesn't mean you _wanna_ (Score:2)
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'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-g
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.
Re:What about reverse? (Score:2)
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".
Salesmen are only motivated by money? (Score:2)
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)
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
Pukeola! (Score:2)
Gross generalizations (Score:2)
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)
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.
My personal experience & opinions (Score:2, Insightful)
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!
Re:Those who read it area already clued in (Score:2)
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.
Comments .... (Score:2)
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)
In a similar vein, though much more concise (and free!):
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
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.
Re:I'm no Einstein... but most managers suck. (Score:3, Interesting)
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.
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
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?
Re:I know a great way to manage "prima dona"s (Score:2, Interesting)
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.
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.
Mutual Respect is Needed (Score:2, Insightful)
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
When I run the world, things will be different
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.
Happiness==not being treated like company property (Score:2, Insightful)
GJC
Holier Than Thou.... (Score:2)
Re:What tech workers want? (Score:3, Insightful)
Re:What tech workers want? (Score:2)
take the job. Skills and talents determine
the perks you can demand.
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.
Re:What tech workers want? (Score:2, Funny)
Maybe it's me but I consider "powerful development and test machines" to be toys.
Re:Disgusting arrogance (Score:2, Insightful)
It's like karma-whoring on
Re:Disgusting arrogance (Score:2)
can *read*.
Re:nerf guns. (Score:2)
it in reality. I have always suspected it was a
creation of the ooh-aah gawking tech press during
the internet stock market bubble.
Is that what it's like in your neck of the woods,
or is it just what you've read about in Wired?
Most of the intelligent people I know are very
interested in accomplishing things, and tend not
to appreciate nerf arrows any more than sales
meetings. They usually don't kick it out until
they are stuck or wiped out or pissed off.
Re:Try to get your PHB to read this (Score:3, Funny)
My boss, for instance, really believes that he is "solving the problems when others don't understand the question." In reality, he is often the problem that must be solved by his subordinates. He would never believe that he is not part of the "engine of change." He's really more like the "wheel chocks of ignorance."
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
Re:How to motivate AI Al. (Score:2, Funny)
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.
Re:Keep tech workers happy?! Not in this job marke (Score:2)
The fact of the matter is that people feel betrayed when a company behaves like this, and that feeling will manifest itself as a high turnover rate some time in the future.
being smart == better employee! (Score:2)
All a corporate employer should care about is whether employing you will maximize shareholder value. And it is very clear that employing and successfully managing very smart people (Einsteins) has the potential to do this.
In a corporate environment, stupid people are a lot less likely to do smart, money-making things. Making money for the company maximizes shareholder value. As a (relatively) smart person, I want my manager to be able to manage smart people. That doesn't mean that my manager has to be particularly smart, but it does mean that he might need to read this book.It doesn't hurt if my manager is "a kind and caring" instead of being a "selfish bastard", but only because being a bastard tends to lead to disgruntled employees, and unhappy employees do not maximize shareholder value.