"C'mon! You think you're the only one on this planet who knows how to do this sh*t?"
 

The programmer in question looked thunderstruck, as though his manager had just given him a rabbit-punch in the gut. He looked like the smart-a*s from seventh grade who had just been told, "as a matter of fact, you are not the smartest kid in school."

We programmers (and Linux sysadmins) are indeed called upon to be more-or-less masters of some very arcane things. And there are such great responsibilities associated with everything actually running properly, day in and out, that it's quite easy to begin to think of oneself as irreplaceable ... or, far worse yet, to become so.

"Write it down. Spill the beans. Write the documentation so that everyone else can actually find it and read it. Train someone else. Share the wealth. Get out of every 'critical path' that you stumble across. This operation does not and must not revolve in orbit around you, or me, or anyone else on this team." The manager looked the programmer keenly in the eye, with a pointed kind of look that kept his eyes locked there even as they glazed. The message was getting through, hard.

I'm happy to relate that the programmer hastened to implement his lesson. Both programming and system administration are just too hard, and too vital, to be held in the head of only one person. Share the know-how, share the responsibility, share the blame. Share. And never let yourself be lulled into thinking that somehow you know it all. You don't, and good news is, you don't have to. If you couldn't walk away from your job tomorrow (P.S. watch out for that bread-truck ...) and leave it in good hands, you're just driving yourself to an early burn. Break those habits. Life's too short. Yes, the job's important. But, not that important.

And...

If you can't be replaced, you can't be promoted.

I don't know about that programmer, but in similar situations an honest answer would be "Maybe not, but I'm probably the only person you will ever meet who can to this sh*t".

I have left a few jobs. I have never been successfully replaced. Several companies have thought that hiring two or three people to do the job I used to do alone could work. It hasn't. Those projects simply failed. Even if you make the job smaller, there is a minimum skill level that may be nearly impossible to meet.

At a recent review, my manager told me "no one is indispensable". The honest answer (which I of course kept to myself) is "yes, but projects fail". Some projects simply can't survive the loss of the most skilled engineer.

I have worked with some very skilled engineers that try to make themselves more indispensable by hoarding information. I think they must secretly have a rather low opinion of their skills. I have always been far too arrogant to even consider a strategy of hoarding information. I give out information as much and as effectively as I can at every opportunity. That lets me delegate work that I otherwise would need to do myself. It lets me work on even more challenging and interesting work myself. Management (at any company) never gets it: But simply being more skilled at software engineering than anyone else they could hire makes you irreplaceable. Even the second or third best engineer in the group doesn't really get ahead by hoarding information.

This year, I lost the best engineer working for me (in my arrogant opinion, second best in the organization). That necessarily has a terrible impact on projects and schedules. Management is deluding themselves with phrases like "no one is indispensable".

In a better economy, that was a good reason to quit. That was the reason for one of the times I quit a job.

Yeah, I never understood people who think that other programmers are intentionally trying to secure their own positions by hoarding information. In my experience it's far, far more common for programmers to be so proud of their solutions that you can't get them to shut up.

Not what I said at all. During several periods in my career, the second most skilled engineer in the organization practiced extreme information hoarding.

My point was that doing so did not give those engineers any net career benefit.

Writing is fairly pointless if the predominant company culture is to avoid reading.

That is close to one of the issues I struggle with.

Our company culture sets a very low max length on the things people will actually read.

I'm not as skilled at writing English as I am writing C++.

I cannot compress a useful communication into the size that will be read.

I'm not a programmer, but I would never take s**t like that from anyone.

You should also know how to deal with these managers, each has a different style and you have to work around it. Some are easily angered by certain things. Some are insane and you should try to appeal to a higher level or just find another place of work.

I dunno. There used to be a time when I thought that my knowledge was so unique and irreplaceable that no one could do the job without me. Then I found myself stuck in a situation where no one could do the job without me ... and, I hated the job. I quickly figured out that the rest of the people I was working with (sic) at the time were all too happy to be the ones going to movies and restaurants when the windows outside the office window contained darkness. I started writing stuff down and, instead of plopping the right answer right down as au fait accompli, started acting a lot more uncertain. And ... other people started coming up with better ideas than I'd ever had. And I started going to movies again.

I always observe that it is my software engineering skill that is unique and irreplaceable. I rarely work on projects where my project specific knowledge is number one in the group. Half the people I supervise know more about what they are working on than I know (that ought to be all, not half, and I am always trying to get there). I frequently collaborate outside the set of people I supervise and then it is almost certain that other people will have more project specific knowledge.

If I knew how to teach analytical ability and software engineering skill, I would certainly do so. But it is hard enough to transfer knowledge. I have had only rare successes in helping someone else gain ability.

