About eighteen months ago, if you worked in design or research, you couldn't open LinkedIn without someone announcing your job was over. "AI will replace designers." "Design is dead." The tools could suddenly generate a logo, write the copy, mock up the screen — the things some of us had spent a career getting good at.

I want to be honest about what that does to a team. It's not an intellectual debate. It's a quiet anxiety that sits in the room. People stop putting their hand up. They wonder if the thing they're brilliant at is about to become worthless.

That fear was real. And on my team, I decided we were going to do something slightly unusual with it.

We walked towards it.

The castle problem

When something threatens your craft, the instinct is to defend the castle. Pull up the drawbridge. Make the case for why the human is irreplaceable. Write the thoughtful think-piece about the irreducible value of real design.

I get it. But I watched teams do that, and here's what happens. While you're defending the castle, you're not learning the new thing. You're spending your best energy building a case for the past. And the people you're trying to protect — your team — they can smell it. Defensiveness doesn't feel like safety. It feels like denial.

Here's the reframe that changed everything for us. The threat was never the tool. The threat was being the last team to learn it. The danger isn't that AI can do part of your job. The danger is standing still while everyone around you gets faster, braver and more capable.

So we stopped asking "how do we protect ourselves from this?" and started asking "how do we become the team that's best at this?"

Four words that became our operating system

There's a bit of internet wisdom that became our team's entire philosophy: you can just do things.

It sounds almost too simple to matter. But sit with it. So much of how we work is shaped by an invisible assumption that we need permission. Permission to try the tool. Permission to automate the boring task. Permission to build the thing instead of writing a three-page proposal asking someone else to consider building the thing.

You can just do things is the antidote to "that's not my job," "we'd need a project for that," and "I'm not technical."

I started saying it constantly. Someone would describe a painful manual process and I'd say — well, you can just do things, have you tried asking the AI to do it? Someone would have a wild idea for a tool and instead of "let's scope it," it became "you can just build a rough one this afternoon and show us."

We didn't make our team more capable by training them. We made them more capable by giving them permission — and then giving them the structures to act on it.

Five moves that actually worked

What follows is the exact playbook we ran. Permission, then structure. Five moves.

1. Start where people already are

You don't begin a capability program at the frontier. You begin where people already have a foothold.

For us, that foothold was GitHub Copilot. Everyone already had the tool, a login, and at least a little exposure. That matters more than it sounds. It meant we had a shared language. When someone discovered something, they could share it and everyone else could actually try it five minutes later. No procurement, no "I don't have access," no friction.

If your team hasn't adopted anything yet — fine. Your shared baseline might be Copilot, it might be the enterprise AI assistant your organisation already gives you, it might just be a free chatbot everyone opens in a browser. The point isn't which tool. The point is that everyone's standing on the same floor, so a win for one person is a win everyone can copy.

2. Show them the ceiling

Here's a trap. If you only ever show people the floor — AI as a slightly better autocomplete — they'll use it like a slightly better autocomplete. You have to show them the ceiling.

For us, the ceiling was something called vibe coding. Let me translate, because it sounds like nonsense and it's actually profound. Vibe coding is where you build software by just describing what you want, in plain English, and letting the AI write the actual code. You don't need to know how to program. You describe the vibe, you look at what comes back, you say "no, more like this," and you keep going until it works.

I shared this with the team not because I expected everyone to become a developer, but because I wanted to detonate the belief that "building things" is something that happens to other, more technical people.

Once a researcher realises they can describe a tool and have it appear, they stop waiting for it to be built. That's the moment the ceiling lifts.

3. Get air cover

Permission from me gets you part of the way. But for people to really lean in, they need to know the organisation has their back. They need air cover.

So I went and got leadership buy-in for a formal pilot. And a sanctioned pilot did three things a grassroots effort never could.

One: it made experimentation legitimate. People weren't doing something slightly naughty on the side; they were contributing to an official pilot. Two: it gave us cover — a safe container with boundaries, so people knew what was okay and what wasn't, which paradoxically made them braver inside those lines. Three: it signalled that this was a direction, not a fad — that the time you invested in getting good at this was time the organisation valued.

Grassroots energy plus top-down permission is the magic combination. One without the other fizzles.

4. Make it personal

This is the move people find most counter-intuitive, and it might be the most important one.

I encouraged everyone on the team to get their own AI plan — a personal subscription — and to use it in their personal lives. Plan a trip. Sort out a recipe. Draft the email to the strata committee. Help the kids with their homework.

Why on earth would a manager push people to use AI for their weekends?

Because the fastest way to build real fluency is in the place where the stakes are zero and the motivation is high. At work, if the AI gets it wrong, that's scary — it's your reputation. At home, if it plans a slightly rubbish weekend in Ballarat, who cares? You just laugh and try again. In that low-stakes playground, people develop intuition — a feel for what these tools are good at, where they fall over, how to talk to them.

You can't mandate fluency. But you can make it personal, and let people fall in love with the thing on their own terms. And they bring that intuition back to work for free. The person who spent the weekend wrangling AI to plan their kid's birthday comes in on Monday genuinely better at wrangling it for a research synthesis.

5. Build an engine, not an event

Everything I've described so far — permission, a ceiling, a pilot, personal practice — that creates a burst of energy. But bursts fade. If you want capability, not just enthusiasm, you have to build an engine that keeps running after the initial excitement dies down.

We built two.

The first is our AI Capability Team. A standing group whose job is to capture what we're learning and deliberately give it away — tips, tricks, prompts, wins — across the broader division. Not hoarding the knowledge inside our team to look clever. And here's the secret that surprised even me: the act of teaching others is what cemented our own capability. You don't really know something until you've had to explain it to a colleague who's nervous about it.

The second is what we call the Innovation Hustle — a pilot squad that runs a real experiment every single week. Not theory. Not a quarterly innovation off-site. Every week, someone tries something, and then we share what we learned.

Why weekly? Because weekly is what turns a one-off into a habit. A monthly innovation event is theatre. A weekly hustle is a culture.

The pilot gave us permission. The personal practice gave us intuition. But the Capability Team and the Hustle gave us momentum that compounds — a flywheel that's still spinning today.

What happened

Design didn't die. Design got amplified. The parts of the job that used to eat the week — the grunt work, the manual synthesis, the first draft of everything — got faster. Which freed people up to do more of the genuinely human, genuinely strategic work that no machine is going to do for us.

The human change is the part I'm proudest of. The team that started out quietly afraid of AI is now the team that teaches the rest of the division how to use it. We didn't survive the threat. We became the people other teams come to because of it.

That's the difference between defending the castle and walking towards the thing you're afraid of.

Do this Monday

None of this required us to be the most technical team in the University. It required us to be the most willing. Here's the playbook, on one page:

  1. Name the fear, then reframe it. Don't pretend the threat isn't there. Point everyone at the real risk — standing still — and the real opportunity: being the team that's best at this.
  2. Adopt the ethos. Replace "we'd need a project for that" with "have you tried just doing it?"
  3. Start on a shared floor. Get everyone onto the same tool so a win for one is a win for all.
  4. Show the ceiling. Don't let people use a spaceship like a bicycle.
  5. Get air cover, then make it personal. A sanctioned pilot for legitimacy; personal practice for fluency.
  6. Build an engine, not an event. A weekly habit and a deliberate act of sharing outward. That's what compounds.

Whatever's making you nervous about AI right now — and it's okay to be nervous — I'd gently suggest the answer isn't a bigger strategy or a longer business case or waiting for someone to tell you it's allowed.

You can just do things. So pick the most boring, most repetitive thing on your plate, and on Monday, before you talk yourself out of it, just try.