The Daily WTF: Curious Perversions in Information Technology

2013-06-27 Reply Admin

F:
Of course. Standard management technique. If you don't understand that, you'll never make manager.

Not sure how you can agree with me and then imply that I don't understand the thing you just agreed with me about. :-P And not ever making manager is just fine by me, thank-you very much.

Snooder · 2013-06-27 Reply Admin

trtrwtf:
I think you're missing the point. Gurus are dangerous, because they are little reservoirs of private knowledge which they have not managed to make available to aynone else in the business. They are dangerous because they cause your business to rely on one single point of failure, and they don't do anything about it. Fire them. Face it, you're going to lose this person sooner or later. If they were capable of sharing information, they wouldn't be a "guru". You might as well lose them at a time of your choosing than to wait for them to have a heart attack or crack their head skiing or otherwise kick the bucket unexpectedly.

And how exactly did the "Guru" get his expertise in the first place?

Look, it's not the fault of the most experienced/competent person in the team if everyone else is less competent. And firing him to level everyone into the same sea of incompetence isn't going to help things. It just leads to hiring consultants and contractors later to paper over the gaps in in-house knowledge.

Look, the way to handle this is really obvious and is what every normal knowledge-based industry does. You have ranks and grades and after you get to a certain level, you are expected to train those underneath you as part of your job. Like a Senior Architect is expected to train the junior ones. You don't just keep paying people the same until they leave, or fire someone who knows too much. You promote him and make his job teaching and supervising the rest.

2013-06-27 Reply Admin

Did you ever see a "guru" who was a great coder? I never have. Every really great programmer I've ever known (and there have been a fair few) has been about making the other people around them better at what they do, not adding floors to their tower of specialness.

Immaterial. You said "if you have someone on your team who simply cannot be replaced, you should fire them immediately". At no point did you question their skill level.

Stop trying to move the goalposts.

Actually, I chose 'a'. I got rid of the old busted lock.

Yes, the problem is the whole 'getting a new lock'. Which you didn't do if you "fire them immediately". Good Job letting the store get looted though.

Also, the 'lock' is undecipherable code. The 'key' is the guy who knows how to decode it. "fire[ing] them immediately" does nothing to fix the problem of the mountain of undecipherable code that already exists. "fire[ing] them immediately" isn't 'a' its 'c'.

"fire[ing] them immediately" literally causes the problems you are trying to avoid.

2013-06-27 Reply Admin

Snooder:
And how exactly did the "Guru" get his expertise in the first place?
Look, it's not the fault of the most experienced/competent person in the team if everyone else is less competent.

You're assuming he has particular expertise and and experience and competence. Why?

And firing him to level everyone into the same sea of incompetence isn't going to help things. It just leads to hiring consultants and contractors later to paper over the gaps in in-house knowledge.

You're missing the point. It's not about firing people for knowing stuff. It's recognizing a problem and fixing it. The problem is a system which you know will fail, and you don't know when it will fail. The weak point is the "guru". The important thing to understand about gurus is that the stuff they know that other people don't know is almost always trivia - locations of key files, critical interactions, details of configurations, that sort of thing. It's never, or almost never a matter of competence - the guy who "understands the system all the way through" is usually the guy who made a system so convoluted that nobody else can understand it, or wants to try. They're never the person who can design a system so that others can understand it and modify it and improve it, because if they did that they'd no longer be the guru.

(we've read this story a hundred times here, haven't we?)

2013-06-27 Reply Admin

nitePhyyre:
"fire[ing] them immediately" literally causes the problems you are trying to avoid.

Firing them at a time of your choosing allows you to replace them in a planned and controlled fashion. Waiting until they wrap their car around a tree means you're going to be screwed at some time, which you know will come, but you don't know when.

If your problem is with "immediately", then let's say "replacing that person is your top priority", but now we're in terrible management-speak.

2013-06-27 Reply Admin

How about from the perspective of the Guru?

Lets assume hes a team player. And everyone has had the same training, started in the same class, and was given the same opportunity. The guru candidate will be the one paying attention in training. Taking notes out on the floor. Asking questions about every little detail. And actually remembering what he is told.

Everyone else slacked off in training. Knows how to do enough to get by their day to day job but god forbid a single thing be out of routine or they come crying to the most competent member on the team.

And in the beginning all was well. He answered questions, gave tips for improvement and generally helped out. But as time goes on the questions keep being repeated. Information that should be remembered not asked for because its more convenient is being forgotten immediately after it is asked for. It gets frustrating having to repeat the same procedures, same tips, same improvements over and over again. He starts to give less information. Pointing to manual where the information can be found. Maybe even pointing out the page numbers in the manual. And it progress until all you get from him is "read the manual".

But its the gurus fault for being more apt at understanding the job. So lets fire him. Not the people who show no ability to actually retain what they were trained to do.

Instead of firing every guru so you get nothing but incompetent drones. Fire every drone until you get nothing but gurus.

2013-06-27 Reply Admin

trtrwtf:
nitePhyyre:
"fire[ing] them immediately" literally causes the problems you are trying to avoid.

Firing them at a time of your choosing allows you to replace them in a planned and controlled fashion. Waiting until they wrap their car around a tree means you're going to be screwed at some time, which you know will come, but you don't know when.

If your problem is with "immediately", then let's say "replacing that person is your top priority", but now we're in terrible management-speak.

The guru didn't cause the problem on his own. If he is the bad type you're referring to, he was able to create these bulwarks of bad code because no one was paying attention to him, or checking his work, which is management's job. If he is actually talented, and just happens to be the nail that sticks out, you're going to end up making things worse by summarily firing them. The correct solution is to deconstruct the bulwarks of bad code and disseminate the siloed knowledge. If the 'guru' resists this process, you can fire them, but only then. Not simply because you've come to rely on them too much.

2013-06-27 Reply Admin

If you are wanting gurus, perhaps you should outsource for them. Here, we have many many gurus. Yogis also.

2013-06-27 Reply Admin

C-Derb:
We talk about winning the lottery instead of being hit by a truck/bus/train....

I've had jobs where the idea of being hit by a truck on the way to work seemed like more fun than making it to the office.

2013-06-27 Reply Admin

Anomaly:
How about from the perspective of the Guru?
Lets assume hes a team player. And everyone has had the same training, started in the same class, and was given the same opportunity. The guru candidate will be the one paying attention in training. Taking notes out on the floor. Asking questions about every little detail. And actually remembering what he is told.

Everyone else slacked off in training. Knows how to do enough to get by their day to day job but god forbid a single thing be out of routine or they come crying to the most competent member on the team.

