In Jordan Peterson’s 12 Rules for Life, he addresses some very big questions and common lies we all tell ourselves. He presents the concept of finding meaning by being rooted in mastery and exploring something unknown. Deep engagement in work and life exists in the space between chaos and order. Chaos might look like becoming a first-time parent, switching from a designer role to managing, or traveling outside the country for the first time. Order is found in our routines, comfortable spaces and skills that have been honed and applied on a daily basis for years.
Too much chaos can be just as bad as too little. Being stuck in chaos without a solid foundation is not a good situation. It can turn out well, but most likely it will be painful and less than ideal. Likewise, abiding in order and routine without chaos can get old, fast. Throughout work and life, we need to find the right chaos-to-order ratio to grow and be challenged.
In a team’s process, moments of intentional chaos need to exist to push ideas further and foster personal growth. If the scope of impact is too limited or the repeated actions are too routine, engagement will slip and the output will suffer. I’m reminded of scenes from Office Space that satire how corporate monotony leads to atrophy and frustration. This is true in a work setting, but it also applies as a general rule.
Work should build on strengths and also require uncomfortable growth to create full engagement. That’s where meaning is. Let’s explore a few areas this concept can take shape in product teams.
Workshops are a great example of intentional chaos at work — they are ordered and also chaotic, and tend to bounce between the two. The team aligns around a problem space and dives in to the unknown while standing on their lived experiences or fostered skills and knowledge. They can face the chaos rooted in mastery.
Workshops might look like “falling with style” from the outside. But instead of looking in control while relying on chance, it’s all about leaning in to the chaos, knowing that control and order will come in time. When you see ambiguity and find more questions than answers, you know you’re on the right track. Instead of shying away from the discomfort, get it down on paper and tackle it as a team. Activities like assumptions and questions, customer journey maps and hopes and fears can help teams get the foggy things down on paper.
The element of chaos in a workshop also opens up collaboration to more disciplines. Disorder makes it clear that this is a work in progress and all are welcome to contribute. It’s the same reason designers create grayscale designs for early stage feedback. Low fidelity makes it clear that the designer is looking for feedback on the flow, interaction and idea behind the experience. A messy whiteboard covered in sticky notes works the same way. It invites collaboration and input from experts in other fields who need not know how to operate design tools.
Beyond dealing with a lack of clarity, workshops also push you and your team to create more ideas. Your best idea is not your first idea, as it goes. Too much structure can push teams towards grabbing the first logical solution and running with it. It might seem obvious or easy to achieve. Eventually, a solution has to be picked, so why not this one?
It’s crucial to set up space to get multiple, diverse ideas on paper to be explored, tested, and riffed on. What seems like the worst idea in the moment can mature or easily spark the best idea. Time-boxed chaos like a crazy-8s exercise can help generate ideas and ease the team back in to order through voting and storytelling. The important part is to set aside time specifically for idea generation to get the raw data out there.
The primary goal of workshops should be to meet ambiguity head on, turn it into opportunities, and come away with a shared understanding of the best ideas to pursue (and potentially abandon).
But what good is all the workshopping and ideation if none of it gets shipped? Half the battle is moving from chaos to a shared understanding. The other half is moving that shared understanding into a solid backlog so that the new understanding is implemented. Here’s a common workflow I’ve seen to move from workshop output to delivery:
- Get all the raw data down on “paper” (this could be a workshop, Figjam brain-dump, or whiteboarding session)
- Organize around common themes or objectives
- Validate those themes with stakeholders (this could be a storytelling deck for executives or interviews with customers)
- Create epics or initiatives from those themes
- Break those themes-in-disguise into smaller pieces that can be sized and assigned in sprints
There are a thousand ways to move through the organization workflow. Even if your team is not operating in agile sprints, the planning methods of the team need to glean from workshop output. In the end, the goal is to move from time-boxed chaos to structure so that ideas can see the light of day.
In chapter 11 of James Clear’s Atomic Habits, he shares a story about a college professor who divided his photography class into 2 groups. The first group, the “quantity” group, would be judged on how many photographs they produced. The more photos, the higher the grade. The second group, the “quality” group, would be judged solely on the excellence of their work. This group needed perfection in their work to get an A.
At the end of the semester, the best work was created by the “quantity” group, simply because they were smashing through ideas, trying different techniques and growing skills along the way. They also created a lot of failures. But in the end, the best output came from a process of tinkering.
Right now, a lot of my own work is on process and refining the deliverables expected from the team. Working in an agile process, the default mindset is to think about sprint deliverables as tangible value delivered to the customer. But if that’s the primary driver, we’re the “quality” group. We’re leaving tinkering to the side to focus on shipping perfection.
But the good news is that any high-level process can be tailored to defend valuable time spent tinkering and exploring. In agile, our team can create templates for stories about iteration and discovery where the deliverable is findings instead of shipped designs or code. That can be a required part of creating new components that involves all disciplines on the team with clear expectations and outputs.
With a shared agreement on the value of tinkering, we can hack process to defend the chaos we all need.