From Chatbot to Coworker: How Mike Rhodes Builds AI Skills for Small Business

You have watched the demos. Someone on stage asks an AI to do something clever, the room claps, then you sit down at your own computer, open a chat window and have no idea what to type. So you ask it to write an email, decide the result is fine but not life changing and get back to work.

Mike Rhodes has been further down this road than almost anyone Dave knows. He is back on the show to talk about AI skills for small business: what a skill actually is, why your business context matters more than your prompt and why this whole thing feels like nothing is happening right up until it does. If AI still looks like a party trick rather than something you would trust with real work, give this one an hour.

In This Episode

• 02:30  What makes this different from the AI tools that came before
• 09:00  The haunted house, the Lego and the adjacent possible
• 12:15  Why context comes first and why most businesses have never written theirs down
• 15:00  Fall in love with the problem, then start absurdly small
• 19:15  The Loom trick for capturing a task you already do
• 27:30  Dave automates his Asana, one recurring task at a time
• 33:45  What a skill actually is and why 2026 is the year to learn them
• 39:30  From 10/80/10 to 1/98/1
• 45:30  Connectors, permissions and how much access to hand over
• 58:00  Where a central business brain fits and how it goes multiplayer

👤 Today’s Guest, Mike Rhodes

Mike Rhodes is an Australian digital marketer turned AI practitioner and one of the handful of people Dave calls SYSTEMology royalty. They shared an office for years and Mike is the source of the big wall of systems story Dave still tells on stage. Twenty years in digital marketing, Google Ads scripts and E-Myth systems work gave him the input, process, output habit of mind that he reckons is now a real advantage. He has been on the show before, most recently for an introduction to AI for small business.

These days he runs a community for owners getting into AI and builds what he calls 80/20 Brain, or just the brain: his own setup, which community members get a copy of. He was one of the first to push Dave onto Claude Code and he built a free gamified course at 8020skill.com to show people the difference between using AI and using AI with a skill. His current project is making the brain multiplayer, with a Team Brain and then a Client Brain on the way.

Website: 8020skill.com

📋 AI Skills for Small Business: How Mike Rhodes Actually Builds Them

Based on the interview with Mike Rhodes, AI community founder and creator of 80/20 Brain.

Most people meet AI the wrong way round. They get access to a tool, then go hunting for something to do with it. Mike does the reverse, in phrasing that will sound familiar to anyone who has been through the SYSTEMology stages.

Start With A Problem, Not With The Tool

Fall in love with the problem. That is the whole of step one. He is deliberately unfussy about the size of it, too. When people ask what scale of problem to pick, his answer is that it does not matter, so pick something little. Five hours a week, five minutes a week, it makes no difference. What matters is reaching the moment where you think, oh, that was easy, it did that.

His signpost for finding your first one is anywhere you are copying and pasting between two apps. Something out of Gmail and into Xero. Something out of Xero and into a spreadsheet. That is an essential, repeatable, delegatable task wearing a disguise, which makes it exactly the sort of thing worth documenting as a process first.

The trap on the other side is planning. Software has been built two ways for 50 years, Mike points out: everyone sits around a whiteboard for months building the perfect waterfall chart, then starts and watches it fall apart, or you accept that you know roughly where you are heading and start anyway. He much prefers the second. Version 0.1, then version two, then version three. It works here because the distance from idea to impact has collapsed to minutes, which is why this suits the visionary in a business more than anyone. Ideas were never the constraint. Implementation was.

Dave puts it to him that a systems thinking brain is a competitive advantage with this technology. Mike agrees and adds two more traits. The second is the honest part nobody puts on a landing page.

“The people that are getting the most out of AI right now are the ones that are just willing to get slapped around a little bit, and like, ‘But it worked yesterday.'”
Mike Rhodes, 07:00

Room One: The Haunted House And The Adjacent Possible

This is the mental model to steal from the episode. You are standing in front of a big scary haunted house. The front door is open, the first room is lit and everything past it is dark. You walk into that first room and there is nothing in it except a few Lego pieces on the floor. No doors, no windows. So you play with the Lego, work out that this bit goes there, then look up to find three doors have appeared out of nowhere.

You pick a direction. Same thing again: a few pieces on the floor. Once you have put them together, three more doors. You do not get to jump from room one to room 50. You earn room 50 by playing with the Lego along the way. Room 10, for Mike, looks like a meeting brief that writes itself: the brain reads his calendar, pulls the notes from his last three conversations with Dave, tells him what each of them committed to, then checks Asana to see what actually got done. None of that was designed upfront. Each piece became possible because the piece before it worked.

