How to prevent being used as a personal encyclopedia by coworkers?

Question

I happen to be the technical expert in our company, in a relatively niche field we base our products on, so the knowledge I possess is not easily searchable on the open web. Besides development tasks, I naturally have the task of helping my colleagues with technical questions they have, and whenever they need detailed information about how our products work and about the technologies we use.

That's not a problem, I enjoy doing it. What I don't enjoy is that people tend to forget the answers I provided them, and ask the same questions again and again. And again. It's not that they didn't understand the answer, often it happens that they need an explanation, and after I provided it, they claim they understood it, and it seems they were honest with it, as it did indeed solve their problem. Half a year later they happen to come across the same problem (or a very similar one), and as if they forgot it, they turn to me again before spending even the shortest time to try figuring it out or searching their notes or emails. Or sometimes a few weeks after I solved the problem for them (this alone is OK, that's why I'm here), they have the same problem again and they turn to me again, as if they forgot the solution.

Sometimes the communication is personal or over the phone, but most often it's via e-mail.

I even created an internal wiki and something like a FAQ list, but for many people it seems much simpler to write me a quick e-mail than to open the wiki, or to search their inbox where the question might have already been answered by me some months ago.

Of course, the bluntest way for me would be to just reply "I already answered that, don't be lazy and learn to use the search function in your e-mail app" but I don't want to be so extremely hostile. But I also don't want to waste my time to explain things again.

So I went with an approach in-between those two extremes. I provide a very short explanation, and casually add to the end "for more details, see my mail from <date>", with the hope they realize by themselves the stupidity of having asked (for the umpteenth time) the same question again. For some people it seems to work, for others I just skip the short explanation and only refer to the mail.

With colleagues who do this very often, I usually don't answer instantly, but wait a while with my reply, so that next time they might be incentivized to search a little before turning to me.

This approach seems to have lessened the burden somewhat, but it still happens, and sometimes I feel I'm used as an encyclopedia or a search engine by people who think it's more easy to drop me a quick mail instead of searching it themselves.

For those who would suggest escalation: I have a quite large independence already, and I also don't want to be whiny. Also, with the approaches listed above, I already lessened the problem somewhat, I only asked this question for hints how to further reduce it.

Answer 1

Short Answer: Why would someone spend time searching/reading a wiki when they can just ask you and you'll give them want they want? You need to stop making it so easy for them to get what they want from you. In the long run, it's better for everyone because one day you might not be available and they need to know how to function without you.

Longer answer: Unfortunately, you've helped set up a scenario where everyone knows they can get easy answers from you. This eventually wears you down and ultimately leads to your own drop in productivity because you spend all your time dispensing knowledge (like an ATM) and not getting any of your own work done.

When everyone is busy, it seems like the easiest way to get rid of the distraction and get back to what you were working on is to give the easy answer, rather than teaching them how to solve the problems. But that's what sets up this dependency on you.

The first thing to do is train yourself to not give out an easy answer. Respond with open ended questions to help guide them to the right answer. For example, "Why doesn't the code work?" could be answered with, "What does the debugger show when you step through it?" And "Where can I find this document?" can be answered with "Where have you looked already?"

Next, and this is the key, you must not respond immediately. This is a time (and sanity) management technique for yourself. You should set aside a specific block of time for answering questions. You can respond to emails at this time (using good guiding questions, still). If people drop by your door to ask questions, you can simply tell them that you will get back to them at whatever time you've set aside for responding.

You will be amazed at how good people actually are at solving their own problems when they don't get quick and easy answers from you. You might feel like a jerk at first, but if you plan a time to respond, then you're not being a jerk, you're just practicing good time management, which is good for everyone. It will take time to wean people and break this habit, but it will be worth it.

Answer 2

Some options:

• Give them a non-answer (ideally just vaguely delaying) and tell them where the question is answered, without linking to it. For this, a wiki is generally better than an email, since that's what a wiki is made for (any given person may not really think of email as a searchable archive).

  I will need to check my notes to answer this.

  You may want to find the answer to this on the wiki in the meantime.

  Just be very sure that it is actually where you say it is.

  Let them be the ones to follow up if they haven't found it, at which point you can respond "found it" with a link (as detailed below).

  There's a chance of this response making you come across as not that knowledgeable or somewhat forgetful (note that I specifically avoided "I forgot" or "I don't know"), but they should quickly internalise that asking you should not be their first option.

