The Cognitive Case for Play in Technical Work

The best work I’ve ever done felt like play.

A few years back I ran marketing, website, docs, and community for a company. Reviews existed - everything shipped through them. But I had genuine autonomy to iterate between them. Within a few months the pages I was working on were converting at five times their previous rate. Not from a plan. From having space to find out what actually worked.

I’ve run the same work inside heavier structures - briefs approved before anything starts, every change requiring signoff, review cycles running weeks. The output was different. The skills weren’t.

The variable wasn’t review. It was play.

I’ve written about what that process looked like - the SEO work and the DevRel sprint - if you want the tactics. This post is about why the conditions that made those tactics possible were the harder problem.

The planning trap#

Most organizations treat creative and technical work like a construction project: specify everything upfront, build to spec, review at the end. The software industry spent a decade learning this doesn’t work. We call the failure mode waterfall.

The problem isn’t review. It’s that planning-first changes the cognitive frame before anything has been tried. When you know your output will be evaluated, you optimize for the evaluation. You take the safe path. You narrow toward what will pass rather than what will work. Teresa Amabile’s research at Harvard showed this effect is measurable. She described the principle directly:

“People will be most creative when they’re motivated primarily by the interest, enjoyment, satisfaction, and personal challenge of the work itself, and not by external pressures or external motivators.”

— Teresa Amabile

People who expect external evaluation before creative work produce less creative output. Not from lack of effort. From the wrong kind of attention.

The cognitive frame that actually produces good iterative work looks different. It looks like play.

Defining play#

Play, in the context of creative work, is a state of engaged experimentation where process matters more than any single outcome, errors are cheap and informative, and the primary driver is curiosity rather than compliance.

To be clear: this isn’t about carving out a separate “play time” alongside real work. Play is a quality of engagement, a way of approaching the work itself. The argument is that certain process structures make it impossible to sustain that quality - and that most teams never realize what they’re missing.

Stuart Brown, a psychiatrist who spent decades studying play, argues it’s a biological drive as fundamental as sleep. His conclusion:

“Play isn’t the enemy of learning, it’s learning’s partner. Play is like fertilizer for brain growth. It’s crazy not to use it.”

— Stuart Brown, Play

Environments that eliminate the conditions for play don’t produce safer, more predictable output. They produce worse output, more slowly.

Every serious creative discipline has figured this out. Writing workshops separate generative drafting from editing: write without judgment first, revise later. Design thinking diverges before it converges. Julia Cameron’s framework in The Artist’s Way is about recovering the play state from years of accumulated external judgment. The morning pages work because there’s no audience, no evaluation, no stakes. This isn’t personal development philosophy. It’s a structural feature of how creative work functions.

Why organizations default to the opposite#

James March’s 1991 paper “Exploration and Exploitation in Organizational Learning” is one of the most cited in organizational theory. His argument: organizations face a constant tradeoff between exploitation (refining what already works) and exploration (experimenting toward what might work better). Exploitation produces near-term returns. Exploration is uncertain but necessary long-term.

The trap is that adaptive processes naturally favor exploitation. Review cycles, approval structures, KPI gates: these are exploitation machinery. Good at refining a known thing. Applied to work that first needs to be discovered, they’re the wrong tool entirely. March predicted that organizations over-indexed on exploitation would be “effective in the short run but self-destructive in the long run.” Heavy planning structures don’t just slow exploratory work. They apply the wrong logic to it.

I’ve watched this exact dynamic play out. Teams that had been genuinely creative when I joined them became incrementally more conservative over 12-18 months - not because anyone changed, but because the process around them did.

The environment has to support it#

Amy Edmondson gave the canonical definition of psychological safety:

“A shared belief held by members of a team that the team is safe for interpersonal risk taking.”

— Amy Edmondson

That’s the other half of what play requires: believing errors won’t be penalized. Edmondson’s work, later validated by Google’s Project Aristotle, showed psychological safety is the single most important factor in team performance. In practice, it means teams where:

“No one on the team will embarrass or punish anyone else for admitting a mistake, asking a question, or offering a new idea.”

— Google re:Work, Project Aristotle

Teams with it experiment more, learn faster, produce better work.

Review-heavy cultures erode this not through malice but through repetition. Every judgment cycle signals that getting it wrong is costly. Eventually people stop experimenting before they’re told to. The play state disappears not because anyone banned it, but because the environment made it feel too risky. Same person, different environment, wildly different output. It’s not talent that varies.

The most capable people I’ve worked with were also the most sensitive to the environment. Give them psychological safety and room to experiment, and the ceiling on what they produce is surprisingly high. The same person in a risk-averse environment produces process-compliant work instead.

Agile already solved this. Sort of.#

The software industry didn’t invent agile because it sounded nice. It invented agile because waterfall kept failing on complex projects where requirements weren’t fully knowable upfront. The Standish Group CHAOS Report consistently shows agile projects are roughly 2x more likely to succeed than waterfall, with large waterfall projects failing outright at high rates.

The insight: if the plan is always partially wrong, the overhead of maintaining a detailed plan crowds out the work that would tell you what’s right. Smaller iterations, faster feedback, lower cost of being wrong. That’s not just a project management style. It’s a position on how complex systems reveal themselves: through interaction, not specification.

That principle applies beyond software. It applies to content, design, marketing, any domain where quality emerges from iteration rather than execution of a predetermined plan. Most organizations nominally accept this for code and then default to waterfall thinking for everything else.

What to do instead#

