What our appetite for AI reveals about the help we have been missing.
You can need help at work and still decide it is easier not to ask. The question may be ordinary, but the response is less predictable. Someone knows the answer. Whether they have the time, patience, or willingness to explain it is another matter.
I have spent much of my career on both sides of that exchange. I have needed guidance from senior engineers who resented being asked, and I have been the person expected to help employees use technology nobody had prepared them to operate. I understand the frustration of needing an explanation and the burden of becoming everyone else’s.
When a company hires for potential without providing mentorship, or assumes proficiency without establishing it, learning becomes something employees negotiate among themselves. The person asking needs understanding. The person answering has responsibilities of their own. Whatever the organization failed to prepare for becomes a recurring interruption between them.
That experience shapes how I look at the appeal of workplace chatbots. I think part of the attraction is the opportunity to ask without that negotiation. A person can describe a problem imperfectly, request another explanation, or admit they lost the thread without first deciding whether the question will make them look unqualified.
An accessible answer is not necessarily a reliable one, and a chatbot does not fulfill an employer’s responsibility to develop its people. But dismissing the appeal as laziness misses the person trying to understand before acting, asking somewhere else because the help around them has become difficult to use.
The technology deserves scrutiny. So do the working conditions that make asking a machine feel like relief.
You Should Already Know This
At one MSP, the lead engineer was reluctant to be the knowledge base for everyone around him. He would provide part of an answer, leave you to work through the rest, and step in later when the situation became a problem with the client. Help was available once the consequences became urgent, but less available when an explanation might have prevented them. In another environment, walking into the senior engineer’s office with a question could produce more irritation than guidance. The response left little doubt that he believed you should already know, even though the company hired junior, lower-paid employees it expected to develop.
I remember asking him why a client’s nightly backups kept failing on the same server. He told me to check the retention settings and went back to his queue. The retention settings were fine. A week later, after the client had called twice and the account manager had joined the thread, he found the real cause in about five minutes: a scheduled antivirus scan was locking the files the job needed. The fix was trivial. What I lacked was the instinct that told him where to look.
I once called this pattern 20/80 Training: a short overview, then the remaining 80 percent left for the new person to work out alone. Leaving part of a problem for someone to solve can be good teaching when it comes with review and follow-through, and research on help-seeking at work finds that asking to be shown how serves people better than asking to have the work done for them. Without the review, it is a junior employee absorbing uncertainty until a client escalation forces someone to step in.
Their inexperience was acceptable when setting compensation. It became an inconvenience when someone had to help them acquire experience. A company cannot build its staffing model around developing people while treating their need for development as an interruption. Hiring for potential requires someone to explain unfamiliar work, review decisions, correct misunderstandings, and remain involved long enough for judgment to develop. Without that investment, the company has not created a development path. It has hired people who need one and left them to find it.
The senior engineer’s position deserves examination too. Being technically capable does not automatically make someone a good teacher, and being the most knowledgeable person in the building should not make them its entire training department. Repeated interruptions are real work, especially when they arrive alongside client commitments, difficult projects, and problems that already require sustained attention. But those constraints do not excuse contempt toward the person asking. They reveal an arrangement in which one employee needs guidance and another is expected to provide it without either having much control over the conditions.
“We can know more than we can tell.” - Michael Polanyi
The Job IT Quietly Inherits
I have encountered the other end of that arrangement while onboarding more than 500 employees. Among them were people who arrived needing help with basic computer use, everyday Office tasks, Excel, or the applications through which they were expected to perform their jobs. Some clients had done little or nothing to establish that readiness before hiring. That did not make the employee incapable in their profession, but it left a practical gap between the work they had been hired to do and their ability to do it in that environment. By the time IT encountered the gap, the person was employed, the equipment was issued, and the expectation was that work would begin.
One new hire, brought on to coordinate projects, had never saved a file anywhere but the desktop and had not used a shared calendar. She was capable in her field and had been hired on that basis, and nobody had asked whether she could do the everyday computer work the role assumed. That gap is different from the one every new hire has, which is how this particular company works: what the shared drive is called, when the VPN is required, which form unlocks new software. An employer should establish the first before making the hire, and it owes everyone the second afterward.
A computer can be functioning properly while the person using it remains unable to complete the task. A technical fault, an unfamiliar business process, and a training need are different problems, but that distinction offers little relief when all three arrive at the same support desk. You are expected to identify what is missing, explain enough to get the person moving, preserve their dignity, and fit the interaction around everything else waiting for attention. Whatever the employer had not screened, taught, or explained becomes part of your workload, often without being recognized as anything beyond ordinary technical support.
That responsibility is not always accompanied by respect. I have helped people who were impatient or dismissive toward the person they depended on for assistance, sometimes with the clear impression that needing help from “the IT guy” was itself an indignity. Expertise in another field did not necessarily translate into respect for technical expertise, just as technical expertise did not always translate into patience with someone learning. The relationship could become strained before either person had properly understood the problem. One felt exposed by needing help; the other felt taken for granted while providing it.
One partner at a client firm stood behind my chair while I rebuilt his mail profile and told the room how much the firm was paying for this. I do not think it was only arrogance. When Fiona Lee studied physicians and nurses adopting a new computer system in a large hospital, she found that the perceived social cost of seeking help, the worry about looking incompetent or dependent, shaped who asked at all. Some of the impatience I met was probably the same discomfort, arriving as irritation.
In Trust Debt I called this kind of unbudgeted effort a hero subsidy, and IT pays a version of it every time it quietly absorbs the training an employer skipped. It would be easy to divide these experiences into stories about arrogant engineers and difficult users, but that leaves the organization conveniently outside the explanation. The junior employee needs a way to learn. The experienced employee needs time and support to teach. The client needs staff who can use the tools their work depends on, and IT needs a reasonable boundary around what it is expected to supply. When those responsibilities remain unresolved, people end up negotiating them through individual interruptions. Frustration accumulates around the people involved while the arrangement producing it remains unchanged.
“Money and time spent for training will be ineffective unless inhibitors to good work are removed.” - W. Edwards Deming
Why the Machine Gets the Question
This is the cost of asking: the time, embarrassment, obligation, and interpersonal friction someone expects to encounter before useful help begins. It does not exist in every workplace or accompany every question, but where it does, publishing a support number or telling people to ask questions does not remove it. A person may know exactly whom to contact and still hesitate because of how the last interaction went. Someone else may keep experimenting because explaining the problem feels harder than trying another possible answer. Help can be formally available without being something people feel comfortable using.
Part of that hesitation rests on a misjudgment. In studies where participants asked more than 14,000 strangers for small favors, Vanessa Bohns found that people underestimated how many would agree by 48 percent on average, and working with Francis Flynn she found that people in a position to help underestimate how much embarrassment keeps others from asking at all. Agreeing to help is a lower bar than helping well, though: the people I have described rarely refused; they said yes and then made the help partial, grudging, or late.
When Microsoft asked employees in 2025 why they had turned to AI instead of a colleague, 42 percent cited its availability around the clock and 17 percent cited fear of being judged. Both belong to the cost of asking, and time is the part people name first.
That is the part of the chatbot conversation I keep returning to. A conversational tool offers somewhere to begin without first finding a willing person or knowing enough terminology to conduct a useful search. Someone can describe what they see, ask for a simpler explanation, or admit that they understood the first two steps but lost the thread at the third. They do not have to decide whether another question is worth interrupting a colleague or whether asking it will undermine the impression that they belong in the role. I think some of the attraction lies in that relief, quite apart from the appeal of producing work faster.
I have done it myself. Working through an unfamiliar conditional access policy late one evening, I asked a chatbot to explain the same evaluation order three different ways before it clicked. I would not have asked a colleague the third time.
The same pattern shows up wherever asking a person carries a price. In 2018, Stack Overflow’s own leadership wrote: “Too many people experience Stack Overflow as a hostile or elitist place, especially newer coders, women, people of color, and others in marginalized groups.” Within six months of ChatGPT’s release, posting on the site had fallen by a quarter relative to comparable forums. Experienced users pulled back too, so hostility cannot explain all of it, but the best-known place to ask strangers a technical question started losing its questions to something that does not sigh. One computing student told researchers in 2024: “I like going to ChatGPT more because I didn’t feel like I had to burden my peers at all.”
The relief has limits, because the judgment follows. In four preregistered experiments with more than 4,400 participants, people who used AI at work expected to be seen as lazier and less competent, and were. Nearly half of desk workers in a 2024 Slack survey said they would be uncomfortable telling their manager they had used it. That creates a risk anyone who runs a help desk will recognize: questions asked privately, where the organization cannot see them, never become the ticket that would have exposed a gap in onboarding or documentation.
“Don’t want to look ignorant? Don’t ask questions. Don’t want to look incompetent? Don’t admit to mistakes or weaknesses.” - Amy C. Edmondson
A Place to Start
I did not come to this through AI. Years ago, when a contract with one of the world’s largest banks meant onboarding more than a hundred security engineers, the training program everyone kept citing turned out to be an idea nobody had built. So I wrote the guide myself: troubleshooting commands for a global network of thousands of firewalls, practical advice, even the wording for difficult calls. The only feedback from the person who had promised the program was a list of spelling errors.
The guide became the backbone of our training for years, and engineers I met long after told me they still reached for it on long, difficult calls. It taught me that people move faster when what they need is written down in the order they will need it, close to the work, in the language of the place they work.
Over the following years that instinct turned into software, built slowly and with the people using it, and the software became FixFinder. By 2023 I was writing that support should guide people through common faults with the system asking the questions a technician would ask, and that the aim was “turning the knowledge trapped in the minds of a few into accessible wisdom for many.” A few design choices followed from that.
The first was where help should live. Most self-service sits in a portal the employee has to remember exists, log into, and search using the vocabulary of whoever built it. FixFinder put the starting point on the desktop, next to the work that had stopped, so that asking for help began where the problem was.
The second was to ask before answering. A decision tree does what a good technician does in the first two minutes: it narrows the problem with questions the person can actually answer. Take Outlook asking for a password over and over. Did you change your password recently? Does it happen on your phone too? Are you in the office or at home? A few answers usually separate a stale saved credential from an expired sign-in token or a network problem, and the person learns something about their own setup on the way through. When the tree runs out, the ticket arrives with those answers attached, so nobody starts over.
The third was to make the guidance specific to the place it was used. A generic article cannot know that this company routes new software through an approval form, that the finance share goes by a different name from the one everyone says out loud, or that the VPN client was replaced last spring. Self-service struggles even in customer service, where it is studied most: Gartner found only 14 percent of issues fully resolved there, and 45 percent of customers who started in self-service felt the company did not understand what they were trying to do.
What I was really trying to put on rails was the judgment of the few people everyone else depended on. When economists later gave an AI assistant to more than 5,000 customer support agents, agents two months into the job performed like colleagues with more than six months’ experience who worked without it, and the researchers attributed the gain to exposing “lower-skill workers to the best practices of higher-skill workers.” A decision tree does that work in the open, where the expert’s reasoning stays visible to the person following it.
The desktop tool was real, shaped by the people who used it. The larger idea behind it has kept evolving, and much of that work is still ahead. What it left me with is a conviction I still hold: the people who need help most deserve somewhere to start that already knows how their workplace runs, and the people who hold the answers deserve a way to share them once rather than a hundred times.
“We must design for people the way they are, not the way we wish them to be.” - Don Norman
Help That Knows What Worked
None of this makes a chatbot a mentor or its answers reliable by default. A responsive explanation may still be wrong, miss an important constraint, or help someone complete a task without developing the judgment to handle the next one. A conversation that feels less exposing is not necessarily private, either. Those limitations matter, but they do not make the underlying demand less real. Sometimes the person asking is trying to do precisely what an employer should want: understand before acting, ask before guessing, and become more capable instead of repeatedly needing rescue.
The answers are also less reliable than they sound, partly by design: OpenAI’s own researchers have argued that the way language models are trained and scored rewards guessing over admitting uncertainty. Support desks have already met the consequences. Air Canada’s website chatbot told a customer booking travel after a death in his family that he could claim a bereavement fare after the trip, which the airline’s own policy did not allow. When the airline argued it could not be held liable for what its chatbot said, the tribunal disagreed: “It makes no difference whether the information comes from a static page or a chatbot.”
Challenge an answer and the chatbot will often apologize, sometimes even when it was right, and the correction rarely travels. “You can’t just tell them something and they’ll remember it,” Andrej Karpathy said in 2025; memory features carry context into the same person’s later conversations, not to the colleague who asks the same question tomorrow.
What a general chatbot lacks is the record: whether an answer has ever worked, in which environment, under what conditions, and what broke afterward. That is what I mean by Actual Intelligence, context tested against reality, and in support it means capturing what was tried, what fixed it, and whether it stayed fixed, then checking it before the next person relies on it. That record is what makes guidance trustworthy at work, and it compounds, because each verified fix lowers the cost of asking for everyone who comes after. I still believe that is where the lasting advantage sits.
The largest platforms in my part of the industry, including Microsoft, Kaseya and ConnectWise, are building toward systems that learn from how work gets done, but the record itself still has to be captured, maintained and checked inside each organization, and a fluent answer does not show that anyone has done it.
Consider an access request that keeps failing because the missing piece is an approval sitting with a manager or a security reviewer. A general chatbot will offer a sensible troubleshooting sequence, and it can only know about the approval if someone has captured it and connected it. Guidance that knows where it is working can say so, and when the next step is a person, it can hand over what it has learned, so that, as I put it in The Call-First Conundrum, “the person enters the conversation already knowing what happened.”
Mentorship requires more than answering questions, but it is difficult to develop someone’s judgment in an environment where ordinary requests for explanation are treated as evidence that they should not need to be there. The answer cannot be endless patience from a few experienced people, and it cannot be placing a chatbot in front of everyone else and declaring the responsibility fulfilled. The organization still has to decide how learning will happen, what support people can reasonably expect, and how expertise can be shared without exhausting the people who hold it. Handing an unsupported junior employee a chatbot and calling it development only moves the problem somewhere harder to see.
The standard I would hold any of this to is easy to state and harder to meet. The person who needs help should have somewhere to begin that does not cost them their dignity and already knows how their workplace runs. The person who holds the answer should be able to share it once, see it checked against what actually happened, and stop being the only place it lives. The organization owns the conditions between them, which means deciding how learning happens instead of leaving it to whoever is least able to refuse an interruption.
Before we ask why someone would rather ask a machine, it is worth asking what happened the last time they asked a person.
“We’re sacrificing learning in our quest for productivity.” - Matt Beane