• A more extreme version of the above is to bluntly point them to the wiki with no link or implication of anything happening on your side.

  You can find the answer to this on the wiki.

  Let me know if you're having trouble navigating the wiki.

  If they come back with an "I can't find it", you can go down the path of asking them how they search and discussing possible improvements to the wiki (still not directly answering their question).

  This is the least friendly option, but should bring the point across the most clearly.

• As you've already done, link to the wiki, attached the email or forward them the email again without answering the question directly.

  You can find the answer below / in the below link / in the attached email.

  Let me know if something is unclear.

  They may still turn to you first if you use this response, but one would hope they'd eventually realise your responses are just directly referencing where they could've started looking for an answer.

  If there isn't a wiki page on it yet, you can start by writing a wiki page and use a similar response:

  I wrote a wiki page on this for you:

  [Link]

  Let me know if something is unclear.

---

There's also perhaps the question of how easy it is to find the information on the wiki or in their past emails.

There's a chance that they've searched but failed to find it since they couldn't use the correct search terms.

If this is at least part of the problem, you could:

• Start by searching for how they phrased the question and make sure you can find the relevant page.

• Try to make it easily searchable by phrasing it how the question is likely to be searched for or including terms specifically to make searching for it easier on the page itself.

• Categorise the wiki well so it's easy and intuitive to just click around without even needing to use search at all.

This is going by the assumption of there being a search box instead of everything being on the same page or needing to click around a bunch to find what you're looking for. If there isn't, you may want to look into wiki services, which will handle this for you (you could probably find some free ones).

Answer 3

Immediately respond to the email as soon as you see it:

I'm afraid I don't have time to write an explanation right now. Please check the wiki [link] , and let me know if it's missing the information you need.

Please remember to bookmark the wiki for quick answers to similar questions!

Then go on with your day. If they are still stuck, they'll email you again, and at that point you can check the wiki. If it exists, read it to make sure they'll understand how it pertains to their specific inquiry, and provide a link directly to the answer:

The wiki addresses this issue here [deep link] - Please let me know if this doesn't resolve your problem, and what you've done so far to resolve it, and I'll update the wiki.

Please remember to bookmark the wiki for quick answers to similar questions!

If the wiki doesn't contain the answer, then write it up on the wiki and then email them the link:

I've added that information to the wiki: [deep link] Let me know if this doesn't solve your problem.

Please remember to bookmark the wiki for quick answers to similar questions!

Never provide the information over email. Use the wiki exclusively, link to it, refer to it, but never quote it or skip it.

You will always have a few people who will never refer to the wiki. They won't be very productive, and if they are bothering you daily, then you should have a discussion with your boss to suggest they have a discussion with that worker's boss, to have a discussion with the worker about abusing internal resources when the wiki is available. Don't make it about being annoyed - suggest that every interruption is a distraction and you'd like to focus your attention on other aspects of your work, that they are wasting their own time in addition to yours for something that already exists.

Others will eventually get so used to seeing the wiki with your links that they will eventually check it first.

The biggest change from what you're doing now is 1) never give the answer in the email, always link to the wiki, and 2) always provide a link to the wiki and a reminder to bookmark it and check it first before emailing you.

They know they're going to have to go to the wiki eventually, once you stop doling out answers in email, so they will get used to using it, and for some that will be enough.

Answer 4

They write the wiki

You make a deal with the staff:

• You agree to graciously accept any question during your designated “office hour” as does a professor at a university.
• They agree to write up the results every time to every question, posting on the wiki. They must take notes during your consultation, as material for their write-up. The write-up is done that same day. They must notify you when write-up is posted.
  • If a page on the wiki already covers their question, you agree to go over the material again as long as they agree to revise and clarify that wiki page.
  • Where appropriate, for general questions not tied into your business, they may choose to post to a Stack Exchange site instead of your wiki.

Any question not worth their effort to comply is not worth your effort to answer.

You never touch the wiki again. If their write-up is poor or insufficient, you give them a criticism at the next office hour and they are expected to revise the wiki.

This only works if you are strict: No exceptions, no “free rides”, no “quick questions”.

This approach neatly resolves your issues:

