Slashdot Mirror
How to Manage Geeks?
Ratatosk writes "The paper Fast Company, which focus on work related things, has a "geek week" with articles like the tutorial "How to Manage Geeks".
Advices are: Get to know your geek community, the best
judges of geeks are other geeks and create new ways to promote your
geeks. " This isn't as good as the age old Managers Guide
To Geeks (does anyone have a URL handy?) which I tried to force
several of my previous boss's to read. But this is for the PHBs I
guess. I guess we're who they're talking about, does this sound
right to you?
There are no PHBs. There is no subculture of "geeks" who fit into any one mold, no matter how vague and general you make it. This kind of generalization seems to be getting really rampant on Slashdot and similar forums. The world (and the people who populate it) might look that way if you're still in college or just graduated, but trust me, those sorts of generalizations end up hurting you a lot more than they help, when people you thought you had figured out turn out to be a lot different from what you expected. The terms "PHB" and "geek" have become like the term "FUD" around here- overused to the point of meaninglessness. :(
Gosh, Slashdot readers are so naive and one sided. It's "workers" (geeks) vs "bosses" (management)
I don't know what company you people are working for, maybe it's just the Europeans? But in Silicon Valley, and the DC area, there are two primary types of geeks:
1) consultant geeks
2) company oriented geeks
#1 are freelancers, run their own small firm of other geeks, do web projects for hire.
#2 are geeks in startups.
Geeks in startups get:
1) a large starting salary ($60k minimum)
2) signing bonus
3) paid relocation
4) stock options or stock
5) and the ability to become a manager.
Most of the time, the startup hires about 5-10 people, and has about 15 total. Then, during the next hiring wave after more funding is secured, the geeks with experience and who own their software modules (just like maintainers in open-source), get to manage the new people who come in and show them the ways.
Have any of you Microsoft bashes ever personally met anyone who works at MS? I have, and they are just as dedicated geeks as you are. Most MS project managers are highly technical coders. Alot of them sit on IETF and W3C committees.
If you are not working for a company like this, YOU ARE A MORON WHO IS SELLING HIMSELF SHORT.
My own company just closed a round of hiring and we couldn't pay anyone less than $70k.
One of my good friends who never went to college and started scripting two years ago got $80k plus $6k signing bonus. My girlfriend makes $75k doing Visual Basic programming.
The job market is so thin nowadays. I am sick of reading about geeks whining. If you really think your worth hot shit, quit your job and get another one.
My other experience is, *geeks need management*
Geeks have large egos, and when you put a few of them together, invariably there is friction. Secondly, geeks spend a lot of time fucking off. Browsing Slashdot everyday from work, working on side projects that no one asked them too. Geeks usually don't have great organization and time management skills I have found, including my self personally.
Yes, there are PHBs, but you narrow minded people think anyone who is not a coder is somehow a skillless dumb-ass, and that a company with nothing but geeks would be a paradise. In my experience, without business development people (and I'm not one), most geek businesses would stall. (and I am a geek)
Case in point: ID Software and Quake. During Quake1 development, they spent too much time fucking off, playing the game, researching side projects they through were cool, and not completing the game. They finally had to hire management to come in and organize the office culture.
Ion Storm appears to be in the same position, with very bad management. Netscape also fucked itself with poor management, flip flopping on projects, development plans, etc.
Geeks think only technology matters, when in fact, the most valuable asset in a company is its people and how they are organized. Effective organization and focus makes all the difference between being market leader, or market loser.
How many of you so-called geeks have ever picked up and read a book on economics, marketing, or management?
I hope I never hire someone who is so super-specialized in one thing (technology), that they don't have the hunger for learning or open-mind to consider other things.
If I did hire someone, and they espoused views like "management isn't needed, marketing is bullshit, spreadsheets is bullshit, MBA's aren't any use. Only code and technology matters, oh, and my paycheck" I can guarantee you they would stay a n assembly line coder.
It's time to consider this essential fact: There are lots of people in the world who don't build things, but yet whose job is totally critical to your lifestyle, and without whom, you would starve.
PHBs included.
Just give us our task and get out of our way. Geek work isn't like grunt work. You can't count the number of lines of code we write or amount of CPU time we log and make any meaningful judgement from that. Most geek work is creative in nature and can't just be turned on and off with output rigidly measured like a water faucet. We may get a lot done on some days. Or we may zone for a week out staring at a block of code and produce nothing. When I code for a project, I tend to create all the functions (tools) I think I will need. There's nothing to show the boss at this time. The GUI comes last. At the very end, all the tools are all linked together to complete the project and it appears (to the boss) that a lot of work is suddenly completed in rapid manner (whilst he had chastized you earlier for 'dragging your feet' and not 'producing anything meaningful'). And looking over our shoulders all the time, or being interrupted by phone calls only slows us down. What is very important and what management doesn't seem to 'get' is that geek work requires uninterrupted concentration; but not only that, geeks need the knowledge, in advance, that they will be allowed to work undisturbed for a known period of time. After all, if the boss asks you to handle the support phone, you're not going to get much work done. Though it may not ring often or even ring at all, just knowing that it might ring and saddle you with 1-60 minutes of unrelated work at any time, or 5-minutes troubleshoots every 45 minutes, randomly throughout the day causes you enough anxiety to hinder your work ability. Just give us the requirements and leave us be. We'll do fine. Really.
[it's probably a bad sign when you start out thinking that your comment will be poorly organized, but I'll give it a try anyway. sPh]
I am not sure I buy the oft-heard statement that geeks/nerds/engineers "lack social skills". First, we have all heard the stories about how geeks can't meet members of the opposite (or desired sex), can't get dates, spend their Friday nights wiping the zit cream off their 19" monitors, and so on. (And to avoid being too elliptical, we are primarily speaking of males when we say these things). But by age 25 or so most geeks who desire to find long-term relationships with the opposite sex, have done so or are in a position to do so. The qualities which are less appealing at age 17 start to look better around 25 (intelligence, persistance, loyalty, oddball humour, and not least a job that pays big $$$). So things start to even out there, and continue evening out through the 30's.
Next, let's take a detour though (syndicated columnist) Bob Greene's Student Council theory of government. Briefly (and there is no way I can do the deep power of Mr. Greene's insightful writing justice here), Greene states that the people running our government (and large institutions) are basically the people who ran for student council president in 8th grade. Much as I normally dislike Bob, I think he is on the money here. And those people have a certain _set_ of social skills, which are commonly thought of in modern western society as "correct" or "good" social skills. These include schmoozing, being at ease in groups of strangers, effortless dissembling (or outright lying) to gain desired goals, disdain for those who can't or won't dissemble, and others I am sure you can add.
Now it's true that the average geek doesn't have these "correct" social skills. And therefore, those in power view (or would prefer that the world view) geeks as "being without social skills". But I would argue that this isn't necessarily the case. It is just possible that geeks have, and are developing, a _different_ set of social skills that include honesty, trustworthiness, loyalty, and plain speaking.
Further, I would argue that the currently dominant group (the "student council") feel threatened by people (geeks or others) who act this way consistently. Thus the need to attack and marginalize "geeks with no social skills". But it ain't necessarily so.
Finally, and along the same lines, I would think a little deeper about Schmidt's statements concerning geeks always trying to tell the truth. I think what makes politicians, standard model senior managers, and the like nervous about geeks is the style of discussion when alternatives/choices involving hard technical choices are present. A typical engineer, when asked to give an opinion on a topic, will respond in the fashion taught by the military: (1) facts (2) observations (3) opinion (4) recommendation. In that order.
So when asked by PHB, "What Internet technology should we use?", the geek replies: "foobar is fast but expensive. jarjar is cheap but unreliable [facts]. Most companies our size who use jarjar are happy with the sevice, although their super geeks complain [observation]. Based on my experience I don't like jarjar's business practices [opinion]. I recommend we purchase a 12-month, terminable contract from jarjar [recommendation]."
However, manager-types think that this is an evasive answer, while geeks types think it is a complete, honest answer which gives the decision maker everything he needs. Everyone walks away unhappy: the manager thinks he can't get good advice, the geek either thinks his advice is ignored or that decisions "never get made". Both sides think the other is unable to communicate.
Well, I ment to say more but that is probably enough for now. I will write more if there is any demand.
sPh
First a little history: I've been in computers (hardware and software) since '78 but that doesn't make me an expert.
1) Give us an evironment where we are allow to think. Don't distract us with time sheets (on a daily basis) and micro-management. Many of us wouldn't be able to put in less than 40 if we tried. And those that do will have their end customer notifying management shortly. And if we work more hours reimburse us for our time (so I guess time sheets are need).
2) Don't decide which tools we have to use. Power Point may be good for marketing but is next to useless for engineering diagrams. If you need to limit the tools because of support issues then ask us for our preferences.
3) Acknowledge our good deeds, let us know about our bad ones. We can't fix something if we don't know it's broken and Marketing didn't fix the technical problems by esculating (and annoying us) so stop giving them our credit!
4) When we are working on a problem keep out of our hair. Hourly conference calls only slow us down and keep us from fixing the problems. Also it annoys us to no end to sit for 55 minutes so we can be rushed in giving our presentation in 5 minutes!
5) When a technical person gives a solution don't allow management types to circumvent it with a political solution. It will not fix technical problems.
6) Keep the politics out of our hair, it is a distraction we don't need.
7) Pay us fairly and give us incentive plans. It's nice that Marketing and Sales have incentive plans but they were not able to make the sale without our help. Also if we see a job were we have the same conditions but we're payed more we will leave (we are not stupid!).
8) Keep our work interesting, we recognize dead ends and we'll leave even if you pay us more.
9) Support us with managers who understand us and do not resent us.
10) Group us together with other techies (of like work). We often need to bounce ideas off other techies to verify that we are on the right track. Breaking up the hardware engineers to work directly with the software engineers (or vice versa) may sound like a good idea but makes it difficult to perform sound board discussions. Or worse don't put the engineers with marketing. 'Suits' (Marketing/Sales) make us nervous!
11) Give us the tools and training we need to keep current. Then allow us to use both. I've seen enough companies train their people only to have them leave when they box them into the same job. We need avenues of advancement just like management but don't expect us to become management.
Neil Cherry - Linux Smart Homes For Dummies
(1) Doesn't mean that I want to write videogames for a living. It just means I want something that I find challenging. Job#1 I was doing digital certificates, Job#2 was XML/Swing, Job#3 is natural language. Fun fun!
(2) Could mean money, but not at the expense of #1. More often it means ego strokes. I recently got a magazine article published, and my boss sent copies to all the higher-ups in the company, something I didn't expect. Back at company#1 I was surprised when the president mentioned me by name in his yearly state-of-the-company address. Stuff like that, combined with cool stuff to work on, will keep me alot happier than paying me double and telling me to work on boring shit.
(3) means I'm one of those arrogant assholes who thinks that the rules don't apply to him. I admit it. I'm a geek, I'm a hacker, I'm a different breed than every employee you've had for the past 20 years, so don't push your dress codes and your administrative rules down my throat, because they'll stifle what I can do for you. White shirt and tie everyday? No thank you. No food in my cube? Forget it. I will do my 80+ hour workweeks for you, you don't even have to pay me hourly or overtime, but as a result of that I will take off my shoes and walk around in my socks, I will have my radio in my cube, and a box of Poptarts in my desk. If some manager somewhere thinks that the tradeoff isn't adequate, that's his choice, but he's an idiot.
For the record, I left job#1 because of item#1 (they killed my project and told me no more Java). I left job#2 because of #2 (a brief consulting stint where I was a hired whore), and I'm currently at job#3 where they just put me on their "emerging technologies team" (covering #1) boosted my salary and let me publish some articles (covering #2), and I'm sitting here in my socks listening to MP3's munching on a poptart (covering #3). :)!
www.HearMySoulSpeak.com
It's not uncommon for the true geeks and hackers to turn down mega-paying jobs in their quest for something more interesting. I've had my calls from Microsoft and IBM, and I'm sure many of the people here have, too. I consulted at a place for what was basically double what I'd been making as a fulltimer - and dropped it after 6 months.
No, it's definitely not simply about paying more.
www.HearMySoulSpeak.com
Ha! This is our most redeeming feature.
It's nice that this guy recognizes that without geeks there would be no technological industries, but he's still stuck in the Dilbert-esque mindset that developers/engineers/artists/etc can do nothing without the "enlightened" leadership of management. Managers without technical backgrounds are not our leaders. They exist to manage resources, schmooze customers, and keep us grounded in fiscal reality, but they have no business making technical decisions. They do not merit higher salaries, nor should they have greater clout than senior developers.
The CEO of Novell isn't successful because he knows how to manage geeks, he is successful because he is one. He knows the technology, therefore he knows how to make clueful decisions reagarding it. The developers respect him for it, so he has legitimate authority. A manager without respect has no real authority, only the authority to sign paychecks.
I'm afraid this article do the opposite of the intentions of its author. Mediocre managers will read it and think "ah, so that's how I control my geeks. Now they will do my bidding!" which is exactly the way to piss us off. Managers should learn humility, learn that respect must be earned, and not try to manipulate us.
All geeks got into computers because of two seperate drives: a need to solve problems and a social need to value logic above personal factors. Thus social skills are not a top priority. Managing geeks requires recognizing the three seperate types of geeks. 'Workers', 'Peoplers' and "Silverbacks'. Every programming community has their own of each. Populations differ by system characteristics.
'Silverbacks' are the rarest. They have worked in computers forever. Geek managers trust them to solve the hardest problems. They absolutely need to feel indispensible and adored, but only geeks should interact with them. Don't even think of moving them into management. Treat their cubicles as the holiest of holies. They are however, the perfect compliment to 'Peoplers' geeks, who should bounce their ideas off of a silverback before commiting resources to them. Don't bother getting silverbacks any training.
'Workers' form the majority of all geek populations. Given a standard toolbox they can solve standard problems. They respond somewhat to cross-training. Occasional training is apreciated. They really should only meet with, be promoted over, or be responsible to fellow geeks. Programming teams are their forte.
'Peoplers' are the only safe geeks to interact with non-geek employees. They need to be in the loop. They actually thrive on being liasons. Often they are not the best programmers. They should be plugged into programming teams on different projects. Their own projects should be small, low-priority and permitted to fail. This keeps them in the geek world. 'Peoplers' can definately become overloaded so they need their programming time and a safe haven. Training has the greatest benefit to these geeks. These people are absolutely essential to the smooth functioning of your company. Don't promote these people into geek manager functions, but treasure them in other ways. But keep them geeks.
So long and thanks for all the fish . . . !!!
It wasn't called the "Managers' Guide to Geeks", but rather, "The Hacker FAQ", and Peter Seebach wrote it. It's for managers, about understanding your hacker :). It's on www.plethora.net/~seebs/faqs/hacker .html and is worth a read if you haven't seen it before.
The geeks control the limits of your business.
... They care about getting credit for their accomplishments.
Haven't heard this phrased quite in this way before - very direct.
Fundamentally, geeks are interested in having an impact.
This is what is hard to explain to some people. There are so many people that are only worried about how much they make. If you're going to be doing something for a significant amount of time, make it something worthwhile to your beliefs.
The rest of the article has more specific ideas, but it seems to me it all comes down to knowing your people and their abilities, and motivating them to do their best work. I do like the idea of small, fast teams, because communication on projects needs to be clear and with fewer people there is less chance of misunderstandings.
But when you look at large projects coordinated with people at geographically diverse locations, you can see large teams can work.
Open communication. Know what you can do and what your team can do, and talk with them. Too many managers talk at people and that is, IMHO, the biggest problem.
Geeks get attached to their tools. They love them in the way a senior manager adores his favorite brand of golf club. Just as in golf, the right tool for one person may not be for another. While corporate standards have their place, micromanaging those standards is often a WOMBAT - a Waste Of Money, Brains, And Time.
A war story, and a lesson:
A few months ago, I worked at a shop which (among other things) tried to mandate the users' choice of mail tool. It foisted a ported Windows application onto a bunch of UNIX users who were comfortable with Emacs, vi, elm, pine, procmail, and all those other goodies we've come to know and love. The theory was that using the ported Windows application would allow us to "interoperate" more effectively.
The funny part, of course, is that none of the NT users in the company seemed to have trouble reading mail from us UNIX-heads, even though us UNIX-heads often tore our hair out at people who sent six separate binary attachments containing little icons for an e-mail consisting of three lines of text. (Or worse, a three-line-long Word document!)
Actually, that's not the funny part. The really funny part is that the UNIX development team was working on the product on which the company's future had been staked. With the stroke of a pen, the management team had managed to alienate the most valuable segment of the company's intellectual capital pool.
I don't work there any more. I work somewhere else. The pay's better here, as is the coffee. And I can read my mail without swapping to disk. Life is good.