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.
A public, prioritized task list for the project and (if needed) each person... so there are no secrets and no rabbit trails
Have a manager/tech lead who codes at least half time so they understand what's going on with the project and the team
Agile Artisans
On a large team, the contributions of the best people are always smaller, and overall productivity is always lower. As a general rule, you can count on each new software project doubling in team size and in the amount of code involved -- and taking twice as long -- as the preceding project. In other words, the average duration of your projects will go from 2 years to 4 years to 8 years to 16 years, and so on. You can see that cycle with almost any technology. Two or three people invent a brilliant piece of software, and then, five years later, 1,000 people do a bad job of following up on their idea. History is littered with projects that follow this pattern: Windows, Unix, Java, Netscape Navigator. The smaller the team, the faster the team members work. When you make the team smaller, you make the schedule shorter. That may sound counterintuitive, but it's been true for the past 20 years in this industry, and it will be true for another 20 years. The only method that I've found that works is to restrict the size of teams arbitrarily and painfully. Here's a simple rule of thumb for techie teams: No team should ever be larger than the largest conference room that's available for them to meet in. At Novell, that means a limit of about 50 people. We separate extremely large projects into what we call "Virtual CDs." Think of each project as creating a CD-ROM of software that you can ship. It's an easy concept: Each team has to ship a CD of software in final form to someone else -- perhaps to another team, perhaps to an end user. When you treat each project as a CD, you enable one group to say to another, "Show me the schedule for your CD. When is this deliverable coming?" It's the kind of down-to-earth approach that everyone can understand, that techies can respect and respond to, and that makes almost any kind of project manageable.
Actually this sounds like a really good arguement against open source collaborative projects!
Be nice, sponsor me: http://jailbreak.ragabonds.org.uk
Food.
yes, it's stereotypical, but "geeks" tend to not take the best care of their health, they enjoy food, chinese take out, pizza, snacks, etc.
Too many meetings. Most employees don't like meetings, at least most employees that are productive.
I don't know that it's the number so much as whether the meetings are productive or not.
One of the tricks I really like from Extreme Programming is the daily stand-up meeting. It's a fast-paced status meeting where everybody gives a quick summary of what they did yesterday, what they're doing today, and what they need help with. If people want to discuss something for more than about 30 seconds, they schedule something later with just the people involved. And as the title says, everybody must stand throughout, which keeps the pace lively. Generally they're 10 minutes or so.
There's a fine trick in another agile method, Scrum. Scrum, thinking of a ham-and-eggs breakfast, divides people into chickens and pigs. The chickens are involved in the project, but the pigs are committed. In a Scrum status meeting, chickens may attend, but only pigs can talk.
It can also help to forbid all distractions. If people are going to check out, then they should just leave and do something more productive.
Im not sure this applies since i work in QA, but generally, don't give geeks repetitive stuff. We'll do something maybe twice or three times because we have too, but if we keep doing the same stuff over and over, you'll lose your passion. That's whats happened to me so far.
Also, put them in an environment where they are challenged and where everyone isn't slacking. IF you see someone slacking, he should get penalized. I don't care what the excuse is, but if your working hard when everyone else slacks, you lose your motivation.
Simple.
Remove all the layers of dreck management who simply get in the way.
Yes you may have got a 1st in Etruscan pottery/Elizebethan clothing/Interior lighting. Yes you may be intelligent but you have FUCK ALL knowledge of computing. Yes you know how to schmooze the clients but you have FUCK ALL knowledge of what we actually do for the clients.
So stop bugging me every ten minutes when you want to update your retarded "man hours per task" spreadsheet. Stop bothering me about my "unfashionable" attire (i.e. anything you don't see in you fucking Sunday supplements) Leave me the fuck alone to do the fucking job you're paying me for... i.e. provide a technical solution to a problem.
So the best way to manage Geeks is simply to leave them alone. If they've gone off on a tangent and it's going nowhere point this out. But generally leave them the fuck alone.
Either that or take out the entire chain of middle management and shoot them. All you need is a good captain, a good first mate and a good crew. All the rest are simply shark food.
Arr.
1999:
> we have permanently entered a new economy
> The geeks control the limits of your business
> rich salaries and hefty stock options that they now command.
> give them promotions without turning them into managers
2005:
Geeks are the lowest paid again. Managers are the highest paid again. There are things managers can do today, experiences they can have, which geeks will never have. The dual track approach doesn't motivate anymore and Indian startups like Google Bangalore actually let their geeks become managers.
Only in extremely rare upturns have geeks ever commanded the lifestyle that managers have. For most of history, if you want to live in a house, if you want to go to concerts, if you want to get married, you have to be a manager.
Eric Schmidt's comments and insight were very good. As sort of a geek myself if gives me insight on why I have liked some managers, and not others. Why was I so purely productive in one environment and then screaming inside myself to get out in others.
The best single task I had was as a consultant. I walked into the interview, I was myself. It lasted 5 minutes and I was hired. The project manager spent the morning with me on the first day and made the business objectives quite clear to me. Some ground rules on documentation and my scope were set clearly and realistically. And the rules and objectives didn't change because of convenience. He outlined the problems and the needs while I was being introduced to the business players. Then set me off for two weeks to study it, with the mandate to be creative and practical. Note here, the technical solution was not predisposed, only the business needs were. I then presented (poorly presented) my observations and ideas outlining a solution to the business people. I walked away thinking I didn't do too well as the business asked some specific questions some of which I didn't have the answers.
But I guess I did good enough, a few weeks later approval came down to do it. I implemented the project as the technical lead in 8 months, on time and on schedule. The parent company hired me right after the gig. I learned later that their own people wouldn't touch the project. Wow, there is money in dealing with screwed up environments if you get the stick to clean them up.
The biggest thrill was the Monday morning when 600 people started to use our work for the first time, it was a big cutover. It went down as planned. Call me nuts, but this geek gets a thrill out of seeing others use my work. It is the best perk of the job. The politics of position jousting and power thrills do little for me but does makes me walk.
So it is good that some environments actually think about how to empower and guide their geeks as opposed to a more Machiavellian BS that so often occurs. Too bad Novell has fallen off a good ride, as Ray Noorda was the last decent Novell CEO.
and wondered how applicable the information was today
This is simple. It is. Geeks haven't socially evolved that much in 6 years other than the fact that chicks like it when you have the car thats not a beater and you have the money to fill up the tank before picking her up. As the article says, geeks are not anti-social, we just don't like cheap manipulative self serving management styles any more than we like chicks that way. And when geeks do it, we do it with thought!
Different people find different things boring. And most boring tasks can be automated, a metatask that geeks usually love. While plenty of stubbornly boring tasks don't require geeks - boring normal people are suited to them, especially with geek-produced tools.
Sure, there will probably always be tasks you can't interest a geek in that needs a geek to do. But management is an inexact science. The story submitter asked for "best way", not "perfect way" to manage geeks. If you're really a geek, you'll appreciate the difference.
--
make install -not war
We have names for employees like you - hourly wage earners. Someone who comes in at 7:30, punches the clock, does exactly as they're told, and goes home after they have 8 hours in, and is never expected to give anything more.
If only it were that black and white. You must work in a small organization. I work for a fairly big one (IT alone is 400+ people, not including the outsourced hardware/network support), and have been in many situations where showing initiative would lead to a lot of trouble. You can't always just willy nilly start to experiment on your own, or you screw other teams up. To do it right you have to coordinate with everybody and by the time you do it's 3 weeks later.
That kind of environment sucks a lot of life out of you, especially if you're new to it and just learning. I'm not saying that it's a good way to be doing things, just that it is that way in a lot of places. Turnover is not unsurprisingly quite high.
You are right that anybody doing only what they're asked and no more isn't a valuable employee. All I'm saying is that in a large organization you aren't always able to take the initiative even when you spot a chance to.
I work with a damn talented bunch of people who will do whatever it takes to fix a problem, and who are always looking for (and finding) ways to improve our systems. But if we tried to actually do anything without first checking with our manager and making sure all the affected groups are informed, we'd cause chaos.
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.
There is a flip side to this. At the job I was recently layed off from we were constantly given very insufficient specifications for what our boss wanted. Generally assignments were along the line of "Hey, we need a program for X that does A, B, and C". At first this seemed really cool to me, being given a fair ammount of lattitude in the development of an application. What ended up happening though was that often someone would add a feature that was very nice or necessary to the application (One example was a web based replacement for some accounting spreadsheets the execs were using written in PHP, the coder who was writing it added the ability for someone with administrative rights to add or edit formulas used in some of the calculations.) only to be chastised by our boss for adding things not explicitly stated in the specifications. Keeping in mind that the projects always came in on or before the deadline, and these were internal projects, not code that we were going to sell to clients.
After a few times this happened to me, I stopped seeing the point in doing anything not explicitly stated in the very meager specifications. The programs were, by my standard, not usually very good as they lacked obvious features that would have been trivial to implement, but the boss was happier.
Famous Last Words: "hmm...wikipedia says it's edible"
The last time I took an initiative, it was at a client who I had to take back his computer to the office in order to fix it. On the scene, I notice that the problem was trivial, and I fixed it in 30 seconds.
When I came back, the big boss (not mine) asked me why I didn't bring back the computer.
- Well, I fixed the problem over there.
- THAT'S NOT GOOD! WE SAID THAT WE WOULD BRING IT BACK HERE TO FIX IT, AND NOW WE LOOK LIKE WE DON'T KEEP OUR WORD.
I had my lesson: don't bust your arse. You'll get shit anyways, but at least, I won't have busted my arse to get it.
Luckily, the company folded a few weeks afterwards, unfortunately not because of me.
My daily meetings are 1 to 2 minutes per person. This keeps this ~really~ short. If people start spinning off into private discussions, I ask them to take it "offline" and get together after the group meeting.
It's a surprisingly good way to let me catch little issues before they become big issues.
I don't like walk around managing for two reasons.
The first I don't like walking around all day. :)
The other reason is that developers work better without interruptions. I think a manager's job description should include ~preventing~ disruptions, not being the one causing them by dropping in at random during the day and demanding a status report.
I practice meetings that are very similar to the Scrum daily meetings. Everyone answers three questions. What did you do yesterday, what problems did you have and what do intend to do today?
Rather than embarrassing people into lying about status, I find it's a good way for me (or other senior team members) to spot problems and help get them solved.
It's not so much about micromanaging but communication. People are going to misunderstand. We're human, it happens. But talking (or meeting) frequently helps to catch those miscommunications more quickly. If meet monthly, how much time is wasted on the wrong tasks?
I've been in and out of managment, development and testing and it's the best way I've found to run a team.
But then again, everyone's different and every team is different. Just because it works for me doesn't mean it has to work for you.
Agile Artisans
Because when you are only a candidate you have you aren't really in a position to make demands. Asking to come in "late" has a negative connotation. Few people realize the way a true geek looks at it. 8 hours is 8 hours right? So why not let me do my work when I'm most productive? The problem is that bosses want to pop out of their office at 8:30a and see all their little underlings in their cubes typing away. It makes them feel like everything's under control.
Believe it or not I am not like the "nerd" I describe anymore. I've grown up a bit. Don't drink whisky to get to sleep anymore. And I show up for work on time. But I do believe that it's unfortunate that companies can't be more flexable when it doesn't really matter.
And just so you know, it does matter because of the following reasons:
* The boss doesn't want to deal with the hardware guys whining about the developer who gets to "come whenever he wants to".
* The software you wrote is in production and you need to be in your office when the rest of the people are to take support calls, etc.
* You want to be viewed as dependable. Not just a brain.
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
I have only been in "industry" a short time. But in that short time I have seen some horrible mismanagement of technical staff. I have basically come to the same conclusions as Eric has about, basically, how a geek would run things if given the chance. Rather, how I would run things.
A competent technical person can see right through a fraud by talking to them for 10 minutes. A manager can ask about certificates and walk down a list of "technical" questions he downloaded off a website, but a fool that did his homework will usually pass such paper barriers. And a fraud will pass with such flying colors.
And yes, YES. Productivity per developer exponentially drops for each additional developer you add to the mix. Very quickly the cost of adding resources hurts more than it helps. And eventually the project is doomed to failure until it implodes and gets restarted with less developers.
The only thing I would object to is the way managers try to spot the alpha geek. DO NOT necessarily pick the one that keeps going to upper management. You have probably found the similarly colored brown nosed geek. Giving the brown noser special privilage will only enrage your more competent employees for your inability to smell out true talent like they can.
I work for a company that used to be at the top of it's game. It used to create the best products in it's market segment. It still has the largest market segment share, but this is because of it's lingering control of the distribution channels.
Now most of it's products are inferior to those of the competition. The competition is gaining market segment share and the distribution channels are getting uppity.
What has happend to this former giant of technical excellence? The short answer is this company thinks it does not need geeks. This company gives pay cuts instead of pay raises. The company no longer values it's engineers. Part of this is that they are drooling over the lower paid talent in India. Do not get me wrong. I think the company should hire some of this lower cost talent in other parts of the world. This is good for the world even though it is not good for me.
Beyond this though the company thinks it can substitute "management process" for engineering. There are many many meetings where managers talk about procedures for engineering products. They have meetings to discuss procedures to talk about how to talk about procedures for engineering products. The ratio of talking about doing to doing is extraordinarily high. Most of the product developement decisions are made by what they called "product development teams". This is a group of people where product design engineers are a very small minority, and where engineers of any sort are a minority.
Beyond this, we have an annual review process that is a cross between a high school popularity contest and a bad episode of Survivor. In this review process people who do not know or have any understanding of what we do determing the outcome. One thing that comes out of this is that we do not know what we are accountable for.
If this company does not relearn to love geeks soon it will see a big decline in profitability and market segment share.
Religion is the main cause of atheism.
I was a manager and am now back to being a regular employee (who leads a team).
Coming up through the ranks I thought that staff meetings were a waste of time, but I was wrong. I rarely held formal staff meetings and attempted to manage by wandering around. The problem I found with this was that certain people were easy to talk to one-on-one and others weren't, so through reticence messages I needed to give to the team as a whole were delivered late to some. These people felt I played favorites, and unconsciously, I did.
I rewarded people with monetary rewards and always accepted comp. time, but the reward that got the best response from people was just not having them come in when their project was finished (not employee-initiated comp. time, but like a suprise holiday).
The perk I always liked was free t-shirts commemorating a project. I didn't wear them much, but I liked wearing them outside work as a badge of what I do. This perk died at the turn of the century. Am I alone in this?
Since I stopped being a manager these are the worst things I've seen that you can do as a manager in your staff meetings:
Read powerpoint slides from meetings you've attended without offering any insights or interpretations.
Start your meeting with the phrase "I really don't have anything to talk about" then proceed to talk for 45 minutes anyway.
Say "Well, I know something about that, but I can't say anything" and then not say anything.
Differences between managing in 1999 vs. now:
More people telecommute and never come in so you need to manage over the phone. This is much harder than you'll think it will be.
I'd rather be preterite
I spend a minimum of 50% of my week programming and I haven't worn a suit since prep school. The people who work for me have a great deal of freedom. That freedom is secured by a very well defined yet minimal set of agreements. Everyone inside and outside my group understands the agreements and recognizes the importance of maintaining them. A regular reasonable work schedule is just one agreement.
I haven't had any problems filling my open slots and I haven't lost or fired anyone in over two years. There are plenty of developers who welcome such structure. For those who don't there are plenty of other places to work.
I have two "geeks" who call me "Sir" ( even though I tell them not to. They still call me "sir". ) and I have found that the best way to manage them is to give them the problem, and say "Go solve this." and let them go and Just Do It. (Nike Swoosh(tm))
When they need "Elevated Authority" they come to me, but I've found that telling them the problem, and letting -their own- judgement dictate the methods of solving the problem, often A: makes them -HAPPY- to work for me. and B: Solves the problem. Is INFINTELY better than micromanaging them.
"Here is $Problem, take care of it." and let them do -whatever they need- to, has worked far better for us than any other management(of interns) methods yet.
This way we are letting them decide what is the best way to reach the goal. and -TRUSTING- them to reach that goal. (which is often more valuable than the goal itself) and in the end, if they fail, I can show them why.
I have two "geeks" in my charge, that would kill themselves if I asked them to. They'd take my hardest tasks -any- day, over the HRs mindless shuffling of paperwork, because I let -their own- judgement choose how to solve the problem.
You want to manage geeks? Tell them what needs to be accomplished, and give them free reign to do whatever their training and personal skills tells them is necessary to solve the problem. I've never -ever- had one come to me with a failure.
But! There is a Caveat. You have to be willing to let your "geek" run free. Not only that. You will have to let your "geek" know (consiously or unconsiously) that you will take the hit, for his failures. Because at the end of the day... his glory is yours.. his failure is yours. If you let him -Run- with whatever he wants.. Let him -know- that you will absorb his fuck ups. You -will- get magic. BUT! You have to let your "Geek" run.
Only then, will your "Geek" truely shine.
-rdewalt
Try this...
:-)
:-)
The unpaid lunch concept. I was expected to work 8am-5pm, yet paid for time from 8pm-lunch and +60min-5pm. Are people really that unaware of their personal worth that they invest unpaid time into the company without any meaningful return?
They insisted I take the damned lunch and not get paid for having this time unavailable for my personal use in a block of time not conjoined with the rest of my personal time. I would suspect most of us here who are working on solving a problem don't necessarily stop at an arbitrary break time? So I did take my unpaid lunch. At 4pm. At first everyone was thinking I was crazy - but is it not logical to take lunch when you are actually hungry? The fact that it happened to coincide with the end of workday was a sheer coincidence.
Then there is the concept of interruptions. The clients got the most productive use of my time only when I was using equipment actually adequate for the task, at home. For some absurd reason that was unacceptable. I lived 3.2miles away on purpose. Billable work is billable work, right? Who cares where it is done?
what do you get when you make a good geek mad enough to leave your company? A competitor!
My rules as a geek manager:
1. Work from wherever you want, as long as the desired results are produced
2. You are not expected to work for more than 40 hours a week
3. Spend at least 5 hours a week on training in advanced topics, you are expected to be certified in a ton of stuff in a very short period of time
4. You are paid in accordance with your direct revenue portion - billable work is paid for according to client's billable rate, non-billable work is paid at a different rate
5. We have an advanced lab environment available to facilitate item 3
6. You can make as much money as sales people if you bring in new accounts
7. You are not a client babysitter
8. Rigid hours are not needed as long as you are available during business hours
It just reflects what I hate and we are growing nicely in the shark-infested waters of IT in Bay Area.
Some companies have some of these points in place, but I find that adding a sales commission keeps the turnover rate substantialy lower. The employees know that bringing business into the company and being compensated for it with every invoice is worth more than the gimmick $500 referral bonus that they can make in 4 hours working direct. That coupled with an actual training program produces a very attractive environment.
Leonid S. Knyshov
Find me on Quora
Perhaps looking to Novell for advice on how to manage geeks and run a successful tech business in general is not the best solution....
1 1201&tid=223&tid=218/ 2154247&tid=223&tid=143&tid=1069 247&tid=187&tid=98&tid=2185 2&tid=223&tid=187
http://it.slashdot.org/article.pl?sid=05/11/02/21
http://linux.slashdot.org/article.pl?sid=05/10/27
http://it.slashdot.org/article.pl?sid=05/10/21/12
http://slashdot.org/article.pl?sid=05/09/16/05312
That was one of the best rants ever. It reminds me exactly of places I have worked. I can completely understand the desire not to come back to the IT world after that. It seems sometimes that many employers think that there will always be enough people coming straight out of training desperate for work to fill all the roles they'll ever need. Of course, when apps have legacy workarounds, experience is the key.
One of the places I worked at was ridiculous. Fortunately, I worked in the web design shop, and didn't have to support anything. Basically, though, we had an ISP that provided server co-location and webhosting in an unsecured basement directly under sprinklers. The patch panels for the network were wide open at any time. We had technicians for hardware support who were near useless. The boss tried to run everything like he was still in the Army and we were supposed to respect the chain of command. Well, if productivity goes up when the boss goes away, you know what the problem is.
The most ridiculous thing was when we decided to come in as a web team and blow off steam for the week playing games on our LAN in the web office. We used our own machines for doing web work, since our boss continually bought second-hand (or even third-hand) crap off of eBay. He threw a fit about us using company resources, even though we paused to help out customer support when the phones rang too much.
Linux - because it doesn't leave that Steve Ballmer aftertaste.
Well said!
......
;) ), there is no need for overworking anymore.
Just recently i've been faced with such a kind of manager:
- Some sales guy got moved to project management and given a baddly defined (the requirements document was a joke and nobody noticed it before i came in), short budget project to do.
- First project meeting and he comes out with "We're going to have to do long nights on this one"
- My response: "Do you know i'm a freelancer and get paid by the hour?"
Somehow, even though the project overran the budget (2 or 3 times), i never got asked to work extra (and payed) hours
My theory:
- Making developers work over-hours is how bad managers (try to) compensate for their poor management skills (bad planning, skipping of requirements analysis, not saying NO when they should, no prioritizing, ignoring how client dependencies affect deadlines, etc, etc, etc) and keep projects within the budge.
It will only happen when said managers have something to win (free out of budget hours) but nothing to loose (if a developer leaves or gets sick one can always blame it on the developer himself).
When those extra hours DO come out of the budget, then (strangelly
Overwork is what has kept hordes of incompetent low/mid-level managers employed in this industry...