More than making money… more than that feeling of launching a new product, feature, website, or app… the idea I am coming to value most in my professional life is the feeling of “play”. Sometimes play is being on my own with high autonomy and low consequences, sometimes it’s getting to choose new and fun technologies, but where play is most valuable is when it involves other people.

I’ve talked about this before in the context of prototyping and play and how we worked at Paravel. It’s a lot like playing baseball; each member of the team showing up to practice, volleying work (in screenshots, short videos, or demos), pushing changes, communicating thoughts and challenges in the moment outside the confines of slotted meeting times. Me and my coworkers, having a catch.

Dan Mall and Brad Frost call it “The Hot Potato Process”, a frequent back and forth between design and development. Design and code happening in tandem, informing each other, producing something greater than the sum of its parts. It’s a spontaneous process where the details and fidelity of an application slowly fill in over time like a progressively loading JPEG on a slow connection.

If there’s a downside to the Hot Potato process it’s that there’s a lot of re-building mid-flight as new requirements trickle in or you discover new constraints. When you build frequent iteration and circling back into the process, it can lead to a feeling of never being “done”. That is a tax on cognitive load, like open browser tabs, that may not neurologically suit everyone. Others might even prefer a more linear assembly line process.

If I had to choose which process I prefer, I’d pick reworking a component over-and-over in a Hot Potato process versus other alternatives. One common project pitfall with waterfall and faux-agile is over-committing to a design/idea that’s difficult to achieve in code and you blow scope as deadlines loom. There’s some research into why projects fail and over-committing is near the top. Unless everyone is willing to radically cut scope, it puts a lot of pressure on developers to pull a rabbit out of their hat and save the day.

When playing catch you deliver a working solution at each checkpoint. You are collectively iterating towards something better. When everyone is looking at working code (or a prototype) instead of a theoretical component, you can have more informed conversations about the costs/benefits/timelines of suggested improvements. That level of collaboration is a high bar and only works when you’re working together, showing up, building trust, and there’s a tight loop passing the ball back and forth.

In Play, Stuart Brown, M.D. studies the value of play from a psychological and biological perspective. Why do we play? What evolutionary benefit is there to it? Wouldn’t we be better off as hyper-efficient single purpose killers as opposed to back-flipping dolphins or dogs carrying enormous sticks? Brown suggests animals that play tend to adapt better to an ever changing environment and climate. The ability to play and adaptability are uniquely linked. Abstracting that to the tech sector, play within an organization seems more valuable than ever in the constantly changing field of technology.

Maybe, we need more play at work.