This isn’t an argument against review or accountability. It’s about sequence and weight. If you’re a manager, your role in this model is to protect the conditions: shield uninterrupted work time, review results rather than activity, and resist the urge to check in mid-experiment. The output is your accountability. The process is theirs.

Separate creation from evaluation. Don’t let evaluation enter the room during generation. Timebox a period where you run experiments without a formal review gate. Review results, not process. Every creative discipline that produces good work does this.

Measure after, not before. KPIs are learning tools after an experiment, not gatekeeping criteria before one. “What did we learn?” is a more useful question than “will this hit our number?” The 5x result I described wasn’t planned. It was discovered, then measured.

The SEO work I described here ran on exactly this rhythm. I shipped changes every week and measured 2-4 weeks later, cross-referencing Search Console, Plausible, and Ahrefs to see what moved. There was no way to know which changes would work before shipping them - the data didn’t exist yet. The KPI came after the experiment, which is the only place it’s actually useful.

Make experiments small and reversible. The reason upfront planning feels necessary is that big bets require justification. Small, reversible experiments don’t. Version control exists. Rollback is one command. The perceived risk of trying something is usually much higher than the actual risk.

Log what you tried, not what you planned. A record of experiments: what you shipped, what you learned, what changed. This gives you accountability without pre-specifying outcomes, and makes the value of iteration visible to people skeptical of the approach. Over the three-month sprint I wrote about here, I tracked 200 PRs against URL-level performance changes post-deployment. That record did two things: it showed me what was working faster than intuition would have, and it gave skeptical stakeholders something concrete to look at instead of a plan I’d written before I knew anything.

Protect continuity. Complex iterative work requires holding a coherent mental model of the system in your head. Status updates and check-ins mid-experiment don’t just waste time. There’s a neurological reason they’re so damaging. Researchers describe what happens to the brain during flow:

“Flow is a state of transient downregulation of the highest cognitive hierarchical component, the prefrontal cortices.” People in flow “become so absorbed in the activity that they do not have any attention to spare to become distracted by anything else.”

— Frontiers in Psychology, flow states research

Anything that triggers self-evaluation re-activates exactly the circuitry the flow state had quieted. You don’t just lose time. You lose the state. Protect blocks of uninterrupted work the way you’d protect a production deployment.

Play and accountability aren’t opposites#

The concern is fair. But accountability and play aren’t in conflict - the sequence is.

Amabile’s research distinguishes between two kinds of measurement: controlling (you must do it this way, here’s how it’ll be judged) and informational (here’s what happened, here’s what we learned). She described the mechanism:

“By putting people under conditions where they expected external evaluation of what they were doing… all each of those conditions and related conditions led to a decrease in creativity.”

— Teresa Amabile

The first kills creative output. The second can enhance it. The argument isn’t to remove accountability. It’s to move it to where it’s useful: after the experiment, not before it.

I’ve had this called out directly: “sounds like you just want to ship without approval.” That’s not it. The distinction is whether measurement comes before or after you have information worth measuring. I made the practice side of this argument, with the DORA data and the pottery story, in Ship the Ugly Pot.

Does this require experience? Yes. Play without enough context to hold a coherent model of what you’re working in is just chaos. A junior contributor doing this without a more experienced collaborator reviewing work regularly isn’t playing - they’re guessing. The guardrails don’t disappear; they shift. Instead of gatekeeping before the work, review happens after each small experiment. You still need someone who can tell you when you’re heading in the wrong direction. This applies most directly to individual contributors and senior practitioners who know the territory well enough to recognize what they’re finding.

---

The project I described at the start wasn’t special. The domain wasn’t unusual. It worked because the conditions for play existed: enough autonomy to experiment, lightweight enough review that I could move between tests quickly, and enough uninterrupted time to keep a clear picture of what I was building in my head.

When those conditions exist, work tends to produce something. When they don’t - when every change needs a brief, every brief needs a review, and every review runs weeks - the work tends to produce process artifacts instead.

I’ve watched this pattern hold for fifteen years, across startups, scale-ups, and enterprise teams. The work that mattered wasn’t the most planned. It was the work where there was enough room to find out what worked.

The Artist’s Way is about recovering creative capacity that most adults have had conditioned out of them by years of evaluation. Cameron’s prescription: create without an audience, protect the generative phase, separate creation from judgment. It sounds like self-help. It’s also just accurate about how good work happens.

Play isn’t the opposite of rigor. It’s the precondition for it. You can’t refine something you never found. And you won’t find it inside a planning doc.

---

Common questions#

What does play mean in the context of work? Play, in the context of creative and technical work, is a state of engaged experimentation where process matters more than any single outcome, errors are cheap and informative, and the primary driver is curiosity rather than compliance. It’s a quality of engagement with the work itself, not a separate activity alongside it.

Why does upfront planning hurt creative work? When you know work will be evaluated before you start, you optimize for what will pass rather than what will work. Teresa Amabile’s research showed this measurably reduces creative output. The issue isn’t planning itself. It’s that planning-first installs an evaluative frame before exploration has happened.

How is this different from agile development? Agile is the closest institutional analogue, and the underlying insight is the same: complex systems reveal themselves through iteration, not specification. But agile is a project management framework. This is about individual cognitive state - the quality of engagement during the work itself, not just how the work is organized at the team level.

How do you stay accountable without upfront KPIs? Measure retrospectively, not prospectively. Ship a small experiment, then measure what happened. “What did we learn?” is a more useful question than “will this hit the target?” You’re not removing measurement. You’re moving it to after the experiment, where it’s informative rather than constraining.