And in the beginning all was well. He answered questions, gave tips for improvement and generally helped out. But as time goes on the questions keep being repeated. Information that should be remembered not asked for because its more convenient is being forgotten immediately after it is asked for. It gets frustrating having to repeat the same procedures, same tips, same improvements over and over again. He starts to give less information. Pointing to manual where the information can be found. Maybe even pointing out the page numbers in the manual. And it progress until all you get from him is "read the manual".

But its the gurus fault for being more apt at understanding the job. So lets fire him. Not the people who show no ability to actually retain what they were trained to do.

Instead of firing every guru so you get nothing but incompetent drones. Fire every drone until you get nothing but gurus.

QFT. Why the hell isn't this Featured yet?

2013-06-27 Reply Admin

trtrwtf:
EvilSnack:
Having a guru--that is, a person in a team that other team members chronically rely on for expertise--is a sign of management failure.

The way I've always put it is "if you have someone on your team who simply cannot be replaced, you should fire them immediately".

What a bizarre idea. Say your company has 1 genius, 3 basically competent people, and 5 marginal people who just manage to scrape along. You find that there are some jobs that only the genius is qualified to do: the others just can't get it done no matter how much time you give them.

How, exactly, does firing the genius solve this problem? Now you don't have a "single point of failure". No, you have a "100% failure". Instead of just one person in the company who is capable of doing the job, now there is no one in the company who is capable of doing the job. Yup, that solved the problem.

See http://www.nexuslearning.net/books/Holt_ElementsofLit-3/Collection%204/Collection%202/Harrison%20Bergeron%20p1.htm

2013-06-27 Reply Admin

trtrwtf:
The way I've always put it is "if you have someone on your team who simply cannot be replaced, you should fire them immediately".

Perhaps part of the problem with the discussion here is that we are using two very different definitions of "guru". Or to put it another way, there are two different ways to become a guru.

Method #1: Be smarter and harder-working than everybody else.

Method #2: Do things in an arcane, cryptic manner so that no one else can figure out what you've done.

Gurus of type 1 should be treasured. Gurus of type 2 you want to get rid of.

2013-06-27 Reply Admin

Anomaly:
Instead of firing every guru so you get nothing but incompetent drones. Fire every drone until you get nothing but gurus.

I agree with everything you said up to that point. I'm sure every manager wishes he could do that. Unfortunately, it's usually just not realistic. There just aren't enough gurus out there.

Most places I've worked, if management is competent they eventually figure out what each employee's relative capabilities are. Then they divide up the work. Give the really difficult jobs to the gurus and the routine work to the drones. And/or put the gurus as team leads over the drones, reviewing their work.

This may actually result in greater overall productivity than if you had all gurus. If you assign a guru to copy text from form A to form B, he's liable to get bored and start getting sloppy, or spending inordinate amounts of time reading the thedailwtf.com. But for others, copying from A to B may be the limits of what they are capable of, they see it as a challenge, and they plug away at it and get it done.

I say that facetiously but I think it's very true. I've worked with many people who do not have particularly high IQs and are not particularly creative. But they are very good at detail clerical work. The kind of work that geniuses like you and me :-) find boring.

It takes all kinds to make the world work. Next time you speak derisively of the guy who picks up the garbage, just think of what your town would be like if there was no one to pick up the garbage.

2013-06-27 Reply Admin

jugis:
trtrwtf:
The way I've always put it is "if you have someone on your team who simply cannot be replaced, you should fire them immediately".
So you punish the competent person for your poor management that got you into that situation in the first place?

For a while it was in all the latest management books and magazines as a means of ensuring that you were no dependent on since person. It later switched to have someone start shadowing the person while you are hunting for a new person then fire the person and make sure they are out the day you fire them and don't let them back in the door.

2013-06-27 Reply Admin

I've used SQL Reporting Services for 6 months in a previous job.

Then I quit without looking back...

Trust me, this post doesn't show the WTF that reporting services is...

Snooder · 2013-06-27 Reply Admin

trtrwtf:
You're missing the point. It's not about firing people for knowing stuff. It's recognizing a problem and fixing it.

Except your "fix" won't. Simply firing the one guy who bothered to learn the system won't actually teach the rest of the group that system. They'll be just as clueless the day he leaves as they were the day before. And creating a culture where people are afraid that learning too much, or becoming too valuable, is a quick trip to the unemployment office creates a culture where everyone is either incompetent or just waiting for a better job to come along so they jump ship.

trtrwtf:
The important thing to understand about gurus is that the stuff they know that other people don't know is almost always trivia - locations of key files, critical interactions, details of configurations, that sort of thing.

If it's trivia, why has nobody else bothered to learn it? Maybe because it'll take a really long time? Well guess what, that's not trivia. That's called experience.

trtrwtf:
It's never, or almost never a matter of competence - the guy who "understands the system all the way through" is usually the guy who made a system so convoluted that nobody else can understand it, or wants to try.

Look, at some point in time, the guru was a clueless newbie like everyone else in the office. Why is he the only one who actually paid attention and poked around enough in the system to learn its ins and outs?

Yes, creating silos of institutional knowledge is a problem. No, firing the guy who holds the key to knowledge isn't a solution. There are two much, much better solutions here.

Create an incentive for the "Guru" to pass his knowledge on. Not "fear of unemployment" but something positive, like a raise to a "supervisory" position where his job is to teach and mentor junior devs.
While still keeping the Guru employed, start a parallel track of knowledge building to give someone else the knowledge the Guru has. See, the Guru got his knowledge from somewhere, so you should be able to replicate that same process for a new guy. And now you have a second Guru. Repeat as necessary until you have as many people with the knowledge as you feel comfortable with and/or can afford.

In either case, you don't want to fire the Guru. He's still doing his job right? And you are fine with the job he's doing right?

TheCPUWizard · 2013-06-27 Reply Admin

Just a thought on Guru's [the good kind]....How often (%) do you really need that person vs. how often can the median team members handle the expected work?

If the % is small, then why keep an expensive resource on full salary? Find a resource that can give an SLA, and has a solid reputation.

If the % is big, take a serious look at why you have a majority of staff that can not handle the majority of the work there is almost certainly a big problem lurking.

2013-06-27 Reply Admin

A better choice of words to fire every drone until the guru can no longer be identified in the group.

Meaning they are all at an acceptable level of aptitude that is about equal.

clively · 2013-06-27 Reply Admin

golddog:
trtrwtf:
Apply trwtf's scalpel: always prefer the solution which assumes the fewest abject morons.
Why would anyone who's been in the working world more than just a little while make this assumption?
Seems as if it might be safer to assume that people are stupid until they prove themselves otherwise.

When I first started out in this business I "knew" I was better than my peers. I finished projects faster, with fewer issues and happier end users. So I figured most of my peers were morons.