One warning goes with the model. Ethan Mollick’s term for what you are dealing with is jagged intelligence, which Mike endorses. The thing will be brilliant at one task and hopeless at the next task that looks almost identical, then brilliant again at something completely different. There is no shortcut around it. You have to play.

Your Business Context Is The Part Nobody Has Ready

Dave asks the question this audience will be waiting for. AI gives you far better output when it understands your situation, so what feeds it? SOPs. Policies. Position descriptions. Your client avatar. Your company goals. Mike’s answer is more honest than convenient. Yes, that is context. And no, it is not room one for most people, because most businesses have not documented any of it. You cannot tell an owner to go away and spend somewhere between 10 hours and six months writing things down and trust that it will pay off. They have to see the potential first, then add the context bit by bit. His line for what happens next is one Dave uses too: once you see it, you can’t unsee it.

Dave admits his own bias here. He looks at clients already doing brilliantly with AI, like Shannon and Ryan Smit’s accounting automation story, then forgets it all started with an account full of documented processes. Once that existed, asking how to do the same work faster, cheaper and better was easy. Most people are not standing there, which is why Mike is blunt that it is not a mind reader. You have to get it out of your head.

His framing for the gap is an alien junior employee. Not human, cannot feel, a bit weird, on its first day of work. You would never say to a new starter, go and build the proposal for Bob. Who is Bob? What is he buying? What do we sell? What are our values? You teach a person all of that before they can write anything useful. It is no different here.

“It’s only as good as you said before, the context you give it.”
Mike Rhodes, 17:45

The Loom Trick For Getting It Out Of Your Head

Here is the cheapest way to start. Pick a task you do in one sitting at the computer, not a multi-day project. Something that takes five minutes, maybe 30. Hit record, do the task and talk out loud the whole way through. I do this. I’m clicking over here because of that. Thirty seconds after you stop, the transcript is ready. Drop it into an AI and ask four things: how can you help me with this task, which bits of it can you automate, what am I not seeing and how could this be better.

Dave’s version is even lighter. Talk the process through into a voice memo while you are driving, let your phone transcribe it, then paste that into systemHUB and let it become a system. Either way the win arrives before any automation does, because you now have something repeatable and transferable where you used to have a habit. That is the whole argument for capturing how the work actually gets done.

Human Automation Before Automation

Mike ran a rule at his agency that solves the problem most people hit when they try to automate straight out of their own head. If an account manager wanted a task automated, they could not walk to the developer and ask for a script. They found it too hard to describe the end state and the developer found it too hard to codify the human judgement in the middle.

The step that fixed it sat between the two. First you teach a junior. A VA, someone in another country, the person sitting next to you, it does not matter. You give them the checklist, accepting that not everything fits in a checklist; step four might be stop and talk to someone more senior. Then you sit with them and work through it, me, we, you. The gaps show up, the checklist gets better, so now you have something a developer or an AI can actually take. It is the same discipline behind any decision about what to delegate and how.

They have both been banging this drum for a decade. Mike is willing to put a number on the prize. The waste he is pointing at is not lazy staff. It is time, miscommunication, handoffs and things getting dropped.

“Double their profit, not their revenue, but double their profit just by using a whole bunch of automation.”
Mike Rhodes, 22:00

What An AI Skill Actually Is

Dave’s one-line version is the one that lands for this audience: a skill is an SOP for a computer. Mike thinks skills are one of the most important things for any business to learn in 2026. He strips the mystique out of them first. At their most basic, a skill is just a saved prompt. Everything is a prompt in the end. The problem is that people believe they have to become a prompt engineer, whatever that means, then write 14 paragraphs into a chat box to get anything good out.

What a skill really does is take the knowledge and the wisdom of someone who already knows how to solve the problem, so nobody else has to work it out. One person builds it once and it solves that problem the same way every time. Then it gets more useful, because a skill mixes two halves. The AI half is the prompt: this is the problem, these are the pieces, this is how I want them put together. The automation half is the scripts. His Gmail skill carries code for reading an attachment, creating a draft and adding a label. He wrote none of it. The first time the model hit a wall it read the documentation, wrote a bit of code, got it slightly wrong, tried again, then got it. At which point you say the only thing you need to say: save that. Bottle it.

What makes a skill different from the automation tools that came before is that it stays flexible. Here are the 13 steps. Step five runs this script, so that bit is identical every single time. Step eight uses this template, so the output arrives in your colours, your fonts and your heading styles. Everything in between can still be judged rather than hard coded, which matters because old automation ran step one to step five and broke, or step five was a subjective call no formula could hold, so the whole thing stopped and waited for a human. Skills also reference other skills, chain into bigger ones and repair themselves: if Gmail changes and a script stops working, it reads the documentation and fixes the script. To see the shape of one without building anything, systemHUB’s process to AI prompt tool does a smaller version of the same job.

