The Playflow Challenge
In the concluding essay of Breaking Smart Season 1, I quoted Seb Paquet's snowclone of Arthur C. Clarke's line about advanced technology being like magic: any sufficiently advanced kind of work is indistinguishable from play.
This is not one of those predictions that just happens by itself, like a solar eclipse. It is one of those "future is easier to invent than predict" self-fulfilling prophecies, where it only happens if enough people start believing in it in an interesting way, and somebody actually invents it. Just as the industrial age was full of "workflows" and philosophies of workflows like "Taylorism" and "Agile" and "Lean", the Digital Age needs playflows, and philosophies of playflows. These won't just happen by themselves. They need inventing.
I don't have inventions to offer here (though I'm working on it), but I think I have a good handle on the right questions to ask. So for those of you interested in the future of work, here is something for you to think about: the playflow challenge.
A quick announcement before we get to that: I just added the first Special Topics video to the Breaking Smart Season 1 course, on the most common question I get asked: "Will software eat jobs?" I've never done more than a casual live Q&A 1-minute answer, so I figured it would be worth documenting a more careful long answer, which as it turned out, took me about an hour to articulate. The video will be public for the next 24 hours, after which only registered course participants will be able to view it.
Now on to the playflow challenge, which as it happens is the central known unknown in the "will software eat jobs" question.
The playflow challenge
1/ There is currently a growing, dim recognition of the ongoing convergence of work and play. It is slow and patchy as yet, and very unevenly distributed, but it's taking root.
2/ But much of the excitement around the trend is wishful thinking (imagining work lose the parts you don't like in merging with play), delusional (playing pure games and imagining it is work), or cynical (much of "gamification").
3/ There is also an element of ignorance and entitlement around interest in play-flow convergence. It's easy to get caught up in play-work convergence to the point where you forget that much of the world is still involved in doing hard, necessary, unpleasant work that needs to be done.
4/ There is not as much solid thinking and work on the concept as there needs to be. Play-flow convergence is NOT about masking or automating away the unpleasant aspects of work, and adding "fun" to what remains. That's shallow, and usually cynical gamification.
5/ Converged play-work will have a play-like soul within a work-like body. It is not that there will be no pain or unpleasantness. Recall actual play as a child. There were bruises, tears and fights on the playground.
6/ The play-like soul of the future of work will manifest in a different way: work becoming continuously challenging and therefore stimulating. Work requiring imagination. Work acquiring ludic qualities. Work fostering deep immersion.
7/ In Mass Flourishing, Edmund Phelps shows, through arguments and empirical data, that people enjoy work when it has exactly these qualities. In industrial work, it is rare and limited to a privileged few most of the time. "Mass" flourishing tends to be short-lived.
8/ To a significant extent, whether a behavior is work or play depends on the intent and attendant sensibility, not the artifacts or behaviors. It is play if you mean it as play. This does not mean it is not serious, or lacks harsh consequences for mistakes.
9/ Play for children is often associated with safety. Good play environments are often designed to be safe-fail environments, rather than fail-safe. Stimulating without being stifling. Bounded consequences, but not risk-free.
10/ For adults, play environments are sometimes designed that way -- think war-gaming or flying simulations, or EMT training using medical dummies. But in general, play-like work is simply work done with a play-like attitude.
11/ This does not mean it isn't serious or that it is sloppy. If you were designing a play-work converged environment for doctors, you'd want better surgery outcomes as the first consideration. Introducing play-like elements will only make sense if you can do that.
12/ The same object can be a tool or toy depending on what you're doing with it. Industrial grunt work might involve tangible behaviors and objects that might look like play. You could invent a game on a spreadsheet.
13/ Let's call a converged work-play behaviorĀ playflows, by analogy to workflow. To define a playflow, you not only have to define the behaviors and artifacts involved, but the attitudes and sensibilities that you need to bring to them, and methods to instill them.
14/ Here's the design challenge, for people interested in workflows and productivity. Call it a Breaking SmartĀ millennium challenge micro-X-prize ($100 prize if you actually nail it as judged by a jury I'll convene if I get any actual entries): Design and validate a system for supporting playflows. What do I mean by that?
15/ I'm serious here, so any entries have to be serious ones too. Not just you spitballing in an essay or powerpoint. It has to be a fully-specified system for a specific domain of "work" that you've actually tested with a few guinea pigs and proved-out to first order.
16/ Let me offer a few of my notes from my own attempts in this direction. The big conclusion I've reached so far is that play is a regime of behavior that can only exist between habits at one extreme, and projects on the other.
17/ In most workflow theories these two extremes are well-theorized: pure habits (things that can be almost fully compiled down to unconscious/barely conscious repetition) and pure projects (only moves if consciously moved, terminates at some point)
18/ The hard stuff is all in-between. We usually call them āprocessesā as in computation threads with foreground/background meta-states. These, as it happens, are the natural regime of play-like behaviors. Not all processes are play, but all play is process-based.
19/ Processes: a) have an evolving log-like state (long-term memory/history) b) repeat chaotically like a strange attractor so they are hard to make fully unconscious c) require frequent inspection, tuning and steering d) start once, terminate by fatal crash
20/ Play has these characteristics too. Specific games may end, but play in a domain is an indefinitely extended conscious behavior. Johan Huizenga's book Homo Ludens explores the play-like character inherent in all human activity. Highly recommended.
21/ Sometimes you're in a "finite game" mode, where you're playing to win. Other times you're in an "infinite game" mode, where you're playing to figure out how to continue the game. As a subjective experience, play extends across these alternating regimes seamlessly.
22/ Processes differ from habits in that their memory accumulates and can only be lossily compressed. In other words, the history of a play behavior matters, even if you're not aware of it during a particular session. Play has a past and a future. It is not atemporal.
23/ Habits on the other hand tend to zero marginal new information after a few iterations. Example, you donāt learn much consciously the 10,000th time you brush your teeth. But 10,000th page read?
24/Ā Processes differ from projects in that they are self-perpetuating and termination is aĀ pathology. Book readers will always have a queue. Book reading is an infinite game. Empty queue = death. You will always try to continue the game. Not āworkā towards ālast book, then Iām done.ā Inbox Zero would be a cancerous idea for a play-like process.
25/ Habits are learning projects. Other projects are āwin to finishā finite games. Both live for a while in a system like GTD and then pass on. Habits till theyāre learned, other projects till youāve won or lost. Processes involve learning, but don't terminate at win/loss like projects, or sink into the unconscious like habits.
26/ Processes are death-do-us-part activity threads. Hereās my book-reading process state for example. Note how it exemplifies everything Iāve said above. A year out of date, but the state structure is still the same. Every book I read (or pretend to) is a finite game. Every time I pick a next book to read, I'm playing an infinite game.
27/ How are these modeled in workflow systems? In GTD (David Allen's Getting Things Done system), a book youāre reading now would be a "Project", and the next chapter might be a "Next Action", but typically nobody tracks books this way. The underlying "habit" supporting the reading is just literacy.
28/ The habit+project part of reading books is too trivial to track. The hard part is elsewhere. All the complexity is in what the GTD system labels the "Someday/Maybe" list. What we might call the under-theorized āquantum indeterminacyā part of GTD.
29/ My book reading list is in some complex superposition of read and unread. See Pierre Bayardās book How to Talk About Books You Haven't Read for a fun meditation on this aspect of the reading life.
30/ If youāve used GTD or similar system for at least a year, youāll have noticed something: the Someday/Maybe or equivalent list moves very slowly. Most Someday/Maybe items come from āplayā, āmeaningā or āenrichmentā areas. You donāt someday/maybe do taxes or a work deliverable.
31/ This is not an accident. Process activities draw disproportionately from the nice-to-have enrichment side of life. Each item is individually unnecessary, but if you donāt do some subset, life will seem meaningless. Book lists, bucket lists, collection hobbies, tinkering/making hobbies...
32/ Subtlety: With books, history matters as much as the future. A book doesnāt ever quite exit the someday maybe list because it can only be declared ādoneā if it doesnāt merit another reread. A book is a potentially infinite-pass āprojectā if you like it enough.
33/ That is the setup. Now imagine a life where 90% of the energy is in processes like this and the project/habit parts are trivial. Everything is a thread with an extended past and an indefinitely extended future.
34/ Things that have this character tend to have a someday/maybe character. Nothing must *necessarily* be done, itās all optional, but you want a certain amount of energy contained in that process. Example: book reading, travel, hobbies, key relationships.
35/ Further, imagine that these processes interact like in a distributed computing system, full of CAP theorem messiness. Your travel inspires your reading inspires your game design hobby inspires more travel. You want to keep this fertile reaction going. But not to the point where the energy dissipates.
36/ The playflow challenge is to design a system like GTD where āprocessā is the first class citizen, indefinitely extended memory is valuable, there are no due dates, nothing in particularĀ must be done, and the governing spirit is play not work.
37/ To think carefully about playflows, don't just think about your favorite kinds of work. It's not hard to come up with a "playflow" for something that's already basically kinda fun, like cooking. But can you make taking out the garbage a playflow? How about firefighting? Brain surgery?
38/ When you start thinking about the hard cases, you realize play is not just a mode of behavior. It is also a social performance that has characteristics that are seen as appropriate in some contexts, but not in others.
39/ If you come up with a surgery protocol that handles more risky cases AND has a lower mortality rate, but looks like the surgical team is clowning around, you're going to have a problem selling it. A big part of play-flow convergence is leveling up the associated philosophy, cultural contextualization, and general literacy in understanding the "performance" properly.
40/ These are not easy problems. When I first tweeted a draft version of these thoughts, I had quite a few people eager to tell me about their "systems". Very few of them passed even the sniff test on difficult domains, social performance perception, etc. So if you have an instant answer it is probably wrong.
41/ To help you, here is a set of tests your playflow design must pass: a) It must be applicable to multiple domains, at least one of which is a hard, serious-consequences domain b) It must induce ludic performance states in play-workers c) It must present a view to spectators that invites encouragement rather than resistance.
42/ To be honest, I'm not expecting significant evolution of playflows within my lifetime. These kinds of changes in the nature of work take generations to establish. But I suspect we'll see at least a handful of "unevenly distributed future" cases emerge within the next decade.
_Feel free to forward this newsletter on email and share it via the social media buttons below. You can check out the archives here. First-timers canĀ subscribe to the newsletter here. More about me at venkateshrao.com.Ā _You can follow me on TwitterĀ @vgr
Check out the 20Ā Breaking Smart Season 1Ā essays for the deeper context behind this newsletter. You may want to sign up for the Season 1 Online Workshop too.
Copyright Ā© 2019 Ribbonfarm Consulting, LLC, All rights reserved.