Later, I branched out into larger projects and went through a period adjusting my problem solving approach. There were many "best practices" that my peers claimed must absolutely be followed. So I figured I must not have known all that much and followed along.

Fast forward a bit more, now with over 20+ years in this business. I've now learned to detect the complete bull shit around the vast majority of those "best practices". Meanwhile I have also found that those parroting them usually have no clue why they were labelled as such and couldn't explain how they were really better.. Simply because they have never tried anything else. So I am once again of the opinion that most of the "developers" out there truly are morons... or lemmings. Maybe those are the same thing.

It's like a circle of life.

As a teenager you think you know more than your dad and subsequently ignore him. Hopefully you manage to reach your early thirties alive and, once there, decide he really did know what he was talking about. Then later( 40s?), faced with questions from your own children, you realize that he was in fact completely full of shit and made things up on the fly while managing to guess right often enough to convince you otherwise.

2013-06-27 Reply Admin

TheCPUWizard:
Just a thought on Guru's [the good kind]....How often (%) do you really need that person vs. how often can the median team members handle the expected work?
If the % is small, then why keep an expensive resource on full salary? Find a resource that can give an SLA, and has a solid reputation.

If the % is big, take a serious look at why you have a majority of staff that can not handle the majority of the work there is almost certainly a big problem lurking.

Even assuming the guru costs twice as much as a median employee. And that it still takes the guru a week to do it. 10 employees would have to finish it in 1 day to break even.

My point is its almost always going to cost more for more people to do the same job unless they can get it done proportionally faster.

Why do you assume the guru is an expensive resource? They may be in the same pay schedule as the others.

So its MORE costly to let the median workforce complete it unless they can do it significantly faster then he can.

The guru takes 5 days to finish a project.

The median work force say, five people, can finish the project in 3 days. Its done faster so its cheaper right?

Wrong. Assuming they are making the same rate. You pay for 5 days of work to the guru. But 15 days of work with the median work force. Since each worker of that work force gets paid a full day for each day of the project.

5 people would have to do the work in 1 day to break even with the guru. 10 people and you only get 4 hours before your gonna cost more than the guru to get the project done.

Snooder · 2013-06-27 Reply Admin

TheCPUWizard:
Just a thought on Guru's [the good kind]....How often (%) do you really need that person vs. how often can the median team members handle the expected work?
If the % is small, then why keep an expensive resource on full salary? Find a resource that can give an SLA, and has a solid reputation.

Or, you could keep paying that "full salary" and benefit from his ability to train other developers. So that you know, later on when you have a bit of work that's slightly unexpected, you don't have a bunch of mid-level and entry-level devs scratching their heads and throwing out WTF code. And, you have a constant conveyor belt of qualified people of all levels.

But, no, better to go for the short term savings and hire a bunch of cheaper junior guys right now. Doesn't matter if you'll run out of competent people 10 or 20 years down the road, you'll have gotten your bonus and be long gone by then right?

2013-06-27 Reply Admin

Anomaly:
TheCPUWizard:
Just a thought on Guru's [the good kind]....How often (%) do you really need that person vs. how often can the median team members handle the expected work?
If the % is small, then why keep an expensive resource on full salary? Find a resource that can give an SLA, and has a solid reputation.

If the % is big, take a serious look at why you have a majority of staff that can not handle the majority of the work there is almost certainly a big problem lurking.

5 people would have to do the work in 1 day to break even with the guru. 10 people and you only get 4 hours before your gonna cost more than the guru to get the project done.

Without wanting to be mean, but I think you've just missed the point entirely.

2013-06-27 Reply Admin

Ozz:
You're ass-u-me-ing that the failure to pass on knowledge is the fault of the guru. Maybe his cow-orkers are too dumb to comprehend it?

...or manglement is too cheap to hire enough people to even be in a position to comprehend it (or not)? It's hard not to be the guru, if you're the only one that has been hired to work on something. Being the only guy in a group means you're always the smartest guy in the group!

The real problem is when your "guru" is a complete idiot in the first place. Remember, boys and girls, "guru" != "intelligent"

nitePhyyre:
That like saying "Our store is locked at night by this padlock. If we lost the one key, we wouldn't be able to open the store and we would be screwed, what can we do to not be screwed?" a) Change the pad lock for a combination lock that can be easily shared b) Copy the keys so that the problem is solved c) Throw out the key and get screwed immediately
and you choose 'c'. wtf?

d) Throw out the lock! Who needs locks? Now we don't have to hire someone to unlock it every morning!

trtrwtf:
It's never, or almost never a matter of competence - the guy who "understands the system all the way through" is usually the guy who made a system so convoluted that nobody else can understand it, or wants to try.

QFT

Skandranon:
The correct solution is to deconstruct the bulwarks of bad code and disseminate the siloed knowledge.

And who identifies said bulwarks of bad code in the first place? If nobody, even your rogue guru, knows what bad code looks like, then how do you even know that you have a problem?

A common thread of TDWTF stories is when someone who does have a clue gets hired, and speaks out about the fractal of fail being produced by the "guru", management's response is often to assume that The Guru Is Always Right, and fire the clued guy. Especially when management is a bunch of clueless idiots who value their weekly golf games together.

2013-06-27 Reply Admin

Snooder:
trtrwtf:
I think you're missing the point. Gurus are dangerous, because they are little reservoirs of private knowledge which they have not managed to make available to aynone else in the business. They are dangerous because they cause your business to rely on one single point of failure, and they don't do anything about it. Fire them. Face it, you're going to lose this person sooner or later. If they were capable of sharing information, they wouldn't be a "guru". You might as well lose them at a time of your choosing than to wait for them to have a heart attack or crack their head skiing or otherwise kick the bucket unexpectedly.

And how exactly did the "Guru" get his expertise in the first place?

Look, it's not the fault of the most experienced/competent person in the team if everyone else is less competent. And firing him to level everyone into the same sea of incompetence isn't going to help things. It just leads to hiring consultants and contractors later to paper over the gaps in in-house knowledge.

Look, the way to handle this is really obvious and is what every normal knowledge-based industry does. You have ranks and grades and after you get to a certain level, you are expected to train those underneath you as part of your job. Like a Senior Architect is expected to train the junior ones. You don't just keep paying people the same until they leave, or fire someone who knows too much. You promote him and make his job teaching and supervising the rest.

If you think the "Guru" in this article HAS any expertise, there is something SERIOUSLY wrong....

In the coding world, and particularly the TDWTF world, "guru" seems to usually mean someone who is so incompetent that they are the only person capable of working with the code they create, and are therefore made indispensable due to this INcompetence. If they wrote decent code then you shouldn't have a problem hiring someone else to maintain it and they are no longer indispensable. Maintainability is part of the definition of good code; "Guru" implies that you have some sort of unique and difficult to obtain understanding of that code. The two are generally mutually exclusive.

