We will all be hackers: the origin story.

Karin knew the work already

I met Karin through Next Step, a seven-month development programme for seventeen executive assistants at Volvo Group. I’d initially been invited to do a forty-five-minute session on AI. We ended up working together throughout the programme, with regular AI office hours.

That gave us something a single presentation rarely can: time to bring real problems back into the room. Try something between sessions, show the others, get stuck, ask a question, try again. The work supplied the curriculum.

Karin has a spark in her eye and a willingness to give things a go. Early on, she decided to fire Google and hire Copilot. I love that formulation. It gave her a small behavioural trigger: when a question appears, try a different first move.

Hiring and firing will turn up again in this series. It starts here, with a person choosing what should help her do her work.

Her Teams report contained the information she needed, surrounded by information she didn’t. The Word template wanted a list of names. Karin had become the manual connection between the two.

She’d wanted help fixing that for a long time. To someone with the right programming skills, it was a small problem. In the larger organisation, it stayed unresolved.

A task can be small in an IT backlog and occupy a large place in someone’s day.

Take the whole thing

Instead of copying the next name, Karin copied the whole report into Copilot and asked for a bullet-point list containing just the names.

Out came the list.

All that switching between windows, all those individual selections, reduced to a much shorter operation. She could see the result and judge whether it was useful because she knew exactly what she needed.

No programming course before the first benefit. No specification handed over to somebody else. An ordinary request about a task she understood.

This is where the story gets interesting for me. The expertise was already there. Karin knew the job, the people and the standard the result had to meet. AI gave that understanding a route into action.

The process had been something she followed. Now it was something she could change.

Then someone asks for more

Karin showed the other sixteen executive assistants in our office hours. Suddenly, she was the person with something useful to teach the rest of us.

A colleague wanted the names arranged differently. There was also the next task: making an email recipient list for Outlook, so the message would go to the people who’d actually attended.

She tried asking for those changes, right there in the conversation. Extract the names, arrange them differently, produce the email addresses in a form she could paste into Outlook. Then, over time, combine the requests into one reusable instruction and share it.

Later, when the ability to build agents became available, Karin gave the method a more permanent home. She built an agent for it. I’ve recreated it in the screenshots above: the same familiar job, carried forward as the tools developed.

Look at how much happens in that little sequence. A result worth showing. A colleague who spots another use. An immediate attempt. A method that gets better because people are working on it together.

I’m fond of this part because it’s how so much useful learning actually happens. You don’t have to arrive with a finished invention. Bring something that helped you, let somebody ask a question, and see where that takes you.

Karin gained a useful method. The group gained a colleague they could learn from. And the next problem no longer had to look quite as immovable.

A level-one hacker

This is what I mean by going from n00b to level-one hacker. Spot a frustrating arrangement, try changing it, see whether the result helps.

The beginner label applies to the technical possibility. Karin was already a highly capable professional. There’s a lot of expertise in organisations waiting for a better way to become action.

But I want hacker to mean something more specific than using AI. Asking for help completing a task is useful. Changing the method, keeping the improvement and making it available for the next repetition is another kind of contribution.

Karin crossed that boundary. She improved how the work was done.

The first technical step was tiny. She could learn inside the attempt, using words she already had, on material whose purpose she understood. Our office hours and her colleagues gave her somewhere to bring the result and develop it.

That’s the entrance I want people to see. A small enough first move that they can try it in their own working day.

All Four Jobs, in one ordinary task

My Four Jobs framework helps explain why I keep returning to this example.

Job 1: Do the work. Produce the attendance list. People still need the result, and Karin still has a job to get done.

Job 2: Improve how the work is done. Change the recurring method. Make the next list easier to produce too.

Job 3: Improve yourself. Learn how to work with AI through a problem you understand. Build capability by trying and refining.

Job 4: Develop the team. Show your colleagues. Share the instruction. Let their questions improve what you’ve made.

There they are, all four, in a piece of everyday work that would be easy to dismiss as too small for a serious discussion about AI.

This is why protecting time for Job 2 matters. If every available moment goes into delivering today’s tasks, an absurd method can survive for years. The improvement keeps waiting because the work keeps arriving.

And once you discover you can change the method, another question becomes available: do we need to do this task at all? That came up when we discussed Karin’s story in a workshop. It’s a good question to carry into the next experiment.

Relief counts

We could start counting meetings, names and seconds per copy-and-paste. There’s a useful calculation to make there.

But spend a moment with what it feels like to be the person doing it.

There is a particular burden in knowing that a process is absurd while feeling unable to change it. Every repetition reminds you of the gap between the work you’re doing and the work you know would be possible.

Then you find a way to act. You can try something, inspect it, make a change. You have something useful to show a colleague. The next time a small problem appears, you’ve got another move.

That matters to me. So does the relief of removing something you dread from an otherwise worthwhile job.

We should ask whether people have more attention, confidence and energy left at the end of the day. We should also resist the reflex to fill every reclaimed minute with another assignment.

There is a life to have after work.

What happened. What I think follows.

Observed: In the learning journey I facilitated, Karin turned a recurring attendance-report task into a much shorter operation, tried refinements with colleagues and developed a reusable instruction to share. The requests in this retelling are paraphrased from my accounts of the experience.

My assessment: The important change was her ability to improve her own work. The frustration, relief and growing confidence belong in the account of value alongside efficiency.

My inference: Starting with a problem people already understand can make the first technical step surprisingly small. Ongoing support and peer learning helped here.

My forecast: More people will gain ways to change the digital arrangements around their work. The results will range from small text hacks to tools and services they can shape themselves.

Still open: How widely that capability spreads, what support people need and which improvements last. This story has no measured before-and-after study of time or wellbeing. It gives us a concrete experience to examine and learn from.

You can begin here

Find a small frustration in work you know well. Choose something whose result you can inspect. Bring it to an AI tool you can appropriately use for that material and explain what you want to achieve.

If it helps, ask what would make the next repetition easier. Then show someone. Their question might be the most useful next instruction you receive.

If you lead people, give them room to do this. Pay attention when somebody brings back an improvement. Ask what became lighter, what they learned and who else might benefit.

The companion essay follows the same instinct into replacing Rebrandly with JJ Links. That requires more tooling, access and technical support than Karin’s first move. There’s real distance between transforming a report in a chat and operating a deployed service.

Karin doesn’t have to travel that whole distance for her discovery to count. Her working day was worth improving.

We will all be hackers. This is where I want the conversation to begin.