Yes, and start with the part of your week you’d hand over tomorrow without a second thought.
This question gets asked in private a lot more than it gets asked out loud, and it usually gets answered on forums by people describing how they got away with something. That’s the wrong frame. The interesting version of this isn’t how to hide it. It’s what you get out of it if you do it in the open.
What actually happens when someone automates their own work?
The work changes shape. It doesn’t disappear.
A consultant we worked with ran building-permit applications for her clients. Every one meant a half-hour to one-hour call, walking somebody through the process while she drove a spreadsheet she’d built herself. It was full of her own hard-won logic, and she was the only person who could operate it.
She’d already done the difficult part. She just hadn’t noticed that her spreadsheet was the blueprint for a system.
She talked through her process for about fourteen minutes on a call. By the end of that same call, the tool existed. She has since extended it herself and is preparing to turn it into a product for other people in her field.
She didn’t automate herself out of a job. She turned the least scalable part of her expertise into something she owns.
Which parts should you automate first?
Ask yourself the questions we ask everyone whose work we’re about to change. They work just as well pointed inward:
- What are you uniquely good at? What would you never want to give up?
- What do you actually love doing?
- What drains you? What’s the time suck that takes ages, leaves you flat, and never feels like it mattered?
- Where do you get stuck on the same thing over and over?
The third and fourth answers are your list. Everyone has one. Nobody loves every part of their job, and the parts you’d hand over are almost never the parts you’re valued for.
If nothing comes to mind, look for the workaround you already built. The spreadsheet, the checklist, the folder of templates, the process only you can run. That artifact is your expertise written down, and it’s usually the fastest thing in the building to turn into a real tool.
What should you keep?
The judgement.
In almost every workflow there’s one call that requires knowing the client, reading the room, or having been wrong about this before. Find it and keep it, deliberately.
We built an executive briefing system for an energy policy consultancy where their analyst spent a full day each week on it: sorting sixty to eighty forwarded links, chasing tracking URLs to real articles, summarising, sorting by topic, then hand-building the document. Now the ingestion, the summarising, and the formatting run themselves. The analyst still decides what’s worth including. That’s the part that was never the problem, and it’s why the briefing is still good. The week went from eight hours to under three.
The rule of thumb: automate the fetching, the formatting, the counting, and the first draft. Keep the deciding.
Won’t this make me easier to replace?
It works the other way round, and the logic is worth being precise about.
AI is a magnifier. Point it at vague instructions from someone who doesn’t understand the work and you get a confident, useless output. Point it at an expert’s process, with their rules and their edge cases and their sense of what “done” means, and you get something genuinely good.
You’re the input that makes the tool worth anything. Somebody else with the same software and none of your experience cannot build what you just built, and that gap doesn’t close because the software got better.
The person who understood the work well enough to encode it is not the obvious thing to remove.
Should you tell your manager?
Yes, and this is the part the forum threads get badly wrong.
Doing it quietly feels safer for about three months. Then it stops being safe, because you now depend on something nobody has approved, nobody has reviewed, and nobody else can fix if it breaks while you’re on holiday. You’ve taken on the risk personally in exchange for a secret.
Telling people changes what it is. It stops being a private shortcut and becomes something you built for the business, which is a much better sentence in a performance review than anything you’d get from hiding it.
Frame it around what changed, not around the tool:
- This took me six hours a week. It now takes forty minutes.
- Here’s what I check before it goes out.
- Here’s what breaks it, and here’s what I’d do next.
That’s not a confession. That’s the strongest case you’ll make all year.
One caution worth naming: if the workflow touches customer data, money, or anything regulated, get it looked at before you rely on it. Not because you’ve done something wrong, but because a tool the business depends on should be a business decision, and that’s also how it stops being your personal liability.
What if the automation is the whole job?
Then you have better information than you had last week, and more time to act on it.
Realistically, this is rare. Most roles are a bundle: some of it repetitive, some of it judgement, some of it relationships, some of it firefighting. The repetitive slice is usually the biggest and the least defended, which is exactly why it’s the right place to start.
And if a large piece of your role really is mechanical, it was going to get automated by somebody eventually. Considerably better that it’s you, holding the documentation, than a vendor’s rollout you find out about in a meeting.
If you’re sitting on a process you think should be a tool and want a straight answer on whether it’s buildable, book a free readiness call. Twenty minutes, no pitch, and if it’s not a fit you still leave with clarity.