2013-06-27 Reply Admin

The real WTF is what this looks like in the RSS feed, with HTML span tags around every character.

Matt Westwood · 2013-06-27 Reply Admin

trtrwtf:
Snooder:
And how exactly did the "Guru" get his expertise in the first place?
Look, it's not the fault of the most experienced/competent person in the team if everyone else is less competent.

You're assuming he has particular expertise and and experience and competence. Why?

And firing him to level everyone into the same sea of incompetence isn't going to help things. It just leads to hiring consultants and contractors later to paper over the gaps in in-house knowledge.
You're missing the point. It's not about firing people for knowing stuff. It's recognizing a problem and fixing it. The problem is a system which you know will fail, and you don't know when it will fail. The weak point is the "guru". The important thing to understand about gurus is that the stuff they know that other people don't know is almost always trivia - locations of key files, critical interactions, details of configurations, that sort of thing. It's never, or almost never a matter of competence - the guy who "understands the system all the way through" is usually the guy who made a system so convoluted that nobody else can understand it, or wants to try. They're never the person who can design a system so that others can understand it and modify it and improve it, because if they did that they'd no longer be the guru.
(we've read this story a hundred times here, haven't we?)

It is a matter of competence. It's a matter of being competent enough to ensure that everything you do is transparent. And any shithead employee of mine who can't be fucked to write his documentation is getting a rocket-propelled boot up his arsehole.

2013-06-27 Reply Admin

Anomaly:
How about from the perspective of the Guru?
Lets assume hes a team player. And everyone has had the same training, started in the same class, and was given the same opportunity. The guru candidate will be the one paying attention in training. Taking notes out on the floor. Asking questions about every little detail. And actually remembering what he is told.

Everyone else slacked off in training. Knows how to do enough to get by their day to day job but god forbid a single thing be out of routine or they come crying to the most competent member on the team.

And in the beginning all was well. He answered questions, gave tips for improvement and generally helped out. But as time goes on the questions keep being repeated. Information that should be remembered not asked for because its more convenient is being forgotten immediately after it is asked for. It gets frustrating having to repeat the same procedures, same tips, same improvements over and over again. He starts to give less information. Pointing to manual where the information can be found. Maybe even pointing out the page numbers in the manual. And it progress until all you get from him is "read the manual".

But its the gurus fault for being more apt at understanding the job. So lets fire him. Not the people who show no ability to actually retain what they were trained to do.

Instead of firing every guru so you get nothing but incompetent drones. Fire every drone until you get nothing but gurus.

What part of this story led you to believe this "guru" was the only person in the company who was competent??? Are we commenting on the same site? Because it looks to me like the exact opposite was true -- the "guru" became a "guru" by NOT paying attention and as a result designing a system so convoluted and illogical that nobody else could understand it. The fact that people are arguing that this guy should have been kept on the team forever is TRWTF....

2013-06-27 Reply Admin

Matt Westwood:

It is a matter of competence. It's a matter of being competent enough to ensure that everything you do is transparent. And any shithead employee of mine who can't be fucked to write his documentation is getting a rocket-propelled boot up his arsehole.

I love how even when you're agreeing with me I feel like you're arguing with me. Try a rocket-propelled valium.

Matt Westwood · 2013-06-27 Reply Admin

jay:
trtrwtf:
EvilSnack:
Having a guru--that is, a person in a team that other team members chronically rely on for expertise--is a sign of management failure.

The way I've always put it is "if you have someone on your team who simply cannot be replaced, you should fire them immediately".

What a bizarre idea. Say your company has 1 genius, 3 basically competent people, and 5 marginal people who just manage to scrape along. You find that there are some jobs that only the genius is qualified to do: the others just can't get it done no matter how much time you give them.

How, exactly, does firing the genius solve this problem? Now you don't have a "single point of failure". No, you have a "100% failure". Instead of just one person in the company who is capable of doing the job, now there is no one in the company who is capable of doing the job. Yup, that solved the problem.

See http://www.nexuslearning.net/books/Holt_ElementsofLit-3/Collection%204/Collection%202/Harrison%20Bergeron%20p1.htm

The difference here is between "genius", "someone who can't be replaced" and "someone who's indispensable".

Geniuses are replaceable by other geniuses. If the genius is truly a genius, he has created elegant, maintainable code and ensured it is adequately documented and transferable. May not be easy to replace, and you wouldn't want to.

"Someone who can't be replaced" can be a problem, but this is probably illusory. Nobody who replaces him can do his job, but that's because what he does actually doesn't really need to be done, he's just carved himself a little niche of uselessness which a few days, weeks of analysis will enable his job to be programmed away (either in the IT or HR sense of the term).

"Someone who's indispensable" is a different matter altogether. This is someone who (by accident and/or design) has managed to fix it so that the company literally would cease to be able to function without him. This would be, for example, the man who is the only one who knows how to perform the build process for generating the company's sole product, for example: he knows what directories to include, he has the passwords nobody else has, and all that good stuff. He's definitely not a genius, but he's a fucking bastard. In this case, once such a person has shown himself to have evolved, every single step must be taken to isolate every little thing that makes him unique, and that information is to be documented and automated. If the person in question won't play ball and becomes deliberately obstructive to any attempt to find out what he does that makes him indispensable, sue the arse off him.

2013-06-27 Reply Admin

TRWTF is showing themselves more and more to be a jealous drone who hates it when their 'i just want a paycheck man' attitude causes the guru to have to fix their crap thus making them look bad.

TRWTF, do you usually wait for the 'gurus' to leave the meeting before you start talking? I've seen you before.

Matt Westwood · 2013-06-27 Reply Admin

jay:
Anomaly:
Instead of firing every guru so you get nothing but incompetent drones. Fire every drone until you get nothing but gurus.

I agree with everything you said up to that point. I'm sure every manager wishes he could do that. Unfortunately, it's usually just not realistic. There just aren't enough gurus out there.

Most places I've worked, if management is competent they eventually figure out what each employee's relative capabilities are. Then they divide up the work. Give the really difficult jobs to the gurus and the routine work to the drones. And/or put the gurus as team leads over the drones, reviewing their work.

This may actually result in greater overall productivity than if you had all gurus. If you assign a guru to copy text from form A to form B, he's liable to get bored and start getting sloppy, or spending inordinate amounts of time reading the thedailwtf.com. But for others, copying from A to B may be the limits of what they are capable of, they see it as a challenge, and they plug away at it and get it done.

I say that facetiously but I think it's very true. I've worked with many people who do not have particularly high IQs and are not particularly creative. But they are very good at detail clerical work. The kind of work that geniuses like you and me :-) find boring.