“If you give the model a prompt text, it’s a strongly worded suggestion.”
Mike Rhodes, 32:00

That line is the reason you do not hand the whole job to AI. Nobody wants the model waking up on Monday morning wondering how Dave might like his inbox managed this week. The cadence, the format and the rules belong in code, because code does the same thing at the same time every time. The writing that goes inside the report is what you brought the AI for.

From 10/80/10 To 1/98/1

Mike has a blog post about the shape of delegated work called 10/80/10. It sits in similar territory to Dan Sullivan’s Who Not How. You do the first 10%: define the outcome, what done and done well looks like, the resources, the tools, the budget. Someone else does the 80% in the middle, bouncing it back every few weeks for a course correction. Then you do the last 10%, where the red pen comes out and you think, this would have been faster to do myself. His honest note is that it never starts at 10/80/10. It starts nearer 30/20/50, with a fortune of your own time going into the back end until the middle finally carries its weight.

The version he is living in now is 1/98/1. You describe the thing you want. The middle is AI and automation taking turns. When it needs a judgement call it kicks back up to the AI rather than all the way up to you. Then it comes out the end and most of the time you read it and think, that is really good, carry on. Occasionally you say, next time do this bit differently. That small correction improves the skill for every run after it.

Where the work sits	10/80/10	1/98/1
The start	You define the outcome	Same, but you talk it
The middle	Humans, checking in weekly	AI and code, checking in with the AI
The end	Red pen, rewrites, training	A read, then one note that sticks

Two things compound out of this. Skills compound, which you would expect. Ambition compounds too, which surprised him. You start pushing, thinking surely it cannot do this, then it does, in five minutes, so you push harder. His brain now holds around 12,000 files, much of it notes the brain wrote itself.

Two habits make that possible, both borrowed from managing people. Do not describe how. Describe the outcome and the why, say what done and done well looks like, then get out of the way. And run the reverse of a prompt. His grill me skill, which he has used for 3 years, has the AI ask you questions until it is 95% sure the two of you are on the same page. They are the questions you would answer for a junior anyway. What is the job to be done? What resources are available? How much time should this take? What is the budget? Those constraints are usually clear in your head and nowhere else, which is precisely the problem.

Connectors, And How Much Access To Hand Over

None of this matters if the AI cannot reach your actual work, which is where connectors come in. For anyone hearing MCP and API and wondering what on earth is being discussed, Mike’s advice is to skip the terminal and start with Claude Cowork. It looks like ChatGPT, which is what most people think AI is, while being far more powerful than the free version. He calls it the baby brother of Claude Code. The connectors are a list you tick, then authorise.

Then comes the bit worth writing on a wall. You do not start on day one by handing over the keys. Start with read. It can read your tasks, read your emails, look at your calendar. It cannot delete events. Then you watch it work. As it earns it, you hand over a little more. Exactly the junior employee again.

Someone gave Mike a metaphor he thinks is bang on: a tool like Cowork is a chainsaw in the hands of a toddler. Enormously powerful if you know what you are doing, genuinely dangerous if you do not. He is quick to name the other half of that, though, because it is the half that keeps businesses stuck. Fear of the chainsaw is what stops people connecting anything. Until you connect the tools you never see what they can really do. So weigh the probability rather than the horror story. There is a risk curve. The far end of it is handing an agent your bank account, which is not where anyone is asking you to stand.

1 Point It At The Task

Dave has been working through his own Asana board task by task. The loop he has landed on is one to copy. He gives the AI the link to a recurring task, then tells it to read everything, follow any links it needs and get a full understanding of what the team member assigned to it actually does.

2 Let It Tell You What Is Safe

Then he asks which parts could be automated. It comes back with something like: steps two, three and four are very low risk, I can do those. That is 80% handled, with the 20% that needs a person left where it belongs.

3 Run It Once By Hand

Before anything gets scheduled, he has it build the automation, run it once manually, then post the result into the Asana thread along with the exceptions and where things broke.

4 Let The Team Comment

The person who owns the task reads that comment and replies in plain language. That was good. It missed the mark here. I think it missed it because of this.

5 Feed The Comments Back

Dave then tells the AI to read what she wrote and look for patterns. It spots them, adjusts the filters and runs again. Twice through that loop is usually enough.

6 Turn It Into A Scheduled Job

Only then does it become a job on a set cadence. Two details make it hold. The scheduled action gets referenced at the bottom of the task description, so anyone opening it in six months can see what is running. And every run posts a comment in Asana saying what it did. The human stays assigned, stays the owner and now reviews exceptions instead of doing the work.

