How to Make Your AI Skills Visible Without Becoming the Office AI Evangelist
Your briefings read cleaner than they did six months ago. Your status updates arrive on time, organised by theme, with the decision or risk flagged near the top instead of buried on page three. Your meeting prep gives people what they need before the meeting starts, not scrambled together during it. And when your last review came round, the language used to describe your work was word for word what it had been the year before. Solid. Consistent. Nothing wrong with either word, and nothing that reflects what actually changed.
That gap is more common than it looks from the inside. Work passes through a surprising amount of distance before it reaches the people who decide what happens to your career. It gets forwarded, summarised, folded into someone else's update, presented in a meeting you weren't in. By the time it lands, the improvement is still there in the document itself, but the reason for it has usually fallen away somewhere along the route.
Quality does not always travel on its own
Picture someone who has spent months refining how they prepare a weekly report for their division. What used to be dense paragraphs stitched together from several sources becomes something else entirely: a clear status line, a flagged risk, a recommended next step. The two or three people closest to that work notice straight away. A colleague mentions it saves her time before her own Monday meeting. Then the report gets forwarded up a level, and up another, and somewhere in that chain the format stops looking unusual, because nobody upstream ever saw what it replaced. The next formal review describes the work in exactly the terms used the year before.
This is not a story about neglect on anyone's part. It is what happens by default when improvement stays private. Nobody upstream is being careless. They simply never had a reason to notice that anything had changed, because nothing about the way the work arrived told them so.
There are two ways people tend to respond once they notice this gap, and both tend to make it worse rather than better. One is to assume the work will eventually speak for itself, which sometimes happens under an attentive manager on a small team and just as often doesn't. The other is to overcorrect, mentioning the tool in every conversation, framing every improvement around the software rather than the result. That second response usually backfires. It reads as enthusiasm for something new rather than evidence of something reliable, and in most workplaces the audience genuinely interested in hearing about a colleague's tool stack is smaller than the person doing the talking assumes. None of this is an argument for secrecy where disclosure is expected. It is a question of what gets said, to whom, and in what order, once disclosure obligations are satisfied.
Direct the improvement, don't just let it happen
The more dependable route is neither silence nor advertisement. It is choosing where the improvement lands.
Most people can name, without much difficulty, two or three recurring outputs that other people actually depend on. A status update a manager uses to brief someone further up. A planning document a team relies on to coordinate what happens next. A research summary that feeds a decision made by people who never see the underlying material. Meeting preparation that decides whether a discussion is useful or a waste of forty minutes. Anywhere your output sits between you and someone whose judgement affects your trajectory is worth deliberate attention, not because it is the biggest task on your list, but because improvement there gets experienced directly by the people who matter to that judgement.
An analyst at an insurance firm offers a useful version of this. His team's quarterly risk assessments had always been technically fine and practically unusable: long documents, dense tables, narrative sections senior underwriters routinely skipped in favour of asking someone to just talk them through it. Over three months he restructured the format into three parts, an executive decision summary up front, a ranked risk section with the supporting evidence attached, and a detailed appendix for anyone who wanted to go deeper. Nothing about the underlying analysis changed. What changed was how quickly someone could act on it. The first restructured assessment let a lead underwriter make a preliminary call in twenty minutes, a decision that had previously needed a forty-five-minute meeting to reach. Within two quarters the new format had become the standard across the department, adopted by three other analysts without anyone asking them to. He never announced that his workflow had changed. He pointed improved capability at one output that mattered to people who mattered, and the result did the explaining on its own.
That is the shift worth making before anything else: not working better in general, but choosing where the better work shows up.
What to say when someone asks
Even directed improvement eventually meets a moment where someone asks how you did it, and the language you reach for in that moment matters more than it might seem to.
There is a real difference between "I'm using AI a lot and it's really helping" and "I've built a more reliable process for turning raw material into structured output, which is why my briefings are cleaner and my turnaround is faster." The first describes a tool without connecting it to anything the listener cares about. The second describes a capability in terms of what it produces, and that is the version an organisation actually has a use for. A manager assessing a team member is not thinking in terms of AI workflows. They are thinking about who delivers clean work, who meets deadlines, who reduces friction for everyone downstream of them, and who can be trusted without close supervision. Capability-first language fits directly into that frame. Tool-first language does not, however genuine the enthusiasm behind it.
You do not need to manufacture opportunities to say any of this. Performance reviews, project retrospectives, conversations about taking on more responsibility, even an informal check-in with a manager, all create natural openings where explaining what has improved is expected rather than forced. The only preparation worth doing in advance is knowing how to describe the change in terms the listener already values, so that when the opening arrives, you are ready to fill it with something specific rather than something vague.
None of this promises a promotion or protects a role on its own. What it changes is simpler and more within your control: whether the people who decide what happens next can actually see the difference between the work you produce now and the work you produced before you built a method for it.
The signal was never in the talking. It was always in choosing where the improvement would be felt, and then letting the work say what it needed to without you standing next to it explaining.
Anthony Velland
Interested in going further?
If turning better AI use into a repeatable working method, one that eventually shows up in the work itself rather than in how often you mention it, sounds useful, AI Without Guesswork builds the full approach from the ground up.
Ad · Amazon affiliate link.