It takes all kinds to make the world work. Next time you speak derisively of the guy who picks up the garbage, just think of what your town would be like if there was no one to pick up the garbage.

"If you assign a guru to copy text from form A to form B, he's liable to get bored and start getting sloppy, or spending inordinate amounts of time reading the thedailwtf.com."

No, no, no, no, NO. What he'll do is program a way to make this task automatic and in the process find a way to make money for the company.

2013-06-27 Reply Admin

Bene:

TRWTF, do you usually wait for the 'gurus' to leave the meeting before you start talking? I've seen you before.

No, usually I leave the company when I find the "gurus".

2013-06-27 Reply Admin

urza9814:
Snooder:
trtrwtf:
I think you're missing the point. Gurus are dangerous, because they are little reservoirs of private knowledge which they have not managed to make available to aynone else in the business. They are dangerous because they cause your business to rely on one single point of failure, and they don't do anything about it. Fire them. Face it, you're going to lose this person sooner or later. If they were capable of sharing information, they wouldn't be a "guru". You might as well lose them at a time of your choosing than to wait for them to have a heart attack or crack their head skiing or otherwise kick the bucket unexpectedly.

And how exactly did the "Guru" get his expertise in the first place?

Look, it's not the fault of the most experienced/competent person in the team if everyone else is less competent. And firing him to level everyone into the same sea of incompetence isn't going to help things. It just leads to hiring consultants and contractors later to paper over the gaps in in-house knowledge.

Look, the way to handle this is really obvious and is what every normal knowledge-based industry does. You have ranks and grades and after you get to a certain level, you are expected to train those underneath you as part of your job. Like a Senior Architect is expected to train the junior ones. You don't just keep paying people the same until they leave, or fire someone who knows too much. You promote him and make his job teaching and supervising the rest.

If you think the "Guru" in this article HAS any expertise, there is something SERIOUSLY wrong....

In the coding world, and particularly the TDWTF world, "guru" seems to usually mean someone who is so incompetent that they are the only person capable of working with the code they create, and are therefore made indispensable due to this INcompetence. If they wrote decent code then you shouldn't have a problem hiring someone else to maintain it and they are no longer indispensable. Maintainability is part of the definition of good code; "Guru" implies that you have some sort of unique and difficult to obtain understanding of that code. The two are generally mutually exclusive.

The guru in this article, and the guru trtrwtf is referring to, are two different people. I am commenting on the statements made by trtrwtf. A "guru" in this sense of the article should be fired hands down, but to suppose that in every scenario where one person is a holder of most of the information about a system is the same as the person in this article is a grossly inaccurate blanket.

trtrwtf tried to cover everyone with his statement to just fire anyone in the same boat who has most of the knowledge of a certain system. But that is a very bad idea. A guru (read dumbass) is not the same as the guy elevated to guru status because he actually is better than someone.

I hope that helped to clear up any confusion.

2013-06-27 Reply Admin

EvilSnack:
Having a guru--that is, a person in a team that other team members chronically rely on for expertise--is a sign of management failure. (Note that this is not the Dilbert version of a guru, which is a person whose utterances are treated by management as if they had descended from heaven on stone tablets, accompanied by angels with trumpets.)
We call it the Truck Number: "How many people in our department can be hit by trucks on the way to work this morning before we become unable to function?" Good managers always strive to push the Truck Number up. (Other people have other names for this concept, which I am sure will be made known in upcoming comments.)

Captcha 'verto': Vini, vidi, verto!

We talk about the "Bus Accident Factor".

One of the problems is that people are comfortable being gurus. So when you support multiple systems, people take pride in being the absolute expert in one. Human nature then dictates that when an incident comes in for System A, the person who's a guru on system C is comfortable not knowing anything about System A and will happily refer it to the guru for that system - who is thrilled to be the only one who knows how to solve it (if for no other reason than because what others don't know always takes a long time [for timesheeting purposes] - even if the actual fix is seconds).

I sort of agree, though, that a lot of this is a sign of lazy management who would rather get stuff done easily than ensure their team is robus (ie specialisation over cross-skilling).

2013-06-27 Reply Admin

trtrwtf:
EvilSnack:
Having a guru--that is, a person in a team that other team members chronically rely on for expertise--is a sign of management failure.

The way I've always put it is "if you have someone on your team who simply cannot be replaced, you should fire them immediately".

I think Alex wrote an aritcle on his soap box before about the differents between the cool cats who understand the underlying technologies, and the not so cool cats who over time become specialist in a home made system, but not much use at the actual technology underneath.

I think it's important to remember that noone is indispensible, and I think sometimes it's important to move 'irreplacable' people to other duties so someone else can skill up too, but I think firing them is a bit extreme (if for no other reason than it makes noone want to become expert).

2013-06-27 Reply Admin

trtrwtf:
Snooder:

That's the sort of sentiment that leads to the situation described in the article. See, what your strategy leads to is shuffling off anyone who gains enough experience to be mildly competent. Leaving only the even less competent to pick up the slack. Eventually one of them will rise above and gain some competency, thereby becoming the "new Guru" and becoming "irreplaceable." At which point you "fire" them, or more likely as in the article stop providing incentives for them to stick around. They leave and the cycle begins anew.

I think you're missing the point. Gurus are dangerous, because they are little reservoirs of private knowledge which they have not managed to make available to aynone else in the business. They are dangerous because they cause your business to rely on one single point of failure, and they don't do anything about it. Fire them. Face it, you're going to lose this person sooner or later. If they were capable of sharing information, they wouldn't be a "guru". You might as well lose them at a time of your choosing than to wait for them to have a heart attack or crack their head skiing or otherwise kick the bucket unexpectedly.

That depends, I think. Some gurus actually have more knowledge of a system (and that's sort of what you talk about it) and some simply understand the system better (and it's not always possible to define how they understand it better - it may well be that they happen to understand C or Java or php or perl or whatever better, and are therefore better equipped (knowledge-wise) to find problems that see the rest of the team scratching their heads).

As you point out, sooner or later you will lose this person, and sooner or later someone will need to step up to the plate and learn things - but if it will happen either way, wouldn't you rather deal with it later than force it to happen now? You're in the same boat either way (with a considerable risk of a new guru appearing) so you're probably better off either letting sleeping dogs lie, or trying to somehow reduce reliance on the guru (which is actually very difficult - because somewhere along the way as people learn they will ask the guru questiuons, and guru bob will get excited and likely take over their task rather than simply assist them).

I know this stuff because I am the local guru.

2013-06-27 Reply Admin

