Asking Tom for an explanation
You're already handling the day-to-day well. You and Tom seem to have a good rapport, and he's happy to help. I don't see any conflict here, currently.
My question is this: Is there a way to ask him to be more in-depth in our emails about what I'm doing wrong without seeming like I'm trying to heap work onto him?
It's mostly a matter of phrasing. Instead of asking Tom to elaborate; point out your problem and ask Tom if he has any input. I would try to remain vague about what input to expect. That way, you give Tom the option of taking the easy way out (referring you to a good source of documentation), but also leave it open for Tom to write his own explanation.
A quick suggestion:
(1) From your earlier emails, I gather that my approach isn't the most efficient. I've been trying to expand my understanding of [tool], but the existing documentation is either sparse or nowhere to be found, and the forums don't see much activity lately.
(2) Are there any resources that you know of which help with explaining how to use [tool] efficiently? Or did you learn through experience? If so, do you have any tips on how I can get more experience with [tool], e.g. example exercises for common problems?
(3) If you have the time, could you maybe show me some examples of better approaches, so I can see the difference to my usual approach?
Notice the three paragraphs. They each boil down to a specific statement:
- I'm having trouble with learning more about [tool].
- Can you offer any tips/help with learning about [tool]?
- (optional) Here's a suggestion that I think would help me.
This leaves Tom with a range of responses to choose from:
- If Tom is willing to put in time and effort, he could draft you some documentation from his knowledge.
- If Tom knows anything relevant, he can quickly point it out (tips, references), in a way that his answer does not commit him to having to train you.
- If Tom knows nothing relevant, then he has the option of sympathizing with your issues in finding good documentation. This option allows him to essentially say "no" but still create a good rapport with you (instead of him coming across as unwilling to help).
But I think the interpersonal issue here is caused by a workplace issue. I'll add that in the next chapter. If it's not appropriate for your scenario, let me know and I'll remove it if you want.
Where is the management in all this?
You mentioned that Tom is willing to offload the work onto you; but you've been eerily silent about the company's involvement in the process.
Are they involved in any capacity? I would assume that you're their employee, and Tom is not (since he's hourly). That means that Tom is officially an external purchase, and I doubt you have the autonomy to make company purchases.
This is an inference, but I get the feeling that the company has tasked you with a job you're not well-trained for, and is leaving you to your own devices.
Keeping a good rapport with Tom, while beneficial to your job, is only a patch to the existing wound. It refers back to the old adage:
Give a man a fish, and you feed him for a day. Teach a man to fish, and you feed him for a lifetime.
You're asking Tom for fish. The company should be buying you a fishing rod and sending you to a fishing course.
Especially with Tom's impending retirement, will it become more important for you to become self-sufficient at using [tool]. What's going to happen when he does retire?
Anecdotally, this is the current situation I'm in. An employee who singlehandedly ran a software development department has retired, his work is passed on to someone else after they retired. The new person is nowhere near self-sufficient, and the client contracts supported by this software are a sizable chunk of the company's income.
Since the work needs to be done; the company has had to resort to hiring me as an external consultant to rework the old guy's work, and I'm costing them three times more than an internal employee to do so. It's not my job to tell them to not hire me, but objectively speaking, my presence is a financial punishment for the company's failure to plan ahead.
If the company does not involve itself in your situation now, they're likely going to end up in the same situation as my current company. Their infrastructure is relying on a tool that no one really knows how to manage (no offense intended to you :)), and if Tom is out of the picture, who's going to fix things?
This isn't even retirement related. What if Tom gets hit by a bus tomorrow?
If you come across a problem that's insurmountable, and Tom isn't there to help you, then what? THe only other option they have is replacing the tool, and that's not only going to cost them a lot, but the effects of the change will be felt in every part of the company that relies on [tool].
I think you need to take this to the company. Don't complain about a current problem, but do pull attention towards the future viability of maintaining [tool].
There are ways to solve this, which will be cheaper now, compared to when Tom is no longer there:
- If training courses exist for [tool], suggest that the company sends you on these courses.
- If Tom is still available for work, they could e.g. hire him to train you. Note that this is not the same as hiring Tom to work with you. They should dedicated time to lessons that are not hinging on active current problems with [tool].
- If no training is possible, they can allot some time for you to set up a sandbox environment so you can get some hands on experience. If you're an autodidact; that is.
But I do think it's essential that you approach the company. They're supposed to manage you; so it's their job to steer clear of future problems. You can only warn them of the future problems, you can't solve the problems if the root cause of the issue is that you're not equipped to solve the problems.
Failing to approach the company and warn them about this, can be a source of great interpersonal conflict in the future (between you and your boss), and can affect your employment and career as well.
The step-by-step approach is the same as when you asked Tom for help:
- Outline the future problems.
- Ask the company for their input.
- Offer any suggestions that you can think of.
For example:
(1) I've been working with [tool] for some time now. I find myself relying on Tom often, because I lack the needed documentation to be self-sufficient here. Sadly, there is not much documentation (nor support) to be found in the public domain. Tom has been helping me so far, but he is going to retire in the near future; and I currently do not feel sufficiently equipped to deal with the problems that arise with [tool] if I can't rely on Tom's guidance from time to time.
If we address this issue when Tom has already retired, I worry about coming across insurmountable problems. As our infrastructure relies on [tool], I feel it's imperative that we ensure its operability.
(2) Is there any internal documentation that I'm unaware of? Is there anyone else in the company experienced with [tool]?
(3) I'd like to get ahead of this problem, as postponing a solution will likely only compound the problem down the line. Would it be possible for us to hire Tom, not so much to have him solve the current problems, but rather to train me on effectively using [tool]?
[If applicable to you] Would it be possible to set up a sandbox environment for me, so I can tinker with [tool] and learn about its workings? It will require me to dedicate some time to it, but I could do this ad hoc, i.e. when there are no pressing issues that need to be resolved.