Mike’s word for those two details is observability. The old model was learning the violin for years, then learning the drums if you wanted an orchestra. The new one is conducting: you do not need to play every instrument, but you absolutely need to see that everybody is playing their part. Management by exception. Tell me when something goes wrong. Trust is what the loop is really building, the same way it is with a junior who does the task perfectly five times, or 10 times with AI, until you tell them to crack on and stop watching. For the wider version of this, systemHUB has a piece on where to start with business process automation.

Where A Central Business Brain Fits

Dave asks the selfish question near the end. It produces the most useful part of the conversation for anyone running a team. So much of his work is making the invisible visible, pulling what is trapped in people’s heads into somewhere shareable. He sees systemHUB as a portable business brain: position descriptions, systems, policies and now skill packages, all in one place, that any staff member can plug their own AI into for pre-loaded context. The systemHUB MCP server is in beta for exactly that.

Mike’s read on why that matters is sharper than the pitch. Silicon Valley imagines a single player: me at the top with dozens, maybe thousands of agents working for me. In the real world we all work with other humans, so the interesting problem is making the brain multiplayer. Once it is multiplayer you need a central store, because when someone changes the business context, every brain in the company has to know. He has already watched what happens without one. Team members he set up months ago have each been building their own context, so their brains have drifted a long way from his with no shared component in the middle. His analogy is a Tesla hitting a patch of ice: one car meets the edge case, then every other car in the world knows how to handle it.

“Everybody can hear the violin without having to learn how to play the violin, and so everybody’s making everybody else better.”
Mike Rhodes, 1:02:45

That is also his answer to what systemHUB is really for. It speeds up time to trust. People trust the systems, so they use them and improve them. You stop having 16 people wandering off on 17 different tangents, all doing the same job slightly differently until it gets worse and worse. Alignment is what makes businesses go further faster.

The Two Hours That Feel Like A Waste

The last obstacle is not technical. Mike names it plainly: once you understand what this does, the hard part is focus, because it feels limitless. And it feels silly to spend two hours with an AI solving something that used to take you 10 minutes. You are running at 110%, your day is full, so the only slots going are gaps between meetings, evenings and weekends. So do the arithmetic on one task. Two hours is 12 lots of 10 minutes. If it is a job you do twice a week, you are square in six weeks. Every week after that is 10 minutes back, which is what you spend building the next one.

His bigger version of the same maths is 10 to 20 hours of playing before it clicks. The first 15 or so might feel like waste. He almost says wasted before correcting himself to invested. One last thing: do not sit down to write your context. Talk it. This is our business, this is what we sell, these are the clients who matter, this is the team, this is me, this is how I like to work. Two minutes of talking beats an afternoon of typing you never start.

None of this asks you to think less. Mike is firm about that. So is Dave. Use it for the research, the summarising and the synthesising, the strategy document that used to cost you a weekend pulling 17 scattered files together. Then do the thinking yourself and stand behind what goes out. You cannot send a document and answer a question about page seven with, oh, I didn’t know that was in there. The human stays accountable. You just stop doing the grunt work first.

Which lands right back where they started. What problem are you trying to solve? Do you have problems? If you have a pulse, you have problems. Pick the smallest one, the thing you copy and paste every Tuesday, then record yourself doing it once. Your business isn’t broken, your systems are. Get them out of your head and the machines can finally do something useful with them.

---

---

Frequently Asked Questions

What is an AI skill?
At its most basic it is a saved prompt, usually with a few scripts attached. Mike describes it as bottling the knowledge of one person who already knows how to solve the problem, so nobody else has to work it out. Dave’s shorthand is that a skill is an SOP for a computer.

Do I need to learn prompt engineering?
No. Mike is blunt that people wrongly believe they have to write 14 paragraphs into a chat box to get anything good out. On his own course the prompt is a single sentence, because the skill is doing the work.

Where do I start if nothing in my business is documented?
Not by documenting everything. Mike says context is not room one for most people, because you cannot ask an owner to spend 10 hours to six months writing things down on trust. Pick one small problem, see it work, then add context bit by bit.

How much access should I give an AI tool?
Start read-only. Let it read your tasks, your email and your calendar before it can change or delete anything, then hand over more as it earns it. Mike’s framing is that you build trust the same way you would with a new hire.

Will this make my team worse at thinking?
Both of them push back on that. The point is not to replace how you think. Use it for research, summarising and synthesising, then do the judgement yourself, because the human still has to stand behind whatever goes out the door.

How long before it pays off?
Mike suggests 10 to 20 hours of playing before it clicks. He warns the first 15 may feel like waste. On a single task the maths is simpler: two hours spent automating a 10-minute job you do twice a week pays for itself in about six weeks.