Slashdot Mirror
Best Way to Manage Geeks?
drummerboy195 writes to tell us that he recently read a 1999 interview with Eric Schmidt, then CEO of Novell, and wondered how applicable the information was today. How much have things changed since the dot com bust in terms of management? What other good and bad techniques have Slashdotters seen evolve from both supervisory and supervised positions?
I've noticed a lot of managers trying to be super friendly and sugar coating everything they say.
just a tip..most geeks are smart and see through this.
be honest.
if I fuck up, tell me. don't make it sound like you're passing the buck from upper management, or pretend you're not mad.
I can't take any of my managers even half seriously because everything that comes out of their mouth is "corporate happy HR department" speak.
I want explicit instructions for what you want me to do. If I didn't do something it's because you didn't ask me to.
that's my 2 bits anyway.
You can't treat an IT geek the same way you treat a marketing guy. They respond to different things. The geek wants reassurances that he's doing a good job all of the time, especially when things are going smoothly. A marketing guy wants to be adequately rewarded for the big numbers.
I don't respond to AC's.
This doesn't apply to just managing geeks, but that is the environment I work in:
1) Too many meetings. Most employees don't like meetings, at least most employees that are productive. While some meetings are necessary, it's probably way less than you think. If your entire group works in the same cube farm, a staff meeting each week (or worse, twice a week) is too much. If you sit back and evaluate it, you'll notice that very little worthwhile gets talked about because people will find eachother and talk about what they need regardless of a meeting. Also geeks are usually good with e-mail, and so can keep eachother up to date even if they don't meet face to face. Excess meetings not only drain productivity by taking up time, they also drain the will of employees to work.
2) Trying to be a friend, or head tech, rather than manager. On campus we love to make managers by promoting the most senior tech person. This rarely goes well. A manager needs to manage. That means your job is to deal with other groups, clients, bosses, etc and find out what they need and keep them happy, and deal with your group and make them do their work and keep them happy. Basically, you play politics. You need to be the buffer so that your group gets to do their work, but everyone else is happy about the feedback they get. If you are sitting around working on tech stuff, you aren't doing your job probably. Also you need to be willing to drop the hammer on bad employees. That doesn't mean being a jerk, but it means if someone legitmately isn't doing their part to work with them until they do, or if necessary replace them with someone who will.
Those are the biggest problems I see. Managers who try to get their staff involved in all the politics. So then you have a bunch of pissed off tech people sitting through lots of meetings that they don't need to be at, being involved in silly games they shouldn't be involved in. Also bad employees are just allowed to stay around working ineffectually, because the managers don't want to be mean and come down on them.
Your staff needs to be the ones fixing the servers, you need to be the one meeting the the finance department to explain why the money needs to be spent fixing the servers, and the boss to explain why the servers are down in the first place.
One might expect a somewhat "biased" result asking for the best management principles from geeks... who are spending their time reading slashdot!
PJRC: Electronic Projects, 8051 Microcontroller Tools
Nerds like to work weird hours. We like to stay up till 2am or later because we are on a roll programming and don't want to quit. Which also means that we don't feel like rolling out of bed till about noon. So let us work from 1p-9p and we'll be happy and productive. But if you start cracking down on the 8:30am policy and even so much as mention penalties for coming in late, guess what? Yep, we'll be on the phone with our headhunter at lunchtime. We'll straighten our act up for about a month. Why a month? Cause that's how long it takes to secure another job (always with higher pay).
In my case I did this for 2 jobs. I didn't have to for the first one because my boss was uber-cool. But now I realize that if you want to look like a professional you've got to fit into the corporate mold. So I go to bed around midnight whether my brain is ready to or not. My trick? Jim Beam Black!!
Oh also, if your nerdy employee pulls a few 12 hour days because he's in the groove, don't just say, "Hey try not to work too late tonight, k?" Try something he will really appreciate like, "Hey, you can come in at noon tomorrow if you want to, alright?" You will be loved.
From TFA:
"This is a golden era for geeks"
He wasn't kidding. It sure went downhill fast after 1999. His other opening lines, "we have permanently entered a new economy", and "Novell has again come to be seen as a worthy competitor to Microsoft", are not exactly prophetic (quick check on Yahoo stocks shows Novell's price has ended up pretty much where it was five years ago).
Other disagreements: "most of them would probably turn out to be terrible managers". I strongly disagree. Of the 5 managers I interact with weekly, the 3 who have running code in our systems (i.e., they're promoted developers) dress the worst and manage the best: they tell me my deadlines and my priorities, they ask me what support I need to write code, and they leave me the fuck alone. The 2 who don't have code running on our servers, who were first hired as managers, like to reorganize our hierarchy, introduce burdensome reporting requirements so the execs have more Social Science Numbers to look at, and want to transform our nice offices with *real* *doors* into a miserable cubefarm. I say, promote geeks! Even if they don't want it! I totally agree when he says "you can tell them what to do, but you can't tell them how to do it" (this is far from an original thought of his), but unless your managers are geeks, this approach will leave them feeling powerless and threatened. Managers meddle, it's what they're trained for.
If you want an insightful, thorough, and applicable discussion of all these ideas, as well as many more, some of them *original*, read the Scrum Handbook.
Normal geeks are intrinsically motivated. They do the job for the joy of doing the job. They are the kind of person who will be up 'til 2 in the morning working on a project. The best way to manage that kind of person is to make sure they are on the right track and keep out of their way. Open source development is a good model for managing geeks. Top down micromanagement is the wrong way to manage geeks.
Geek gods, on the other hand, can be hard to manage. They tend to treat everyone else with contempt. Keeping them on track is quite difficult because they won't take direction, even when they're totally wrong. They won't believe you because you're dumber than them. They're a lot like star atheletes. For them, you need good coaching skills. Read a few biographies of great coaches. You'll get the idea.
but like other prescriptions, it makes it sound like it's straightforward, and it's not, because human beings do not fall into neat categories. Just finding out who's good and contributing can itself be a nearly impossible task once the code bases become too large to be understood by any one person.
The problem is magnified in a large organization such as Novell. I would like to see senior staff shuffled between managerial and hands-on technical roles from one project to the next, provided they're willing and not too antisocial. That rarely happens, but if it did, it would at least prevent some of the rampant Dilbertism found at the management at many large technology companies (including Microsoft, if you believe some of the comments posted on the mini-MSFT blog).
People are always saying managing geeks is like herding cats. But no one ever talks about how to herd cats. Chasing them with dogs just makes them scatter, and actually puts the dogs at risk. The answer is chasing mice. Give geeks something to do that's really geeky. Like cats, you have to be sure they're fed and get their weird brand of attention and petting. But the only way to get them all moving in one direction, working together, is to put them in there with some really juicy mice. Then they'll happily stalk and pounce, living the chase, proudly returning with the trophy for the adulation of their keeper.
--
make install -not war
1. Keep the fridge stocked with Mountain Dew and Bawls. ...you know, from the hammock district!
2. Allow them to mod their PC cases with leds and overclocked - spreadsheet busting - cpus.
3. Mandatory slashdot breaks.
4. And, of course, hammocks!
Religion for nerds. Stuff that really matters
First, ignore all advice from computer science undergrads with no experience who make an inspid and glib list of weakly argued points and pretend to sound like they know what they are talking about. For whatever reason, that is very common on slashdot.
Then realize that the question "How do you manage geeks?" presupposes a lot of bullshit that does not apply in real life. If you are a manager and you have a question like that floating around in your head, you probably should not be managing.
The geek wants reassurances that he's doing a good job all of the time, especially when things are going smoothly.
I sure as hell don't. I'm not a needy child who needs constant reassurance. Give me work that mentally stimulating and challenging and compensate me appropriately and I'll be happy.
-everphilski-
* nerds are often disorganized or have a twisted skein of attention-deficit issues
* nerds love assessing, classifying, and defining the objects in their world
* nerds crave actionable items and roll their eyes at "mission statements" and lofty management patois
* nerds like things that work with technology-agnostic and lofi tools
* nerds like frameworks but tend to ignore rules
* nerds are unusually open to change (if it can be demonstrated to work better than what they're currently using)
* nerds like fixing things on their own terms
* nerds have too many projects and lots and lots of stuff
"It was a summer's tale: Just a boy, his Linux, and a head full of dreams..."
The solution to the problem you describe is simple: you need to be fired. If you are playing games all the time and not getting your work done, the then you need to cure the problem (you have no self control), not he symptom (you play games).
If a good employee wants to play CS during his lunch hour, I say why not. If he reads /. once in a while but still gets all his work done, let him have it. If it takes a little stress off and isn't harming things, then what is the problem?
It's self control. If an employee keeps stealing stuff, what do you do? Nail everything down so he can't take it, or have him arrested?
Locking things down unnecessarily (obviously, some stuff must be) because of one bad egg will only annoy the other employees and decrease their productivity because you don't "trust" them. I'm not saying let them roam free, but they don't have to be in a cage either. Zoos have animals trapped, but the enclosures are designed not to seem to bad to the animals. Same kind of thing for employees (note: sorry about the zoo comparison, but it was a easy way to make the point).
Comment forecast: Bits of genius surrounded by a sea of mediocrity.
Don't be a dick. A lot of them are very smart people and if you offend them they'll find ways to slack off and get back at you. They may not ruin your career but a word here and there can do you no good at all.
Be honest. Most geeks would perfer if you told them what was going on. Don't lie to them unless you 100% have to.
Listen to them. If they say "we need a week" then go "including delays and testing?". If they say yes then give them 8 days. If they say no then add an extra couple of days (for a short project) or weeks/months for a long project. If the shits going to hit the fan because of a too short deadline you get it in the neck as well as them.
Remember they're people. If you're getting a dirnk offer to get them one, same goes for if you're making a run some where. Act like you're one of them because that way you're a friend and not "the boss". Make sure they know when you say something it really must be done (when to put your foot down, don't do it always).
And last but not least. Get a decent tasting coffee and some biscuits. A good drink gets you going in the morning, biscuits go nice with it and if you're hungry a couple will hold you till lunch. A hungry worker is one thinking of lunch, so his mind is else where.
I like muppets.
I've been a programmer, then a manager, then a programmer again (by choice if it matters)
I tend to think that meetings are boring and unproductive. Maybe I've been to the wrong meetings.
I like "management by walking around" and "micro meetings". The big meetings still have a function but I try to only do them when management by walking around and micro meetings aren't enough.
Management by walking around is when the manager or project manager walks around and informally talks to people. If there is a problem it can be taken care of then. This informal atmosphere also encourages people to go talk to the manager directly if there is a problem. I'm social so many of the informal meetings aren't about work at all. I thought about limiting those meetings to limit the amount of time that I'm "wasting" but in the end I kept doing them for two reasons 1) they help keeping an informal feeling in your relation and 2) sometimes people have somethign on their mind and they don't take the step to come talking to you but if you are shooting the breeze they might steer the discussion in that direction. Maybe this made me feel like a PHB every once in a while that trapped you in your office and you can't get out of it. I hope not. I certainly kept that in mind to try to avoid it.
Micro meetings are when one particular issue needs to be discussed and resolved. In those situations I grab all the people that needs to be in that meeting and we usually have a short stand up meeting in someones cubicle or office. Once a decision has been made someone is made responsible for writing an Email and sending it out to all that should be informed.
If I have to have a meeting with the entire group I try to keep it on focus as much as possible. One little golden rule I have is to spawn off a task once a subject has been discussed for a few minutes and there only are two or three people discussing. They can then have something similar to a micro meeting later and suggest a solution. The purpose is to not either force a decision before we understand the problem while also not keeping the entire group tied up, drifting away, bored to tears.
I also tend to have a task or issue system where tasks can get assigned, worked on, reviewed and approved. If a task is large or important enough that I want to track the status then I make sure it gets entered in that system. An issue system may seem like a hassle but it helps you keep your shit together even without those large 1 hour meetings with the entire group.
The biggest advantage, and also disadvantage, with large status report meetings are that you'll embarass people into finishing their tasks. After reporting no progress on a task for 4 weeks a person dreads the fifth time and finishes it. But it also means that people fudge their numbers and make inaccurate reports. But that also means that people might be feeling like shit. In the end, I think the disadvantages of those meetings are bigger than the advantages.
Geeks don't usually need motivation. They only need direction. And the direction should preferably not be in the form of orders. If a geek believes that he had a choice then he'll be much happier. Now, this is of course true for any person.
What you just said is that employees who take over those functions are more valuable than employees who don't.
Well DUH!!! But the REAL problem is that the MANAGER is not effective.
Don't blame the employee for putting in 8 productive hours a day
As can bad managers.
But don't confuse bad management with bad employees.
He doesn't get paid if he doesn't get the account. You do.
Part of the problem here is that there are enough blind managers in existence to hire your useless ass.
Unless you work entirely in a vacuum, you're inevitably going to cause more problems than you fix with your "uber-code."
Not toeing the party line is fine. Being an arrogant asshole is unacceptable and unprofessional, no matter what your technical skills are like.
"People who do stupid things with hazardous materials often die." -- Jim Davidson on alt.folklore.urban
"3. No second guessing. If you hire a guy because he is an expert on ABC, and he gives you his best educated guess on an issue about ABC, give him the benefit of the doubt. Don't go asking a wannabe geek that read ABC for Dummies for his opinion. And please, don't go back to the expert to tell him "so and so says you are wrong." It is stupid."
This is true, but if a valid concern about his opinion comes up, he should be able to defend it. That's why he's an expert in the first place, but it also gives him a chance to fix mistakes before making the company dependent on them.
A lot of it is in approach. You can usually legitimately get away with something like; "Someone suggested (x) as an alternative to your plan. I'm curious if you have any thoughts on the idea." If need be, make sure they understand that their idea is still the official plan, and you're looking for clarification rather than a defence.
"People who do stupid things with hazardous materials often die." -- Jim Davidson on alt.folklore.urban
The penal problem jokes aren't realy saying geeks cannot get a date rather it is saying they are preocupied to the extent it apears this way. I remeber a study that basicaly said women prefere geeks and there was some unexplainable trend werre women were finding geeks more attractive then the original jock type sterio types.
I know many geeks who would rather play video games or work rather then go out on a date with someone. I have been guilty of it myself a couple of times. I even took a laptop along on a date once so i could periodicaly monitor a problematic server I was trouble shooting. I bet given a sixpack and a willing woman, they could figure out what to do. It just seems they aren't concerned with doing it like some other in the world are.
As for women? It doesn't really matter. Even if they are "but ugly", they can goto a bar and act drunk and end up leaving with someone willing to give it to them. It is more of a matter of them being able to get the people they want to get, more then being able to get anywere. I know a couple of girls who probably havn't paid for thier own drinks in over ten years. They go home with very few people but have the chance every time they go out. You would be surprised in how unattractive they look and the responce they get in a crowded club. Even lesbians pick up on them (wich one accepted but isn't commited to the idea).
You can't always just willy nilly start to experiment on your own, or you screw other teams up.
I think what the GP post was talking about in re: people "who don't do anything that they aren't told to do" wasn't people like you who are guarded about overexperimenting. I know a number of IT and engineering folks who do no more than what was precisely described and don't try to proactively make anything better. That's what the problem is - marketing says "we need it to do X," and the engineer comes back at the (not unreasonable) deadline and says "it does X now, but it doesn't scale, doesn't work outside of the scope that was precisely in the spec and it doesn't do anything else that you might reasonably expect it to. If that's not OK, you should resubmit it through our project management process and be more specific."
For example, when I was a product manager at an ISP I gave engineering a spec on how our DSL offering was supposed to link in with our satellite networks. Engineering gave an estimate on infrastructure costs based on what turned out to be wildly underpowered routers, which then went into the business case. When we were implementing the product ad push came to shove they came back and said, "oh, you need something else that costs 3x the original estimate" and hosed our business and pricing model. When I asked them why they didn't think about what would realistically be required to provide the service - which I didn't know how to calculate but they could have - they just said, "well that's not our job to go beyond what was explicity written in your case."
Who knows? Maybe that's the way it has to work ... but marketing and sales people are expected to take initiative and go beyond the explicit instructions they receive. They are expected to anticipate not just what the customer specifically asked for, but what they actually want as well. Of course sometimes this is a recipe for disaster, but the point is that they are expected to be holistic in our approach and rightly or wrongly (maybe wrongly), they expect others to do the same. Yes, yes, of course this principle can be abused. I'm not talking about being a mind reader. I am, though, talking about the difference between doing only what is explicity spelled out versus applying common sense and initiative to your job. And that, I think, is what the GP post was saying was the characteristic of someone they didn't want working in their organization.
"95% of all Slashdot
Bar non - in every situation I have ever worked, former hardcore geeks are _always_ the best managers (both in terms of being pleasant to work for, and in terms of total group output.) I think the reason for this is simple- It takes one geek to truly understand 'the drive-' that is, that most programmers worth their shit work as much for the fun and challenge as they do they pay. Non-techie types can cognatively understand this- but they can never quite fully empathize with why sed. engineer is so thrilled that X solution is so Y Brilliantly efficiant... There is nothing that will turn even the best engineer 'off' faster than being micromanaged by a power-drunk fool who he feels superior too. Granted - on the flip side, you can't let the wolves manage the hen-house - geeks tend to be very band business people... most of us are perfectly happy perfecting, playing and tinkering until the cows home... if you let a geek just always do what he feels like, the chance that he will feel like doing the exact sequence of things necessary to create a sellable product is slim to none... Therefore, the best geek managers take on the roll of shepherds... Understand, commiserate, and encourage the geek to explore the stuff that intrinsically motivates them, while occasionally pointing out that if they don't do X-Y-Z before Close of Business Friday, the company can't make the cash necessary to support their 'play time'.
Seriously, though. You'll get a million and one answers to the question of how to best manage geeks and most of them won't really matter, because they work well for some people and organizations, and don't work well for others. The trick to managing geeks or anyone else well is to become not just a manager of time and resources, but a leader. There are plenty of ways to go about learning leadership, but the important thing is that leaders recognize that humans are the most valuable asset in any organization. All the MS Project charts and spiffy time-management tools and HR policies in the world don't matter if you don't lead your people.
That doesn't mean you have to become Patton. Some of the best leaders I've encountered were quiet, calm, and almost always in the background. I've also come across great leaders who were always talking, always on the go, and always visible. Leaders can't all be cut from the same mold, and they can be hard to find. Taking raw leadership capability and nurturing it is difficult, which is why most companies shy away from it and focus on management (a concept that was spawned in the early days of the Industrial Revolution, when everyone worked on factory floors) instead. The result: Most companies have managers who are ill-prepared to lead.
Read the EFF's Fair Use FAQ
I'll never work in the IT field again; it has been relegated to a hobby. The company I worked for will not be named here, there's no reason to trash them by name, no matter how much they pissed me off. Still, I learned a few valuable lessons while I was there. This kinda reads as a rule sheet for the manager to read before hiring me, or maybe I'm just ranting, but these things need to be said...
1. I started from a technologically low point in the ladder of IT as it stands now. As the employer, you knew I had never worked as a sysadmin, that Linux was my OS of choice *at home*, and that I do not program in the languages you used at your business. Don't expect me to be able to move from that low point to a seasoned expert on only four months. It just does not work that way.
2. Don't tell me I'm not doing enough, or I'm ignoring this or that part of my job, if I'm already buried in projects for your clients. I'm a geek, not a fucking magician. If I tell you I'm busy, it means I'm busy working on your clients' machines. Furthermore, if you as the manager are not a tech, then let me believe it - don't try to do my job for me!!
3. Don't try to make me feel intimiated or inferior to you just because you carry the title of manager. I don't care if you worked for Company X and they improved while you were there; you are NOT working for Company X now, and we are not the same people you dealt with there.
4. Don't bitch at me if I open a [perhaps previously iconified] window and head for Slashdot or IRC or even browse the web in general for a few seconds or even a few minutes, when I'm working on some client's machine at the same time.
5. Don't create mandatory meetings and expect me to willingly attend them, especially if they're held when I would normally be asleep. If you have something to say, you can always email it to me, or even drop by later and give me a quick heads'-up on those things I need to be involved in. If it doesn't relate to my job, I generally don't want to hear about it! I don't care how much money the company made, or even if you start to lose customers, unless I'm responsible or I'll be directly affected by it.
6. If I use the staff-wide mailing list to lodge a public complaint, don't tell me not to. I wouldn't have used that method if it weren't appropriate to do so. (In this case, I was injured by someone else's carelessness, and now I have a large, permanent scar on my leg to show for it).
7. DO NOT, UNDER ANY CIRCUMSTANCES, EVER TELL ME TO LIE TO A CLIENT. Is that clear? I value my integrity, and it makes the company look *really* bad when some client calls you up, asks what's going on, and then calls your bluff. You know, clients actually DO read the literature your company produces, and they often remember those little promises and guarantees you make in said literature.
Better yet, try not putting me in that position to begin with - Fix the problem before it occurs! (yes, this problem was fixable).
8. Don't expect me to support a program/user environment, if the only person who can actually solve the problem the client is having, is the author of said program. Believe it or not, clients actually do call in asking why this or that function can't be altered in some certain way, or asking when the next release will be out. Repeatedly telling the client that I can't help them just pisses them off and makes ME as the individual tech look bad.
9. Related to #8; If the author of said program does not feel he needs to make himself available to his users, fine. Send him home and let him do his work remotely. If you won't do that, then don't expect me to pretend he isn't here wh
Karma: I don't care too much, but it's 0.0% (mostly due to lack of interest)
This is touted by so many as a desired "right" of programmers / IT staff. Hogwash. In a business atmosphere you should look presentable. There's no reason any employee in an office environment should be permitted to wear cargo pants, a ripped Marilyn Manson t-shirt and a bandana. Employees should bathe regularly and look presentable enough for clients, business partners, marketting staff or anyone from outside the company should they visit the production area.
I'm not advocating shirts and ties for all employees by any stretch, but what's wrong with a nice pair of dockers and a golf shirt? It's comfortable, it breathes, it's very low maintainance (you can sleep in dockers and wake up presentable) and it's not an expensive outfit to put together.
As for long hours; I'm currently in sales. I come from an IT background (networks primarily). I work long hours if required to meet my targets; I'm no stranger to 84+ hour weeks. You have stress, I have stress. You have deadlines, I have deadlines. You have a multitute of managers, so do I. I, however, come in on schedule, leave no earlier than the end of my shift, dress professionally every single day, do not have access to video games, do not have an enclosed office but I'm here every day doing my job rather than complaining about it.
All this talk in this thread about "special treatment" for sales staff, management, etc. yet you want programmers to make their own hours, dress like slobs and play video games whenever they feel like it? Hello? If you want to be treated (and compensated) like a professional - stop acting like spolied children! Your job can be outsourced to $foreign_country for less than half the cost of paying and providing benefeits to you. Give them a reason to keep you, not an excuse to get rid of you.
BD Phone Home!
Shameless plug. Like you weren't expecting it.