Many people (including all of higher management everywhere I've worked) cannot recognize that something other than knowledge is even relevant.

There are two engineers who happen to both be named Andy that I collaborated with at two different companies in two very different fields, with very similar interactions: Andy did not ever want to collaborate with me, because it was obvious that he had all the project specific knowledge and I didn't know anything relevant to the topic. On multiple occasions when Andy was spinning his wheels for days over a hard problem, our manager insisted over Andy's strong objections that Andy seek my help and answer my questions. Each time it took an hour or two to solve Andy's problem. Each time the solution was reached, Andy was loudly certain that he had solved the problem himself and I had contributed nothing. On the theory that just explaining the problem was what let Andy solve it, one Andy got the manager to agree that he should explain the next problem to a third engineer rather than seek my help. That didn't work and I still ended up needing to help.

All my successful collaborations outside my direct reports could be described as combining my intelligence with someone else's knowledge. But you can't ever describe it that way when you want to do it, because that is offensive to the other person. The lack of an alternate way to describe it was the source of the stress with Andy, Andy and a few similar co workers. Sometimes there is no other explanation for why it works. The two different managers for Andy and Andy both had the sense to not care why it worked nor even whether I made a contribution. The work needed to get done. When Andy answered my questions about his problem he solved the problem. Otherwise he didn't.

Some alternate explanation is usually in play when the collaboration is free of the kind of interpersonal stress of the interactions with Andy.

Data flow expert: In many of my collaborations, the problem required a little data flow expertise and I had more data flow knowledge than the topic specific expert, so we could pretend I was the data flow expert justifying the collaboration. I'm not really a data flow expert. I know more about data flow than anyone I've actually worked with, but by looking at various online info, it is clear that there exist data flow experts and I'm not one of them.

Socratic teacher: Some of my most successful collaborations were by fake Socratic method or even accidental fake Socratic method. In the Socratic method, a teacher who knows the answer asks the questions necessary to get the student to realize the answer. The lesson is generally more effective than telling the student the answer. In the fake Socratic method, a teacher who doesn't know the answer asks the questions that cause the student to realize the answer.
Some of my most successful/bizarre collaboration were with Bill on very hard problems in a field I knew nothing about. After Bill was stuck for days, he would seek my help. I would ask questions about the problem and stupid questions about the basic rules of the field in order to try to get an initial understanding of Bill's problem. There was always a moment at which I suddenly started to see what the problem was and I was ready to start helping Bill find a solution. At that moment, Bill said "I see what you're driving at. Thankyou again." and walked away knowing the solution.
In other conversations, Bill made it clear that he refused to believe I wasn't secretly an expert in the topic. Bill very much appreciated that I always asked him questions that made him find the answer, rather than ever telling him the answer. He never believed that I could lead him somewhere without ever knowing myself where we were going. My consistent lack of any topic specific knowledge was obviously just an unsuccessful attempt to balance out my normal insufferable arrogance with some topic specific false modesty.

You tell a very interesting tale about "fake Socratic method," which is not a term that I was familiar with until now ... although I have also seen it in action.

You definitely hit upon some key points in that last reply:

• The manager (and the business) simply wanted the work to get done, and they realized that a log-jam existed. They didn't rip the assignment away; they simply obliged him to get help from you. (And you didn't "rip it away" either. Brilliant. Everybody saves face, even if they grouse about it at the time.)
• Your colleague couldn't bring himself to surrender "mental ownership of" the problem. Even when the solution or the key to the solution came from someone else, he couldn't bring himself to terms with that ...
• ... and yet, there was no bona fide reason not to. His worth didn't drop in the eyes of anyone just for seeking outside assistance. He didn't have to carry the entire load himself; but it likely never occurred to him that this could be so.
• There is a big difference between "causing a problem to become solved," and "being the one who gloriously and single-handedly solves it."

In the OP that I started this thread with, the (anonymous) engineer whose tale I was relating most-certainly didn't lose his job either. Today he's happy as a pig in :eek: as a very good senior team-lead; basically a more-than-entry level management position(!) in which he gets to keep his hands dirty, which he loves and is good at. But he also runs his teams on well-oiled paperwork ... complete knowledge-sharing and status-sharing ... and people come away from working on his teams (and on other teams patterned like his) knowing considerably more than they started with, both in terms of technical know-how (which they no longer seek to hoard), and the art of working efficiently. (Teams are "efficient." Just, hard to find.) The engineer would have been stuck in his own career log-jam, possibly forever, if he hadn't made that medicine go down. ("And that's pretty much why he told me the story that I've now told you, Gentle Reader.")

I remember that he described this cross-learning technique that you spoke of, although the term "fake Socratic method" wasn't dropped that I can recall.

That is a term I made up myself, originally for something that happened to me when I was in high school and tutoring students in the MBA program at UMass Amherst. That MBA program misunderstood the growing importance of computers in business and required MBA students to take Basic and Fortran programming courses. (Yes computers turned out to be vitally important, but programming was not the aspect of computers those students needed to learn).

After tutoring in Basic one semester, I agreed to tutor the same students in Fortran the next semester. I knew nothing about Fortran at the time, but assumed I could learn it all in a few hours by reading the manual (I probably could have). I procrastinated and didn't get to the university book store to buy the manual until it was out of stock. So I showed up for the first tutoring session without a clue about Fortran.

Given hard working students who had clearly read the right parts of the Fortran manual before even seeking my help and given homework assignments that they could not figure out how to code in Fortran (after getting A's in Basic): I started by asking them "how would you do that in Basic?" and when they didn't quite know, I asked some actual Socratic method questions to remind them they really did know. Then I pointed out specific small parts and asked "how would you do that piece in Fortran?". I saw that as "fake" Socratic, because I didn't know the answer myself, but I was confident they did know and just needed to apply the knowledge.

I ended up tutoring the entire semester without ever seeing a Fortran manual. By the end of the semester, my students had paid me quite a lot for the privilege of teaching me Fortran (I got a part time job doing some Fortran programming soon after that and never did need that manual). But they learned a lot more and got better grades than if they hadn't hired me.

I want to clarify that point. I was not talking about engineers who were unwilling to ask for help or unwilling to share the load (I have worked with some of them as well, but not the ones in the above anecdotes).

We are talking about experts in specialized fields who were unable to conceive of the possibility that someone who knew nothing about the field could be helpful in a hard problem within their specialty.

Even when I was helpful, it was still so inconceivable that someone without any relevant knowledge could have helped them, that they could not interpret what had just happened.

Can't remember where I heard this but it springs to mind -

A test to measure how indispensible you are.

1. Put some water in a glass
2. Put your finger in it
3. Take your finger out again
4. Measure the hole thats left behind.

ROTFL... yup, been there! Good recovery! :p