Surviving Guru Status

I have the misfortune of having GuruStatus. While it can be rewarding, it's also frustrating and limiting. There's no one to bounce ideas off of, there's no one to check my work, and there's no one to learn from. There's not much room to grow - and I realize you can't spend twelve hours a day coding forever. I'd like to work on a project as part of a team, and learn the skills needed there.

Is there a way to break out of guru status? Can it be done without changing employer?

Stop writing code. Just stop. Figure out how to get everyone else moving enough faster that no one notices. Write test cases. Pair program. Clean up ugliness that is getting in the way (make sure you do this with a partner).

If this works, you're golden. If not, you're fired and you can start over somewhere else.

See XpIsGeniusFriendly.

Is the problem really that you're a guru? Or is it that you're a TeamOfOne who has no one to collaborate with?

I was in your shoes at my last position. The guru status was okay, the problem is that I was the only person in my "group". No one else in the shop was working on the kinds of things I was working on (we weren't even solving problems in the same problem domain). I was professionally isolated from the rest of the group. No one else even shared the same professional interests as I did.

Then I convinced my manager we needed to hire an entry-level person to help me out (I certainly could have used an extra pair of hands). We identified someone who wanted to transfer from another group. We worked together for a bit, me serving as a mentor. I had someone to work with now. Sure, he wasn't at the same level of expertise, but he shared many of the same interests, and he was eager to learn. And I was eager to teach. We did some PairProgramming, and even some LearningInPairs.

There is a lot a guru can learn by teaching others. Teaching yourself to learn is one thing; teaching others to learn is harder. By coming to grips with their differing perspectives to help them overcome their difficulties and constraints, your own knowledge becomes much richer.

So be a mentor, do some GuruingByWalkingAround, engage in PairProgramming and LearningInPairs. But most importantly, find someone you can professionally and socialize collaborate with! If such a person doesn't exist in your group, seek them out, or convince the right people that one needs to be hired ASAP.

Being a Guru is great if you have other people to share your interests and insights with (regardless of whether they are a guru or a newbie). If you simply cant find or obtain such people, then I fear you will have to change positions. You might not have to change employers, perhaps just groups, or departments.

You're right, it is more of a TeamOfOne than GuruStatus. I think the problems for the organization are similar, though. I really like GuruingByWalkingAround, too.

Thanks!

Guru can't really be applied to what you're referring to. A Guru is a person who starts a religion or the high spiritual leader of a religion, not every preacher/teacher figure. The term originates from Sikhism, where it refers to the reincarnation of the first leader, the sacred text or God. Gurus have people seek them out, and tend not to actively seek the status. Confucius even said that he was merely compiling what had been said before. Maybe ElderStatus? or PreacherFigure? would more aptly describe what you are doing. -- BethanyAndresBeck

The term "guru" is commonly used among computer people for an expert in some technology or skill that no one else understands. Others do seek such people out, precisely because they are the only ones who can provide answers to certain questions. And the gurus don't seek such status. The spiritual connotations are ironic (and intentional). -- KrisJohnson

If you're a Guru in a team, here's something that always helps me: "Other people's needs come before mine."

That is, it's always more important to make other team members productive, than to accomplish a lot of coding myself. If they're idle, it cancels my self-sacrificing overtime, doesn't it? Learn to delegate. -- JeffGrigg (WeExistOnlyToServe. ;-)

Practice saying "How would you solve this problem if I weren't available?", then follow on with, "Well, guess what. I'm not available."

Having GuruStatus can be evil. Sometime gurus have to commit GuruSeppuku to protect themselves. It's not fun when colleagues compete to be the one to prove the gurus wrong at all times. People with GuruStatus does not have permission to be wrong about things, ever. If gurus are proven wrong, it's free pizza to everyone except the guru. Managers with technical background will enforce obviously bad design suggested by themselves, for no reason but to prove that they can. A person with GuruStatus, and a lack of social skills to match it, is very easy to destroy.

So how do you destroy your GuruStatus?

How do you survive losing your GuruStatus?

When you have completely destroyed any GuruStatus you might have had, start working your way back into the team again. This time make sure you are JustAnotherProgrammer? and make sure you don't come forward as a PragmaticProgrammer (if possible). Also get used to the idea that your CircleOfInfluence? will never be as wide as it was when you had GuruStatus, however there might be areas where you will find that your CircleOfInfluence? has become much wider. This is normally a good thing and almost always a sign that you have been accepted by your colleagues as JustAnotherProgrammer?.

This is of course really sad, but sometimes this is the only way out if you really want to stay on the job, or if for some reason quitting isn't an option. But remember: Being part of the team is mostly much more rewarding than having GuruStatus and being a TeamOfOne.

I have a problem with some programmers that seem unwilling or unable to learn. I am all for GuruingByWalkingAround etc, i.e. mentoring other programmers, but some programmers are just time-wasters. You teach them stuff, they seem to understand, but 2 days later they will ask a different version of the same question. After a while it becomes obvious that spending any time at all with this person is just a waste, because:

Does anyone else have experience with this, and ideas on what to do?

Put the lesson in writing (perhaps as a summary after the discussion). Point them at the document when they re-ask the question.

Perhaps better: get that person to put it into writing.

Well you can try. ForceThemToDocumentIt? takes a lot of energy, and can make you unpopular. The "plan B" to this is to simply forget the information for next time they ask: "I thought we'd already solved this one? Why isn't it recorded in the Wiki?", but this doesn't seem to work.

Another possibility (as one of the last resorts) is to just LetThemFail?. Then, the management has to pay attention to the problem. If they don't, you should probably leave.

I had this problem... a very junior C programmer I was mentoring just couldn't get the hang of allocating strings before filling them. He called me over three times in one week, we looked at the code, and it was the same problem each time. A few days later I was working away when I heard him call my name, tentatively. On a hunch I responded, "Did you call malloc()?" He paused, swore, and went back to his seat. Occasionally, guru status can be fun.

I would recommend reading "Why Employees Don't Do What They're Supposed To Do and What To Do About It" by Ferdinand Fournies, ISBN 0071342559 . Despite the forbidding title, the book provides an extensive listing of reasons why certain approaches do not work and measures to take to improve the situation. Each situation is different and you need to tailor your approach to the situation.

He called you only 3 times a week for the same thing? Lucky you. We had this particular tool which required us to do step A before being allowed to do step B. And the message which was given by the tool if you forgot step A was rather incomprehensible. I had been given this rookie to help with some tasks at hand and of course he stumbled on that tool's obnoxious handling. I was quite helpful until he asked me the fourth time in just 3 hours about that message and what to do about it. Oh, come on kid, please switch your brains on, oh please.

There's no one to bounce ideas off of, there's no one to check my work, and there's no one to learn from.

The problem does not seem to be "guru status" but isolation.

You want someone to check your work? Go ask him and be prepared to listen to his comments without being defensive. Please note, it may take multiple attempts (think in the term of months) to accept your new behavior and actually provide valuable comments.

You want to learn from someone? Ask him how he would solve a particular problem. He will almost certainly choose a different approach than you. Now try to understand the rationale and benefit to his approach. This will be learning.

The hard part about developing a specialty is that then every project you work on has a TruckNumber of 1. You have to be on all the time. Even in a sizable team, if you have a bad streak (as we all do from time to time) the project tanks. Have to miss some work? Multiple projects derail while everyone scrambles to deal with it. That's a lot of weight on your shoulders.

Mentor the newer programmers, specifically train some into your specialty, give informational presentations to the company, write up documents. In spite of that, it's still all on you. Your proteges will be assigned to something else, because you're the expert and would be more efficient, so they'll never get any practical experience. Try to push off some work on them, and it'll come back because they don't really remember their training since they never got a chance to use it.

Then you remember - I wasn't an expert at this when I started it. I knew next to nothing about it. I could pick it up, and so can they. They'd be fine without me. Thus the guru finds peace of mind. And the freedom to finally pick up another specialty.

The problem I run into though, is that eventually you are called back to fix your original works. You find you no longer recognize them, because they/it has been ravaged by those that worked on it in your absence. Those that were brought in did/do not understand what it did, or how, and so it has been gutted, limited, hacked apart, and now you are cursed for having created such a piece of junk in the first place. Gurus are not a "dime a dozen" like people like to think, and even when you leave lots of documentation, it is never enough. "Gurus literally marry their specialties for life", in order to save their reputations, and if you do not, later you will be cursed.

EditText of this page (last edited January 31, 2011) or FindPage with title or text search