• Natural filtering system. Any simple question is more easily resolved on their own by googling/binging than waiting until your office hour and then having to write a solution.
• Your efforts shift to the part you enjoy: Answering interesting questions with the pleasure of teaching.
• Interruptions are eliminated.
• Distractions in your email are gone. They must visit you during the appointed hour.
• The wiki grows richer with minimal effort by you. You only need to perform some quick reviews.
• No more “forgetting” the solution. Writing cements the knowledge in their mind.
• Those with weak writing skills will improve gradually. That's a win for them, you, and the company.
• The negativity evaporates. No need for you to chide them about not putting in effort or having to repeat yourself. If they fail to abide the terms, you drop them as a “student” until they agree to the terms; no argument and no emotion – just a fact. No hard feelings, they remain your colleague and all is well except that you will not take questions unrelated to your own work. You become more of a mentor, less of a parent.

Answer 5

Start asking "What did you try?". Do not provide additional information, wait for their response, even if the question is new and unanswered. If the answer is some bullshit about "it's not in the wiki", insist, "What exactly did you search ?". Make them follow the steps needed to find the solution, do not point them to the solution.

Also, do not spoon feed them! Whatever you do, do not provide the solution verbatim, make them work for it, it will promote understanding of the issue and provide them with the tools needed to think for themselves next time.

Of course it won't be a quick fix, but they will eventually come around.

Answer 6

You are doing well - there nothing much that you can do, to be honest. Some points that you can try to improve your situation:

• Improve (publicise) the access to the Wiki. The easier to find & access it, the less people will come finding you.

• Wait even more time before answering - days if necessary. If someone complains, tell them that you are busy, and point them over to your FAQ/Wiki instead.

• Try to hire someone to help you. Even if yours is a very niche field, there must be a way of finding someone else (maybe even a friend?) within your same field of expertise.

Also, it can be interesting to use this situation as leverage with management. In addition to get new people helping you, you should keep track of all the problems you are helping solving around the company. These are the kind of things that in the end help getting raises/promotions (specially when you are the only one that can provide such support).

Answer 7

(I'm assuming you work in software development, so I refer to your current official duties as 'development', but if that assumption is incorrect, feel free to make the necessary changes, since the thrust of this answer doesn't depend upon the actual duties under consideration.)

This question and its answers take a personal approach, trying to answer the question "How do I get the rest of the company to stop seeing me as the expert in this field?" in terms of your own choices and habits, both diagnosing those habits which landed you in this situation and offering suggestions with which you may, as an individual, attenuate the problem. But the problem isn't with you or with anything you, as an individual, have done. It's a systemic problem with your company.

The problem is that you're a silo of information, and a mission-critical one at that, from what we read in your opening line. The only durable solution, both in terms of clearing your workload and preventing the company from going under if you get hit by a bus, is to de-silo this information by creating more subject-matter experts with your skills and expertise within the company. This can either be done through hiring new people with your set of skills or by deepening the knowledge of a subset of the current staff. Either way, it's not your responsibility, it's that of your company; it takes investment, and entails a certain amount of risk, but it's also incredibly risky for a whole company to lynchpin their flagship onto a single source of information (as long as that information source/SME is a fallible human who is subject to illness, calamity, caprice, or simple ennui-leading-to-career-change).

There are two potential solutions to this problem that you could initiate, presuming you want to solve the problem instead of simply attenuating it. They both involve a frank sit-down with an executive (or more than one) explaining that the strategy they've pursued thus far in hiring, promoting, and relying upon a single individual with critical understanding of their infrastructure was great for you personally, but that it's a mistake to stake the entire organisation's future upon your continued good health and recognizance. They need to start an initiative to attract or educate more people with your skillset, not to take the workload off of you but to mitigate the risk to them if and when you fall ill, or move on, or retire, or any one of an uncountable number of unforeseeable events that could well lead to the loss of the company.

In the first scenario, you offer to train a potential team lead, whose team you'll join and (at least for a while) be the most senior member of. In the second scenario, you offer to be the team lead, which would move you more officially out of full-time development and into a managerial position. In either case, this new "core" team would collectively become the source of information, and so rather than every developer in the company barking up your tree, you'll be either the lead or the senior-most developer of the team that the other developers will consult. This will both limit your direct exposure to these repeated queries as well as inure the company to the certainty that they will one day be unable to rely upon you as a resource.