C-Derb:
EvilSnack:
Having a guru--that is, a person in a team that other team members chronically rely on for expertise--is a sign of management failure. (Note that this is not the Dilbert version of a guru, which is a person whose utterances are treated by management as if they had descended from heaven on stone tablets, accompanied by angels with trumpets.)
We call it the Truck Number: "How many people in our department can be hit by trucks on the way to work this morning before we become unable to function?" Good managers always strive to push the Truck Number up. (Other people have other names for this concept, which I am sure will be made known in upcoming comments.)

Captcha 'verto': Vini, vidi, verto!

We talk about winning the lottery instead of being hit by a truck/bus/train....

I think the accident scenario is more realistic.

2013-06-27 Reply Admin

trtrwtf:
nitePhyyre:
-You have a great coder who is doing his job, who the company relies on. He isn't the best team player. -You have a manager who isn't doing their job, and who has caused the company to find itself in a precarious position. - You choose to fire the great coder

Did you ever see a "guru" who was a great coder? I never have. Every really great programmer I've ever known (and there have been a fair few) has been about making the other people around them better at what they do, not adding floors to their tower of specialness.

You're right, there is a management failure here as well, but the immediate point of failure is Mr. Special. Start there.

and you choose 'c'

Actually, I chose 'a'. I got rid of the old busted lock.

