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?
The best way to manage geeks? Well, I pretty much treat them like any other employee. Honesty, fair and equitable treatment for everyone while not indulging high maintenance employees at the expense of others. You pay people what they are worth, treat them with respect, challenge them while rewarding success and you will have lower turnover and decreased personnel costs. However, the geeks (typically programmers, but hard to define in science) need to realize that they are part of a team and they are part of a greater whole. Those who need more, will move on to other companies or their own companies and that is not necessarily a bad thing. However, the longer you can hold onto those successful individuals, the more successful your company/organization will be.
Visit Jonesblog and say hello.
In general, Schmidt speaks of his geeks in complimentary terms, while acknowledging their vulnerabilities and shortcomings.
Anyway, I'd have said Doritos, Lightsaber fights and Anime...
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.
They are already being managed on Slashdot. Mod them up, mod them down, call them trolls.
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.
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.
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.
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
I know it's hard, either the CEO is part of the solution or he's the problem. There are several tricks you can use to better manage your CEO:
1. Learn his language. If you can explain your goals in words he is familiar with he will self organise himself to better deliver the support you need. To achieve this, engage him in dialog and take notes on the words he uses. Don't "leverage joint synergies" if he "maximizes differentials" for example. "Maximize those differerntials" right along with him!
2. The best judges of CEO's are secretaries. Talk to his secretary, does he prioritize "eating lunch undisturbed" over say, "saving drowing New Orlean's people"? If he does, drown a few New Orleans people aswell, to break the ice.
3. Look for the natural leader of your CEO. Does he always downsize right after IBM downsizes? Does he diversify when Kodak diversifies? Then IBM is his leader or Kodak is his leader. It's important to determine leadership so you can be forwarned about upcoming wild management swings.
4. Be prepared when the CEO hits the fan. He won't be there forever, keep links with Bob the CFO and Carly the insane Amazon in marketing, you never know when they will become the CEO.
5. Too much management spoils the broth. CEO's don't talk to the customer, they don't talk to the technical people or even read the spec, or have any idea what the product is. So don't let them get too involved with the decisions. Think of them as the team mascot.
Greetings,
.Net.
I manage a small but important team. The guys who report to me are, by the definition of their jobs, highly technical. Whenever something complicated needs to be researched and/or implemented, my guys get to do it, especially if it has to do with the adoption of new technologies.
We had our quarterly review a few weeks ago (it goes both ways; they evaluate me, I evaluate them) and the results were excellent. Here are the overall management techniques I employed with them:
1. Hold everyone in the team, including myself, to the highest
standard.
2. Define what 'highest standard' means as a part of the requirements
specification.
3. Once a decision has been made, by the team, business owners, etc.
there is no arguing. Part of my job is to keep the business guys
from becoming a distraction. The other part is to ensure that
the engineers deliver (1) and (2).
4. Go through a quarterly review with them; divide a sheet of paper
in three columns labeled as follows:
a) Desired outcomes (projects, training, coaching of others, etc.)
b) Achievements
c) Areas that need improvement
At the beginning of the quarter first quarter ever that you
implement this, fill-in only items in the first column. At the
end of the quarter, fill in the other two columns. A person is
doing great if they had, say, four desired outcomes and wind up
with four or more achievements. Last, review things that need
improvement (mine is "needs to attend relevant meetings" for this
quarter). Discuss those AND FOCUS ON BEHAVIOUR, not on
personality. Explain why the improvement is needed. After you
negotiate what this means, add it both as a thing to improve and
as a desired outcome for the next quarter. Repeat every quarter.
5. Respect your engineers' decisions. Combined, they know more than
you do, regardless of how technically capable you are. If that's
not the case, you shouldn't be a manager and you're probably not
meeting 1-3.
6. Leave your engineers alone to do what they do best. Don't invite
them to too many meetings or have them do tasks unrelated to their
charter. Engineers hate distractions, and distractions prevent
the team from achieving 1.
7. If the business folks start coming up with eleventh hour changes,
ensure that the engineers are part of the discussion and reason
WITH BOTH SIDES to figure out which changes make sense and why, which
don't, and how to come up with a solution that will meet everyone's
goals. NEVER just inform the engineers that a decision that affects
what they've been working on for three months has been made.
8. As a part of 4, create an environment where you are constantly training
your team, exposing them to new technologies, etc. Reward the intro-
duction of new techniques, procedures, etc. In 4, suggest that they
read at least a new book ON SOMETHING NEW NOT USED AT WORK every quarter.
If you work in a Java shop, they should be reading about Ruby or
You never know when a better mousetrap is available if you aren't informed.
9. Reward excellence whenever you see it, from solving the thorniest algorith-
mic q
http://eugeneciurana.com | http://ciurana.eu
1) Flex time, when appropriate. If I am working on some kind of deep core system where I just code and code and code and the only person I'm interacting with is a manager, why should I be on a 9-5 schedule? If it *really* doesn't matter so long as I get my shit done, let me come in at times where I can get my shit done most effectively.
/. and other such stuff - let me do it without having to fear that I'm going to lose my job because I need a mental floss break. I'm going to do it anyway, so why not let me do it without stress? Even better - FAR BETTER - let me work on something that is blue-sky stuff for 20% of my time. One place I worked at actually bought me animation/3D design software to use and encouraged me to take up to a day a week to work on it - on their dime. It wound up coming back to them 10-fold: when they were updating their website, and needed a bunc
2) Meeting issues. There are 3 kinds of meetings, in my mind: Meetings that are productive and important for me, meetings that are productive and important to other people, and meetings where upper management wants to whack off in public. The first kind of meeting I'll go to gladly. The second kind of meeting I'd like to always be optional. The third kind - you know, where upper management gets up and talks about shit like the direction the company is heading - well, they can email me a ppt presentation... I promise, I'll read it... Yeah... If I want to know about some big initiative the company is having, I'll print out a letter from the CEO and read it while I'm on the crapper, ok? I don't need to have some special ed like encounter group where we all blow smoke up each other's asses.
3) Respect. I don't mean people praising what I do or telling me I'm great. I mean respect like not treating me like some kind of half-functional asocial asshole because I happen to have technology skills. I really hate being treated like some kind of pet nerdling, to be brought out and questioned by the marketing people when they need the opinion of someone who, like, knows how to do math.
4) Respect. Really! Again, this is important. Just because *some* geeks are proud of their Autistic-like behavior doesn't mean we all are. Don't speak to me like I'm a child, and I'll be happy.
5) Privacy. Or, rather, a lack of frequent interruptions. There's a well known study that shows that most people can remember +/- 7 things simultaneously. Programmers frequently come in WAY on the right hand side of that particular bell curve because, one of the things we have to do is keep stuff in ready memory - highly specific, exact stuff. It isn't like we're writing a letter and we just need to remember the gist of something for later - we need to remember every damn bit of the thing we're working on (at least, I do) in order to accomplish stuff.
6) Little things. The best motivator I ever got came at the end of a 3 week crunch. I was taken aside by my manager, given an attagirl, told not to bother coming in on Friday because I would be expected to be enjoying the free spa day the company had signed me up for. Cost to them? 1 day's pay for me + $300 or so, but they had a ferociously motivated person coming back to work on Monday.
7) Managers who can manage. A boss's job is broken into two parts: supervising me and protecting me. Supervising means getting work to me and letting me know what's expected on it. I take a lot of initiative, but when I am handed a task, I would like to know what I'm supposed to do, when I'm supposed to have it done by, and (if applicable) what methods I'm required to use to do it (if I don't have a choice). Protecting me means keeping assholes like Phil in business development from swinging by and talking my ear off for a half hour in the afternoon. It means not scheduling me for meetings that are a complete and absolute waste of my time. Basically, doing all those helpful things that allow me to do what I can do.
8) Be realistic. Let's face it - at *least* 20% of my time is spent on shit like reading
Since I can't tell them apart, I treat all ACs as the same person.
I already survived my first tour as a PHB, so here are some things I noticed:
1. Hard boundaries. Some of us geeks every now and then think we can get away with murder. Which is true but no need to rub it on non-geeks' faces.
2. Shit umbrella. Your job as a boss is to isolate your employees from the bullshit so they can work. If you protect your employees from the bullshit, they will work their asses off for you.
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.
4. Be flexible. Let your geek pick his workstation OS, most of the cases he'll ask for Linux so it won't cost you a penny and he will feel happier about it. Let each employee expense out no less than one O'Reilly title per quarter, even better if you can get away with doing it once per month.
5. Pick their brains. Geeks don't mind if you ask them what-ifs. If it is obvious that the geek has more in his mind, ask him to write a white paper and give him credit for it on his next review.
6. Feed them. If your geeks are stuck at the office past 6 PM, and you know for sure it is not their fault, call in for some pizzas or chinese. A well-fed geek is a happy geek. If possible, every two months or so send your geeks out for a long "work" lunch and let them argue technical issues without being bothered by people outside of their team. If marketing and sales can meet outside on the company's tab, so can your geeks.
7. Paid time off is sacred. If you give the guy the day off, make sure everyone knows he is not to be disturbed even if the company servers catch on fire. Geeks usually take less PTO than regular employees, so you need to make sure that whatever little time they take will be peaceful for them.
8. Free caffeine. Our 15-employee company has about 9 coffee drinkers. We ran our own coffee club for about a year ($5/month per person) and we never ran out of supplies. After the first year the boss took over paying for our supplies. It is nice to have good coffee in the office and it saves you the hassle of having to run downstairs and wait in line for overpriced coffee.
9. Allow some flex time, especially if your geeks monitor servers from home. When people start bitching about Dilbert working 7AM->3:15PM, tell them that Dilbert goes home, takes a nap and works until close to midnight. Oh, and he is salaried too.
10. Allow some latitude with the work attire. If your geek has zero external customer contact in person, then you should let them wear jeans if they like to. My only rule for jeans was that they had to be clean and without tears or patches. As for t-shirts, some people like them, I don't. I think jeans and golf shirts are confortable enough for a relaxed environment.
Pedro
----
The Insomniac Coder
no shit. Mr. Salesguy gets an umpty-thousand bonus from an account that *i* worked 60 hour weeks to satisfy his promises, and i get the same paycheck as always.
... hi bingo
It's unfortunate that stereotypes of Sales people in the Tech world persist just as much as stereotypes of geeks in the Sales world.
Personally, I do both roles. Perhaps I'm fortunate, however I can see both sides.
I totally agree that there are some salespeople who believe that they are somehow superior to the technical people, who don't bother to learn or understand what they're selling, and the technical aspects of what they're selling. I have managed such people - but only briefly, normally. They haven't tended to last long with me.
Similarly, I have worked with Technical people whose contempt for sales was manifest, and whose elitist attitude made getting information about what we actually could and should sell was nigh-on impossible. Again, these people didn't last long - they had a technical manager who understood the requirements of working in partnership with Sales.
The fact is, in business we ALL need each other.
A good sales guy will work with technical to learn and fully understand his products and services. He will deliver what technical can support - and act as a buffer between the end-user and technical. If he is over-promising and causing problems for the tech - question it. Put your questions in writing, with valid explanations. Sales people should be ethical enough NOT to be causing you problems - if that is happening, then they're lying to their customers and that's something management should hear about and act on.
But Technical - you don't live in a vacuum, either. You need to be interacting with Sales. Most sales people aren't as moronic as you might think - and would welcome a deeper knowledge of what you can do. The more we know, the more information we can give our prospects - and the more we can sell.
Don't let Sales fool you - in the end, EVERYONE in the company is involved in one thing - bringing in money. Your sales rep has pressures you don't. You have pressures your sales guy doesn't. Communicate with him clearly, in language he can understand - and make sure he's doing the same to you.
If that isn't happening, make it happen.
We can work closely together - and believe me, when it's done right, everyone is happier and more productive. But little snide wars like this thread DO NOT HELP - on either side.
"This is your life - and it's ending one minute at a time" - Narrator, Fight Club