Both of these scenarios come with a reduction in independence, but the independence was, in a way, the root cause of the problem you're describing. If compromising your independence by either joining or leading a team of SMEs (with the attendant experience you'll be able to put on your CV) doesn't appeal, then you can attempt to attenuate the problem in the manner the other answers describe, but the problem will never fully go away. To be clear, it won't fully go away with my suggestion, either...but that's just the nature of being an expert. By definition, you'll know more about your field than almost everyone else. At least by attracting or training more experts, both your company and yourself will be at less risk of a meltdown.

Answer 8

Expand a little on what you already do

Make their impatience level exceed their laziness.

First Repeat

Ask them why your solution from the last time you answered the question doesn't solve the issue now.

If they reply along the lines of "oh I lost the email" or "oh, I forgot can you just tell me again?" then you reply with "I don't know where the email is right now myself, give me some time to find it. It may also be on the wiki, give some time to search that too."

Then, don't do anything at this point.

Second Repeat

If they come back, just say "sorry, I totally forgot - I'll try to get that in my work schedule this week. But, if you need it sooner, it may best for you to search the wiki".

Wait again.

Third Repeat

If they come back a third time, make them wait for you to search the wiki while they watch. Then send the link to them. If they want an explanation, tell them you'll have to schedule a meeting as you are heads down on a project right now.

Slowly, over time, their lack patience will overcome their laziness and they'll start to do it themselves.

Answer 9

I think your current approach is optimal.

Your wording is great: polite and informative but laden with "RTFM" nuance. When people don't get the hint, you inject a little delay to spur them into their own research and hopefully the realisation that they're capable of discovering information themselves.

If those people still don't get the hint, there's nothing you can do. You'll just have to continue tutting about them. I'm sorry.

Answer 10

Teach them how to learn

Having fallen into the role of 'personal encyclopedia' myself, I can tell you how to handle it.

The saying 'give a man a fish, and he will eat for a day, teach a man how to fish, and he'll be full for the rest of his life' applies aptly here. Don't aim to give them the answer to their question, aim to give them the tools to answer it with. If you only given them a fish, when they become hungry, they'll will just ask you for more.

In your case you've created a wiki, but that's equal to opening up your own fish store, which you have to run and maintain. When someone asks you how to do X, don't say 'this is how you do X', recall how you learned to do X, then gently encourage them on this method of learning.

So for example, if they say 'What's the standard text formatting rules for our forms?', and you learned it from the companies' sheet, you'd reply 'Have you checked the company's sheet?'. If they say no, simply say 'I think the answer to it might be there.'

Don't give them the answer, give them the means to find out the answer.

If someone says 'What's the console command for XYZ?', and you learned it from your line manager called Frank, say 'Ask Frank, he should know the console command for XYZ.' If you learned it from a manual, say 'Check the manual'. If they ask 'Do you know it?' just say 'I'm not sure, manual should have the answer'. Even if you are sure of the answer, you're directing them where to find it directly (which eventually they will go to directly, cutting out the middle man, IE you).

Delegate to other resources and tools to the extreme!

Best way to solve a gap in people's knowledge is not to impart knowledge, but impart how to learn the knowledge. Sometimes this requires you allow them to struggle with finding an answer for a bit. If it seems too personal to say 'Have you...', you can lead by example by saying 'Sometimes I use the W3C resource as a point of reference for XYZ' (don't say this sarcastically, but in an upbeat, matter-of-fact tone of voice).

I find this works wonders. And people will appreciate it more because you're teaching them how to learn new stuff (I find once I show a person a resource, they happily devour it for whatever knowledge they're after, and then they become encyclopedias).

Answer 11

Their behaviour is unsurprising; they have a low cost strategy that is proven to be successful. 6 months is a long period to retain information you've not needed to apply.

Creating the wiki is a good step but if you want to discourage a behaviour then you need to increase the cost of the behaviour, which is preferable to the alternative; reducing the behaviour's success (e.g. by giving them sub-par information).

You can promote the use of the wiki by requesting, or suggesting a process be enforced, where the consumer of the information you provide becomes responsible for updating the wiki. The increased cost to them is then justified by the value added to the shared knowledge base, which they have now invested work into and would prefer to consult in favour of risking the responsibility of an update.

If successful, the benefits are potentially many: the effort of documenting is offloaded from yourself (though you may need to assist the process); their domain knowledge increases, and is more likely to be retained, through the act of documenting; and an additional resource to consult means knowledge is easily shared to new or forgetful colleagues (i.e. repeat offenders).