There's gurus that are great programmers - these are usually found in places where mediocrity is the norm, and where any attempts to help people learn fail because the people aren't great learners. These are often the people who have an aging skill set that noone else is interested in (eg COBOL (or possibly these days even C) programmer dealing with grads who have been forced to use C# through college, and think Python is great). You don't need to fire this guru, for the following reasons:

He's great, and he's probably documenting stuff - just noone else understands.
He's keeping your systems running, and probably doing things more efficiently than others (egscripting repetitive tasks; using Excel Macros to assist data formatting etc - these aren't necessarily things to document - they're probably one-off tasks (but perhpas repetitive as in "We need to do this every day for 2 weeks) where he recognises spending 10 minutes to write a script saves 3 hours work a day)
If you fire him or he leaves the result is the same - you have lost a pretty valuable resource and now some other numpty needs to skill up (and probably become the other type of guru below)

The second guru is the type who is mediocre (or worse) at the technology, but overtime has developed an intricate specialisation in a home-grown application. This is the type who knows where to kick the xerox machine to get it working, but doesn't really know why. This is also the guru who struggles to pass on knowledge even to competent peers - mainly because he doesn't really understand why stuff works, he's just noticed that certain actions help stop certain behaviours. This one (I think) is the Mr Special you refer to above, however I don't think there's much reason to fire him, for the following reasons:

His specialty is your system. He knows nothing else. He's not likely to decide to move on.
His probably a bit of a social misfit, and is unlikely to get killed venturing outside.
Replacing him now or replacing him later will cause you the same problem. Why hurry it?

Firing the guru is not the way to address the problem.

2013-06-27 Reply Admin

trtrwtf:
Snooder:
And how exactly did the "Guru" get his expertise in the first place?
Look, it's not the fault of the most experienced/competent person in the team if everyone else is less competent.

You're assuming he has particular expertise and and experience and competence. Why?

And firing him to level everyone into the same sea of incompetence isn't going to help things. It just leads to hiring consultants and contractors later to paper over the gaps in in-house knowledge.
You're missing the point. It's not about firing people for knowing stuff. It's recognizing a problem and fixing it. The problem is a system which you know will fail, and you don't know when it will fail. The weak point is the "guru". The important thing to understand about gurus is that the stuff they know that other people don't know is almost always trivia - locations of key files, critical interactions, details of configurations, that sort of thing. It's never, or almost never a matter of competence - the guy who "understands the system all the way through" is usually the guy who made a system so convoluted that nobody else can understand it, or wants to try. They're never the person who can design a system so that others can understand it and modify it and improve it, because if they did that they'd no longer be the guru.
(we've read this story a hundred times here, haven't we?)

I disagree.

I would rate myself the guru in my workplace (everyone eventually asks me when they can't work out what the issue is themselves), and it's rarely knowledge of obscure trivia. More commonly it is looking into where errors came from (rather than guessing what they mean) and analysing system statistics. If anything, what makes me a guru is my understaanding (and ability to find good resources online) of the ACTUAL environment not just the application. Others get limited by "that would require me to look at source code - that's too hard", or even "yeah, I can see that error and normally it means this, but that doesn't look like what happened, but other than that I don't know where to go". In my opinion (and of course I probably think too much of myself) the reason I am considered the guru has nothing to do with application knoweldge, nor even an understanding of the application (at least not moreso than my workmates), but it's an understanding of the technology we use, a knowledge of the tools that are available in the environment and an ability to dig for explanations. I can't teach people how unix works, but I can point them toward resources. Sometimes it bothers me that some of my peers are blissfully unaware of 'man', and are unwilling to use it even if they know it exists. Why should I document how 'sar' can be used to analyse different aspects, when resources written by people actually involved with making it are broadly available (and will do a better job of explaining what it does)? Never underestimate the impact of laziness and incompetence in creating gurus (gurus who often become that way out of necessity - not because a system will fail but because it has in the past and they were the only ones dogged enough to actually investigate to the bottom of the root cause. In all likelihood, even the email explanations of what happened have been ignored by the team - so formalising it inot a document ain't gonna change the difficulty for others to upskill should the guru get skittled by a car.

2013-06-27 Reply Admin

Anomaly:
How about from the perspective of the Guru?
Lets assume hes a team player. And everyone has had the same training, started in the same class, and was given the same opportunity. The guru candidate will be the one paying attention in training. Taking notes out on the floor. Asking questions about every little detail. And actually remembering what he is told.

Everyone else slacked off in training. Knows how to do enough to get by their day to day job but god forbid a single thing be out of routine or they come crying to the most competent member on the team.

And in the beginning all was well. He answered questions, gave tips for improvement and generally helped out. But as time goes on the questions keep being repeated. Information that should be remembered not asked for because its more convenient is being forgotten immediately after it is asked for. It gets frustrating having to repeat the same procedures, same tips, same improvements over and over again. He starts to give less information. Pointing to manual where the information can be found. Maybe even pointing out the page numbers in the manual. And it progress until all you get from him is "read the manual".

But its the gurus fault for being more apt at understanding the job. So lets fire him. Not the people who show no ability to actually retain what they were trained to do.

Instead of firing every guru so you get nothing but incompetent drones. Fire every drone until you get nothing but gurus.

you make a very good point - the guru has learnt and remembers. Why are the people constantly asking questions of him not documenting his responses?

someone who understands something intimately well will find it difficult to document - because it's natural to assume everyone else finds it equally easy. Someone who has to ask a question, should always document the answer - because if they needed to ask it, someone else might need to ask it in the future.

I know of colleagues who have left and at the time handover a document full of notes of little quirks they discovered, and resolution to issues they didn't originally understand. In all of these cases, the references were originally made for their own use - ie to remember what a guru had told them, but the notes then become an invaluable (albeit informal) documentation of different behaviours. But the creation is done by the person seeking answers, not the person knowing answers, because the all-knowing doesn't necessarily understand what questions might be asked - but the asker does,

2013-06-27 Reply Admin

TheCPUWizard:
Just a thought on Guru's [the good kind]....How often (%) do you really need that person vs. how often can the median team members handle the expected work?
If the % is small, then why keep an expensive resource on full salary? Find a resource that can give an SLA, and has a solid reputation.

If the % is big, take a serious look at why you have a majority of staff that can not handle the majority of the work there is almost certainly a big problem lurking.

I am the guru and I am paid less than at least some of the drones, however we are theoretically roughly equal.

I think the whole notion of guru (in the discussion thus far) is not someone who is paid to be an expert, but someone who has established themselves as more knowedgable (or at least capable) than the average worker. This means that there wouldn't be any point firing me to save money....

2013-06-27 Reply Admin

urza9814:
Snooder:
trtrwtf:
I think you're missing the point. Gurus are dangerous, because they are little reservoirs of private knowledge which they have not managed to make available to aynone else in the business. They are dangerous because they cause your business to rely on one single point of failure, and they don't do anything about it. Fire them. Face it, you're going to lose this person sooner or later. If they were capable of sharing information, they wouldn't be a "guru". You might as well lose them at a time of your choosing than to wait for them to have a heart attack or crack their head skiing or otherwise kick the bucket unexpectedly.

And how exactly did the "Guru" get his expertise in the first place?

Look, it's not the fault of the most experienced/competent person in the team if everyone else is less competent. And firing him to level everyone into the same sea of incompetence isn't going to help things. It just leads to hiring consultants and contractors later to paper over the gaps in in-house knowledge.

Look, the way to handle this is really obvious and is what every normal knowledge-based industry does. You have ranks and grades and after you get to a certain level, you are expected to train those underneath you as part of your job. Like a Senior Architect is expected to train the junior ones. You don't just keep paying people the same until they leave, or fire someone who knows too much. You promote him and make his job teaching and supervising the rest.

If you think the "Guru" in this article HAS any expertise, there is something SERIOUSLY wrong....

In the coding world, and particularly the TDWTF world, "guru" seems to usually mean someone who is so incompetent that they are the only person capable of working with the code they create, and are therefore made indispensable due to this INcompetence. If they wrote decent code then you shouldn't have a problem hiring someone else to maintain it and they are no longer indispensable. Maintainability is part of the definition of good code; "Guru" implies that you have some sort of unique and difficult to obtain understanding of that code. The two are generally mutually exclusive.

I sure wasn't the person who wrote our app (it was written 10 or more years before I joined the organization). I seem to have been one of few who have bothered to understand it to any depth though. There are probably 4 other people who, given loads of time might eventually manage to find the root cause for most of our incidents, but 3 of them spend a couple of hours (or less) on it and then refer it to me, and the 4th will dig and dig and eventually fget there, but not as efficiently. These days, people simply don't want to know about technologies that aren't trendy (although I'll add that 3 of the 4 mentioned before are older than me and I'd expect would have had more exposure to the specific technolgies than me)

2013-06-27 Reply Admin

Matt Westwood:
jay:
trtrwtf:
EvilSnack:
Having a guru--that is, a person in a team that other team members chronically rely on for expertise--is a sign of management failure.

The way I've always put it is "if you have someone on your team who simply cannot be replaced, you should fire them immediately".

What a bizarre idea. Say your company has 1 genius, 3 basically competent people, and 5 marginal people who just manage to scrape along. You find that there are some jobs that only the genius is qualified to do: the others just can't get it done no matter how much time you give them.

How, exactly, does firing the genius solve this problem? Now you don't have a "single point of failure". No, you have a "100% failure". Instead of just one person in the company who is capable of doing the job, now there is no one in the company who is capable of doing the job. Yup, that solved the problem.

See http://www.nexuslearning.net/books/Holt_ElementsofLit-3/Collection%204/Collection%202/Harrison%20Bergeron%20p1.htm

The difference here is between "genius", "someone who can't be replaced" and "someone who's indispensable".

Geniuses are replaceable by other geniuses. If the genius is truly a genius, he has created elegant, maintainable code and ensured it is adequately documented and transferable. May not be easy to replace, and you wouldn't want to.

"Someone who can't be replaced" can be a problem, but this is probably illusory. Nobody who replaces him can do his job, but that's because what he does actually doesn't really need to be done, he's just carved himself a little niche of uselessness which a few days, weeks of analysis will enable his job to be programmed away (either in the IT or HR sense of the term).

"Someone who's indispensable" is a different matter altogether. This is someone who (by accident and/or design) has managed to fix it so that the company literally would cease to be able to function without him. This would be, for example, the man who is the only one who knows how to perform the build process for generating the company's sole product, for example: he knows what directories to include, he has the passwords nobody else has, and all that good stuff. He's definitely not a genius, but he's a fucking bastard. In this case, once such a person has shown himself to have evolved, every single step must be taken to isolate every little thing that makes him unique, and that information is to be documented and automated. If the person in question won't play ball and becomes deliberately obstructive to any attempt to find out what he does that makes him indispensable, sue the arse off him.

The only indispensible bit is the knowledge of passwords - and even that is unlikely to pose too much problem unless he is the only admin.

Build processes can be tricky, and it can be a thorough pain in the rearquarters when some people with that sort of knowedge leave, but necessity is the mother of invention and people will eventually manage to get things going again (possibly at considerbale expense). I have twice been the replacement for an 'indispensible' person, and on both occasions have within 3 months become the new 'indispensible' person. Noone is indispensible. Noone. Unfortunately management often can't see this.

2013-06-27 Reply Admin

Matt Westwood:
jay:
Anomaly:
Instead of firing every guru so you get nothing but incompetent drones. Fire every drone until you get nothing but gurus.

I agree with everything you said up to that point. I'm sure every manager wishes he could do that. Unfortunately, it's usually just not realistic. There just aren't enough gurus out there.

Most places I've worked, if management is competent they eventually figure out what each employee's relative capabilities are. Then they divide up the work. Give the really difficult jobs to the gurus and the routine work to the drones. And/or put the gurus as team leads over the drones, reviewing their work.

This may actually result in greater overall productivity than if you had all gurus. If you assign a guru to copy text from form A to form B, he's liable to get bored and start getting sloppy, or spending inordinate amounts of time reading the thedailwtf.com. But for others, copying from A to B may be the limits of what they are capable of, they see it as a challenge, and they plug away at it and get it done.

I say that facetiously but I think it's very true. I've worked with many people who do not have particularly high IQs and are not particularly creative. But they are very good at detail clerical work. The kind of work that geniuses like you and me :-) find boring.

It takes all kinds to make the world work. Next time you speak derisively of the guy who picks up the garbage, just think of what your town would be like if there was no one to pick up the garbage.

"If you assign a guru to copy text from form A to form B, he's liable to get bored and start getting sloppy, or spending inordinate amounts of time reading the thedailwtf.com."

No, no, no, no, NO. What he'll do is program a way to make this task automatic and in the process find a way to make money for the company.

No, no, no. What he'll do is automate the process, but only admit a partial speed-up. The 10 hour process now takes 1 hour, so we'll tell the bosses we trimmed it to 9, and then we have 8 hours of time to focus on other stuff undisturbed (although often this might be writing the next piece of automation for some other task). Gurus often don't admit the full extent of their speedups, partly because they feel it's irrelevant, partly (perhaps) because it allows them to slack, but mainly because it allows them time to focus on other useful work that wouldn't otherwise get enough spotlight to be addressed without being side-tracked by crap that management has got themselves in a spin about.

2013-06-27 Reply Admin

Ho Hum:
Matt Westwood:
jay:
Anomaly:
Instead of firing every guru so you get nothing but incompetent drones. Fire every drone until you get nothing but gurus.

I agree with everything you said up to that point. I'm sure every manager wishes he could do that. Unfortunately, it's usually just not realistic. There just aren't enough gurus out there.

Most places I've worked, if management is competent they eventually figure out what each employee's relative capabilities are. Then they divide up the work. Give the really difficult jobs to the gurus and the routine work to the drones. And/or put the gurus as team leads over the drones, reviewing their work.

This may actually result in greater overall productivity than if you had all gurus. If you assign a guru to copy text from form A to form B, he's liable to get bored and start getting sloppy, or spending inordinate amounts of time reading the thedailwtf.com. But for others, copying from A to B may be the limits of what they are capable of, they see it as a challenge, and they plug away at it and get it done.

I say that facetiously but I think it's very true. I've worked with many people who do not have particularly high IQs and are not particularly creative. But they are very good at detail clerical work. The kind of work that geniuses like you and me :-) find boring.

It takes all kinds to make the world work. Next time you speak derisively of the guy who picks up the garbage, just think of what your town would be like if there was no one to pick up the garbage.

"If you assign a guru to copy text from form A to form B, he's liable to get bored and start getting sloppy, or spending inordinate amounts of time reading the thedailwtf.com."

No, no, no, no, NO. What he'll do is program a way to make this task automatic and in the process find a way to make money for the company.
No, no, no. What he'll do is automate the process, but only admit a partial speed-up. The 10 hour process now takes 1 hour, so we'll tell the bosses we trimmed it to 9, and then we have 8 hours of time to focus on other stuff undisturbed (although often this might be writing the next piece of automation for some other task). Gurus often don't admit the full extent of their speedups, partly because they feel it's irrelevant, partly (perhaps) because it allows them to slack, but mainly because it allows them time to focus on other useful work that wouldn't otherwise get enough spotlight to be addressed without being side-tracked by crap that management has got themselves in a spin about.

agree. The more you automate the monotony, the more time you buy yourself to deal with real issues that aren't getting enough traction.

snoofle · 2013-06-27 Reply Admin

AC:
EvilSnack:
Having a guru--that is, a person in a team that other team members chronically rely on for expertise--is a sign of management failure.
and solution is ofc to fire the gurus and hire persons nobody can rely on.

No problem; we recently let three of them go from WTF Inc.; you can hire them

2013-06-27 Reply Admin

jay:
C-Derb:
We talk about winning the lottery instead of being hit by a truck/bus/train....

I've had jobs where the idea of being hit by a truck on the way to work seemed like more fun than making it to the office.

C-Derb:
EvilSnack:
Having a guru--that is, a person in a team that other team members chronically rely on for expertise--is a sign of management failure. (Note that this is not the Dilbert version of a guru, which is a person whose utterances are treated by management as if they had descended from heaven on stone tablets, accompanied by angels with trumpets.)
We call it the Truck Number: "How many people in our department can be hit by trucks on the way to work this morning before we become unable to function?" Good managers always strive to push the Truck Number up. (Other people have other names for this concept, which I am sure will be made known in upcoming comments.)

Captcha 'verto': Vini, vidi, verto!

We talk about winning the lottery instead of being hit by a truck/bus/train....

Yup I often think that winning the lottery is more fun that making it in to work.

2013-06-27 Reply Admin

Evil guru = has obscure knowledge about system, config, or weird application behaviour and uses it to make himself look good. Does not play with others. Mgmt sees him as indispensable. Good guru = has obscure knowledge and analytical skills that he uses to examine problems and systems to figure out what makes them tick. Uses skills to explain things to others. Result is that problems remain below mgmt radar. Plays well with others, helps them succeed and avoid looking bad. Mgmt sees him as a replaceable cog.

Evil promoted, good discarded.

2013-06-27 Reply Admin

Been there. Done that. :p

2013-06-28 Reply Admin

As someone said above, you need the distinction between 'genius' and 'guru'. A 'genius' is just a programmer who is better than the other members of their team. They do twice the amount of work with half the amount of bugs. A 'guru' is a programmer who is a vault of undocumented knowledge. As above: a guru is the only person who knows how your build works, who knows why files are located and formatted they way they are. You ask a simple question and they can go on for about 10 minutes on little side cases.

I have a genius sitting on one side of my and a guru on the other. If the genius was to (get hit by a truck | win the lottery) tomorrow, we would mourn their loss and work a bit more slowly. If the guru was to (get hit by a truck | win the lottery) we wouldn't be able to function for months while we decipher all the procedures that he has in place and only he knows.

The guru has been with this team for nearly 12 years while other people come and go, move onwards and upwards. He has become the most experienced by default: because he can't be replaced, he can't move on to different projects like other people do. He's actually a pretty good coder, but terrible at making documentation widely available.

The saying 'if someone in your team is irreplaceable, fire them immediately' is obviously a bit trite (you obviously can't just fire someone who is irreplaceable) but the idea is that you should NEVER have someone 'irreplaceable' because they will not be with you forever. You can have knowledgeable, experienced people who are more familiar with your system than others, but they should not be the only person who knows something. An 'irreplaceable' person is a massive warning bell, a disaster waiting to happen.

We're Going to Need Another Guru!

Leave a comment on “We're Going to Need Another Guru!”