The 10-Minute Rule for Trying AI at Work
- Amy Westlake
- Mar 29
- 3 min read
Situation
It was a Thursday afternoon and I had a status update due.
I had all the inputs — notes from three different workstreams, a risk I'd been tracking, a decision that was still pending. I knew what needed to go in. I just didn't want to sit down and synthesize it.
So instead of writing it, I loaded everything into Gemini and asked it to draft the summary for me.
That was it. That was the whole move.
I wasn't testing a new workflow. I wasn't optimizing anything. I was just tired of staring at a blank page with too many inputs and not enough time.
It worked. And then I started wondering why I hadn't been doing this all along.
The honest answer: I thought using AI properly required a project. A learning block. A workflow redesign. I kept telling myself I'd explore it more intentionally, and that block never appeared.
Meanwhile, the same small frictions kept repeating. Rewriting status summaries. Cleaning up messy meeting notes. Pressure-testing an email before sending it to executives. None of it dramatic. Just low-grade inefficiency I had normalized.
The AI Move
So I gave myself a constraint.
If something would take less than 10 minutes to try with AI, I would try it.
No optimization. No perfect prompt. No workflow redesign. Just a quick experiment layered directly into real work.
The status update became the first real test. I had a rough paragraph, accurate but muddy. Too much context. Not enough signal. I pasted my inputs into Gemini and asked it to separate risks from updates, tighten the language, and flag where I was being vague.
Seven minutes. I still edited it before sending.
I wasn't trying to save time. I was trying to lower the threshold for trying.
The Shift
Because the bar was low, I did it again the next week. And the week after that. Then with meeting summaries. Then with decision briefs. Then with risk logs.
After a few weeks, something shifted. And it wasn't the outputs.
I started noticing patterns in my own writing. The ones that surfaced first were the most obvious: my language consistently softened when something needed clarity. Instead of "this decision is blocked," I'd written "we're still working toward alignment." Gemini would pull the harder version up. I'd read it, recognize it was more accurate, and feel mildly annoyed that I hadn't just written it that way.
The reacting-instead-of-structuring pattern showed up almost as fast. I'd hand it a messy set of inputs and watch how it organized them, and realize I'd been writing updates in the order things happened rather than the order they mattered.
The other patterns took longer. Over-explaining. Burying risk under context. They didn't show up in a single output. They showed up across several weeks of looking at the same type of task.
The value wasn't speed. It was visibility.
The Pattern
The pattern I'm seeing is this: constraints drive compounding.
The 10-minute rule isn't about saving time. It's about increasing experiment frequency inside real work. And when you repeat the same experiment across the same type of task, over weeks, you stop just seeing the output. You start seeing yourself.
Thirty small experiments inside the same recurring task began changing how I structured my thinking before Gemini was even involved. I started writing cleaner inputs. I started leading with the risk instead of the context. Not because I'd learned a technique. Because I'd seen the gap enough times to close it myself.
Without repetition, there's no compounding. And without a low enough bar to start, there's no repetition.
The Implication
If you want to try this, start small.
Pick one repeated task:
A weekly status report
A recurring meeting summary
A decision memo
Set a 10-minute cap. Run the experiment inside the real task. Stop when the timer ends.
You don't need a transformation plan. You don't need a prompt library. You don't need to redesign your workflow.
You need frequency.
The leverage doesn't show up in the first attempt. It shows up when you start recognizing your own patterns after the tenth.
What I’m Testing Next
I'm experimenting with a lightweight log of these micro-experiments.
Not to track productivity. To track patterns.
I want to see what actually compounds over 90 days, and whether repeated, low-friction experimentation meaningfully shifts how I design work, not just how I execute it.
Comments