As the domain expert it is your responsibility to ensure what is documented is coherent and useful, otherwise no value is ever gained, so it is in your interest to review what is documented and provide feedback. You should be in a position to promote the documenting, even if you can't get a process enforced officially, given you are the gateway to the information that is not yet documented.

Answer 12

One thing I think you should do is have much less faith in the usefulness of email records as an information repository.

It's surprisingly difficult to track down an email where someone explained something to you when there's lots of other emails flying around. And remember that they're not domain experts; they may vaguely remember a discussion with you on a particular topic, but they're much less likely than you are to identify the correct keywords they should use to find that email again. If they don't thoroughly understand the topic they're also less likely to realise that a previous conversation that solved a closely related problem for them already contains everything they needed to solve their current problem because they don't know what they don't know.

And no matter how perfect your email information is (either because the recipients remember it forever, or always find that email again when they need it), that still only helps the people who received that email. So any email that you're needing to refer back to with "for more details see my email on " should probably be posted on the wiki instead, so other people can find it.

Most of the other answers here have focussed on making yourself less valuable as an information source, so that people are more likely to find their answers elsewhere. And you've been trying that yourself a bit, with not answering questions immediately if they come from repeat offenders. But I'm going to suggest instead that you focus (instead or as well) on trying to make other information sources more valuable.

A key problem with information repositories (like wikis) is discoverability. How easy is it to find what you need on your company's wiki? My company's one is terrible. Searching for general keywords in titles results rarely finds what I need, and searching for keywords anywhere in the article results in way too many articles (many of them obsolete); the right one is buried in the noise. The top-level organisation of the wiki is divided roughly along functional groups, so to find something by navigating from the top I need to figure out "which group is most likely to have originally written about this topic, when it was originally written about" (assuming there actually is an article on this topic specifically, rather than information being hidden in other articles or just not present at all), but the group structure and responsibilities haven't stayed static and plenty of potential topics touch on multiple groups. The net result is that I can basically only find specific articles I already know exist (either by remembering the title closely enough, or knowing enough of the "rare" keywords that the article contains to narrow down the search without.

