This is probably a lesson that is endlessly learned by new junior consultants. When new consultants get into consulting through the fluent practitioner route (as opposed to the "warm body contract job shop" route), they tend to make the common assumption everyone is as excited as they are about the field, and the only difference between them and their clients' staff is time-on-keyboard, and perhaps some perspective.

There is a distinct category of staff that the new consultant will encounter who immediately glom onto the convenience of treating the consultant as a personal Google service, with the added bonus of not even having to sift through the search results and handed the answer. Kind of a value add when the check-signing manager witnesses this happening first-hand; many appreciate getting confirmation they bought the services of an expert.

However, the trap is the new consultant assumes the staff member will leverage these answers to find their own new lessons to learn. Or even remember the answer. This becomes a significant time sink, so different consultants develop different ways with different clients to mitigate this anti-pattern. Nothing to fire a client over (to bring us back to the original topic), but definitely an issue you want to keep tactics to employ in your back pocket for.

For context, I have been in consulting roles for most of my career, probably because of my proclivity to be "unsolicited advice guy". I see something amiss and I tell people about it. My delivery has changed and matured over the years, but I still cannot correct flaw.

An epiphany I had a couple months ago, and this is after 20+ years of this work, is that consultants are primarily organizational psychologists. They bring a lot to the project and the org, but it isn't the technical that takes the highest position. And in the case of the repeat-help-desk-can't-fish customer there are a lot of different issues at play. Some of the charitable ones are

- lack of confidence

- risk of getting blamed

- over worked, too much responsibility compared to the skills

- unrealistic deadlines by their managers

- personal issues prevent a lack of focus and inability to do deep work

If you deliver the n-th answer like you delivered the zeroth answer, they will think you have an infinite capacity for taking their burden. There are signals you can use to push back, explain how busy you are, frame you answer relative to a previous answer, answer the question with 3 questions and some tasks that if completed will solve their problem (Socratic help desk).

Consultants should make their customers and all of their customers look like rock stars, but we shouldn't let folks within the org use your knowledge and skills to make themselves look better. This particular pattern is damaging because while to the rest of the org they look amazing, their ego erodes and they keep coming back to the oracle for more answers and at some point they are only a mindless conduit.

In the case of an employee who is using you as a 2nd brain, one technique is do a pomo of the issue, give them mad props for the debugging, development, patience, etc while outlining the problem and how it solved. Make a group effort while giving them some praise but don't allow them to consistently take center stage.

On the flip side, one can find the staff members how share knowledge within the org, and synthesize new solutions from previous ones. These folks need to be protected, cultivated and propped up, they will save projects and your ass if handled with care.

The delicate balance to effect here is employing the techniques you outlined, against the deliverables and maintaining good working relationships with staff you depend upon to deliver to you information you need to accomplish what you were brought in for. Unless you correctly read your client organization and staff who you will be interacting with, and correspondingly pad your estimates, carrying out these techniques become mostly or all unbillable work.

The technique of doing a pomo works really well for issues above a certain complexity level. Often I can get a manager to enthusiastically sign off on incrementally adding to the engagement on a time and materials basis on top of the outcome-based fee I bill for such knowledge transfers, typically as one or a series of lunch and learns.

Below a complexity level (for example, "how do I enable tracing in <foo>?"), and it rapidly becomes nonsensical, and I use a lightweight (to the consultant) version of what you recommended. Depending upon the personalities involved, and facilities available, I usually ask for the request be re-framed as a ticket "so the entire team can learn now from the answer, and datamine the knowledge base in the future", and I suggest to the manager that the requester be officially tasked with documenting the answer into the team's official documentation repository with an official documentation template, that a project manager will then start chasing down. I also recommend someone else on the team "QA" the documentation by performing the procedure as documented.

The documentation doesn't have to be fancy, even a single paragraph suffices in some cases, but usually there is a lot of red tape involved. This delivers genuine benefits from the leadership's perspective, and for genuine "the organization didn't know how to do this", it does advance the organization's capabilities. The bonus for the consultant is it puts you back in the consulting seat, where you point towards how it is done in sufficient detail so someone can put together the steps (you might call out one or more particularly tricky steps, but usually just pointing in the right direction is enough), but the person doing the asking becomes responsible for proving and documenting the steps to their peers, project manager and manager. This cuts down on the frivolous requests to pretty much trivial amounts in my personal experience, without compromising on leadership's nor staff's desires.

I have been trying to re-route RTFM queries to inside the org by putting in support structures where there were previously none, as well as working on some training sessions that are basically "how to avoid RTFM queries" but in a respectful way.