I'm also one of the technical experts at my company, and I've been here a long time. Imagine how much worse it would be for people who don't fully understand the domain yet, don't know all the right terminology and linkage between concepts, and haven't yet built up a good mental model of how the wiki is organised and where they're likely to find things. The sad irony is that when you don't understand a lot about an area it's also much harder to find the information that will help you increase your understanding. It can be much easier to seek help from known experts (especially as getting that also gives them the "blessing" of an authority figure that what they're doing/thinking is reasonable). It can be very hard for people to get out of that mode, if the information repositories are daunting and/or rarely lead them to a solution they can be confident about. Because they don't find the information stores very helpful they don't use them, which means they don't get better at using them so they never become more helpful.

So I'd suggest that when someone comes to you for help treat it as almost a "bug report" for the information stores you have. Ask them for more details on what happened when they tried to find information about their problem, and why it didn't work. But don't ask as an accusation that they should have found it for themselves, but rather ask as a source of information for how you can make the information more discoverable for next time.¹

Is the information not actually there yet? Are they searching for the wrong thing? Does the content need some organisation with top-level "starter" pages linking to more details? What top-level organisation would serve the needs of people looking for information (start pages by product, by problem domain, etc) - and which people (there are probably different groups with different needs)? D you need to link some articles to each other? Is it just not widely known that there is an FAQ? Are the questions on the FAQ too specific, or too general (it needs to be clear to the person skimming the questions which ones connect with what they need now, and the connection needs to be clear before they've read the answer). Do you need links in heavily domain-specific source code to the wiki articles likely to be relevant to people who need to work on the code? Is there a good place in the code to embed those links where they'll be found? Do you need to train people specifically on how you've organised things and how you intend things to be found?

In short, merely having all the relevant information recorded (either in peoples' email achives or publicly on a wiki) is not the same thing as having it discoverable by the people who need it, when they need it. Improving the latter could help you (and everyone else) a great deal.

---

¹ Inevitably there will be people who just can't be bothered, either habitually or just at that moment. But treating questions that come to you as a potential failure of the information stores and trying to "debug" the failure sets the expectation that asking you personally is the "fallback" mechanism, and will still have the effect of making people embarrassed if they come to you without having tried to find the answers first.

Answer 13

I disagree with the answers given where the core action is simply to make it more difficult to reach the OP with questions.

The OP has some mission-critical knowledge that the others do not possess, but that they need to know in order to be effective in their work. The best way to approach this problem is to deliberately train the others. A workshop where people can ask questions and work through real problems together will develop confidence, and eventually, self-sufficiency.

Some students will thrive and become experts themselves and be able to answer questions that would have otherwise gone to the OP.

Of course this will take work and time from the OP. Running a few sessions of workshop lasting 1-2 hours each is serious a time commitment. This will be seen as "spoon-feeding" by some, but actually, this is called TRAINING. It works and it is the quickest way to get people up to speed.

Answer 14

I've been in the same situation and have to disagree with most of the answers here. Delaying your answers and making them less helpful makes you a jerk in my eyes.

My experience is that some people will never be able to advance beyond a certain level of understanding. In my case, it is simple physics, and trying to educate others was simply a waste of time, and annoying for them as well.

I also collected a Wiki and referred to it in my answers. Did not help - they still came asking. In my case, the worst department was one with a high turnover, so every 6 months a new person would ask the same question.

My recommendation is to collect some boilerplate and send that out instead. Yes, the answers will be longer than the ones you write specifically, but it will cost you almost no time. I did this at the end of the day at the latest, so people did not have to wait undue time. They need the answers to do their work, so delaying the answers will keep them from being productive.

In my eyes, there are three levels of understanding:

1. When you get something explained and it sounds plausible, you think to have understood it. That is the level of your coworkers.
2. When you think it over independently, and you are still able to piece all parts together correctly, you are at level 2. Your coworkers seem not to have the basis to advance to this level.
3. You have really mastered a topic only when you are able to explain it to others. This is the level you are at. Face it, some people will never get there, be it for lack of interest, schooling or intelligence.

Answer 15

So... I am not the biggest fan of these ideas where you should necessarily set up office hours or demand a pay raise or what have you. I mean, they do have a kernel of truth to them but the kernel is this:

• Your time is valuable.

When someone pops an email over to you and you aren't doing anything, sure, go ahead and answer their question and then when you're done refer them to the wiki you set up on the subject. That's just being polite and at least some people will prefer to use that medium instead of having to wait for you. On the other hand, if this isn't actually part of your job description and you're in the middle of something that is, don't even think twice about waiting to answer that person until you're done / free. If it's going to be a while, sure, send off that quick "sorry, I can't reply; I'm in the middle of something" email before going back to your job. The same goes if you get an email on a break or a lunch; that is your time, not your company's and not your co-workers'.

If someone gets bothered by the fact that you are putting your own work in front of theirs, I'd just politely explain to them that you set up the wiki on your own precisely so that you wouldn't be interrupted like that. If that person persists or gets snotty, talk to your supervisor (or theirs, if the chain of command works that way; I will add, though, that even in the most informal of working environments you should always try to go up through your own chain of command).

I think what you want to avoid - and I think you were clear in agreeing with this ahead of time - is making yourself so available that your own work suffers. That doesn't help anybody. I think you also want to avoid getting into a position where doing this plus your own job means you're basically doing 1.5 times as much work as everyone else; aside from the notion that you aren't getting paid enough for that (which I feel is almost besides the point) you'll risk getting burnt out. So if you get pushback from your higher-ups when you take a while to answer some questions, I think you have to make them make a decision as to whether or not mentoring is part of your job description, and if it is, make them give you a lighter load in your "regular" job to make up for it.

On the flip side, though, I do feel like if your position has a bit of downtime at the moment you ought to consider filling it by being extra helpful and social with your other co-workers, especially when they ask you questions like this. There are a whole bunch of ways you can become indispensable to your company, bad ones (like writing code that only you can decipher) and good ones (like being the "go to" for a particular piece of technology). The wiki is a great idea in that it allows you to demonstrate that you are trying to raise the bus factor, but the fact that people seek you out to get help makes you an asset to your company if you play it right.

Answer 16

... so the knowledge I possess is not easily searchable on the open web

Creating an internal wiki is a great start, but please consider posting a self-answered question on StackOverflow.

This will make their questions searchable and help others looking to solve the same problems.

Answer 17

You're doing a lot of things right. My advice to you is a multi-pronged strategy. Some of this will sound redundant with other answers. I mention them anyway, because they are all part of the strategy. (If I only presented the new info, my answer would not be very self-contained.) Plus, I agree with the points I'm re-iterating, so strongly that I think redundant mentioning is a good thing. I happily join the choir of voices that say some of the same things.

Require Searching

The first prong is: make sure people use the internal resources.

As a policy that you enforce (more information on enforcement is in the "Team Effort" "section of this answer"/"prong of this strategy"), when people ask you questions, they must provide:

• A clear description of what they are after
  • This could be information they want, or something else, such as permission for something
• What were the results of trying to find the information, and in what way were those results unclear/insufficient?
  • The search is expected to include internal documentation
  • The search is expected to include ticket history
  • The search is expected to include public web
• Recommendations (or at least, what do I think makes sense to do next) should be provided
  • If the experienced people can read faster than they can type, this can often result in them needing to type less. They can hopefully just say "Yes".
  • This helps provide some insight into what the less experienced people may be thinking, which might expose some deficiencies so that training can be provided. (That might be training related to the process of doing their job, or more specific training about specific internal resources.)

    Sometimes less experienced people might have more genuine troubles than experienced people, like a lack of a required security permission that experienced people have (and don't often think about). Getting their input may help expose such troubles so they may be rectified.

They are, very simply, not allowed to just ask, "Help me." If they do, they are required to "Follow the process". That means, they provide the above information.

If they don't provide that information, then you take the time to invest in your co-worker, by not providing them with the answer, but providing them with the requirements. "I don't see any reference showing the results of your search for this answer. Please explain what was searched, and what was found. (Then I will happily fill in the missing pieces.)" *

• As a bonus, since the question was asked, you're welcome to cheat. Start writing up the answer for the next E-Mail when they tell you what's happening, and maybe modify the documentation if it is insufficient.

Have Documentation

It sounds like you are happy to refer people to old E-Mails. Stop that.

E-Mails are not usually a key documentation source:

• One problem is that they often have lots of information that are specific to a situation. If someone else needs to access that E-Mail, they have to filter out all of the details that aren't relevant
  • When you quit, your E-Mails will likely be purged. The alternative is that someone copies your E-Mails into a decent documentation format. In my experience, that is quite uncommon.

    (Usually they decide just to invest effort in re-creating it, which has the benefit of being more up to date, but the cost of re-creating this. One reason is because having someone else go through your E-Mails to separate gems from coal is time consuming, and that cost often sways things in the direction of creating from scratch. Another possible reason for this is the feeling that going through all your E-Mails may be a bit disrespectful, making that unattractive.)

    The solution to this is: you be that person. You're among the most familiar person with the E-Mails in your mailbox, especially if you were the author. You be the person who puts the info in your centralized documentation.

• New people don't have access to the old E-Mails. Re-sending them a copy of the E-Mail is time-consuming for the experts. It is better that the information be in a centralized database that they can use.
• Many people like to delete old E-Mails. This reduces burden on E-Mail storage systems. It is better to have documentation be served by technical systems that are designed for the purposes of long term storage and easy retrievability of information that has been sitting for a while.

Basically, if you need to refer to an old E-Mail, it means that you didn't correctly foresee the need for someone to ask this again. Which means you didn't succeed at getting the information into one of the public documentation resources. This is an understandable oversight; we're all less than perfect at predicting everything every time. Just do the right thing to take care of the results of this problem: Get the information out of just being in your E-Mail, and place it on an internal documentation resource. Stop relying so much on old E-Mails.

You mentioned a documentation resource. (You called it a wiki.) Great.

Another source of documentation, which I've found can be very useful, is ticket history. When work is assigned, people are required to document what they've done.

• It removes you from the burden of "Remember when...", because they should have bumped into that themselves.
• Another benefit from this is that you end up having multiple people contributing to the documentation.

Team Effort

I have seen this work very well in an environment where there were multiple people with greater expertise in the company. Those with expertise all got behind the efforts of making sure people with less expertise are following the process.

I have seen this work multiple times. (In other words, we had new staff members come on multiple occasions.) Each time, the process was the same:

1. New staff didn't know about our internal resources, or even our internal processes
2. We enforced the internal process of requiring search, especially until it was clear that they were as comfortable as any of the rest of us at using internal resources
   • This process may take around 1-3 weeks before they instinctively trust that they absolutely must follow the process, or else it just takes them longer anyway (and makes them look less good). Then, they heavily reduce how often they do that.
   • Still, they linger on doing that until 2¹/₂-4 months after hire date. By that point, they start being more trusted to have done simple searching before unnecessarily sapping other technical resources. Until then, experienced staff remain cautious about what information is just easily provided.
     • (These time frames are just some of my estimates based on some memory.)

I totally remember a conversation:

• New guy knowingly violates policy, and asks question
• Experienced guy: "What were your search results?"
• New guy, speaking honestly: "I didn't do the search. Because, you're right there, and the most convenient thing for me to do is to just ask you real quick."
• Experienced guy: "I totally understand that. But the thing is, I'm just doing the most convenient thing for me to do. And that is to just quickly say, "What are the search results?" (And send you back, on your way to go do a task without requiring me.)

Both were laughing as the new guy was just totally caught red-handed at violating the policy, which means he is doomed to being given less benefit of the doubt, which means the experienced staff who witnessed this will be less inclined to give quick answers and be more inclined to make sure the process is completely (albeit painfully) beaten into the new staff.

The strategy I mention should have management buy-in. Make sure that the process is actually required; that it is a requirement dictated by management. (That is much easier if you are a manager.) If you don't have management buy-in, your success will be more limited. (Some may say you're doomed to fail. I say you might have limited success at simply managing how people interact with you. But, really, you want a more wide-scale success/effort, and that might impose some requirements on your environment, possibly changing culture a bit from what currently occurs. That will happen much better, if at all, with management's buy-in.)

Your position

We all agree that you're valuable. (Well, maybe we're just giving you the benefit of the doubt, trusting what you say. But, I think most of the people here are comfortable operating under that assumption.)

Fattie's comment mentioned you need a raise. Seth Greylyn's answer called you a "mission-critical" silo. teego1967's answer says you need to train.

The problem with Fattie's suggestion is simply this: if the company were to give a raise (which companies typically don't particularly like to do), then that doesn't resolve the problem: You're still in the same situation, and you're not going to just keep getting raises infinitely.

What you're going to want to do is to make sure you're a leader. That may mean getting a new position/title. That may mean getting promoted.

Some of the rest of this might not apply if you officially are already a manager. (I'm writing these suggestions under the assumption that you might not yet be.)

Whether you've previously realized it or not, you're getting to be management-type material. You are a leader, to at least some extent. Formalize that, so that you don't have power/obstacles getting in your way. Then, instead of your actions looking like you are "trying to exert power over his peers", which is often seen as a more negative thing, you can be "applying oversight to those under him", which may be seen as a more positive thing.

To do that, make sure that some of your official duties involve oversight/training/etc. You might also want to include documenting as a key role. Since you're going to be doing these helpful things anyway, it makes sense to be (officially) recognized as someone from whom it is proper to be doing these managerial-like things.

Even if you haven't thought of yourself as a manager to date, you're at least on the verge of being in that role. So, if you're not ready to make a daring move (by proposing a change in your official position), at least start making the move mentally, preparing yourself for the adjustment that happens as you become one of the experienced folks that other people rely on. When you've decided what you want, which will work well for you in the long term, then seek to formalize that. (Also, while you're at it, see if the "promotion" can come with the raise that Fattie was suggesting.)

Summary

My two recommendations for you are:

• Deploy a multi-pronged strategy:
  • Require searching
    • Require a description of what they want, results of searching, and recommendation of next step
  • Require documentation be used
  • Make this a team effort
• Seek promotion (if that's still needed)

Answer 18

I have been in this position myself, albeit as part of a small team of designated experts, and we tried most of the strategies listed in other answers with limited success. Eventually, I left that company, and now have a role where being the expert is less intrinsic to my job description.

Unfortunately, the only thing that will actually work is support from management for you to migrate away from being the expert. My guess, from experience, is that at least part of the time, people are coming to you because their supervisors have told them to. I also discovered when I was in your position, that there were occasions when said supervisors specifically told their employees NOT to attempt to 'waste their time' figuring out the answers themselves, but go straight to the experts.

In short, there are many strategies that could work, but they are all in danger of failing unless the managers of the employees using you as a walking encyclopedia support the process of their employees becoming knowledgeable and using your free service less.

Answer 19

One of easiest get away is to ask them to send you an email and then have some boiler plate emails ready for repeated questions.

I use this strategy to deal with recruitment agents. They try to ask me different questions and when I ask them to email me... they never actually DO...