My UX Team is Run Like a Circus

There is an old Polish saying, “Not my circus, not my monkeys!” This is used when something has devolved into chaos. Our current election cycle often brings up the reference that normalcy and sanity has devolved into a circus.6d36e782c1b48a128f4e53d063e134aa

The idea of the circus is energy, confusion and novelty. You never quite know what to expect – that’s why people go to the circus. When monkeys are involved, especially if they get loose, there’s a good deal of chaos as well. But that reality is that circuses are well run, highly synchronized and choreographed displays of ordinary people doing extraordinary things to the delight of others.  Whomever utters the saying, signals that they not the ring master of this disaster, mess or ball of confusion. The problems/monkeys aren’t from their show. They are just watching – it’s not their job to fix it. But in UX, everything gets back to the experience. Slow connections, bad data, poor responsiveness, accessibility issues, these all track back to the user experience. So it is our circus even if its not our monkey.

All members of a development team are responsible for the user experience of the end result. With DevOps, the entire team has the responsibility to satisfy the customer by maintaining the software in production. By blending UX and DevOps we draw inspiration from what I learned as a circus performer with a foundation of teamwork, trust, and audience feedback. Circus performers and UX teams are similar in that teams can embrace multiple disciplines to make system development fun, engaging and to thunderous applause.

The act of watching a circus is about witnessing amazing things. The breathtaking acts of physicality that brings audible gasps, rollicking laughter, thrills, excitement; it is all about the experience.

But how does it happen and how does it relate to UX and building amazing web products. There is so much more behind the scenes that happen before the lights turn on, the curtain raises, and audience fills in. And there are direct juxtapositions to application and web development.

Being part of a circus, like successful development teams, relies on teamwork, specialization, cross training, security (safety), the right equipment and, sometimes, a little luck. It’s based on training, repeated practice, and learning new things. It’s accidents and failures that we learn from; that missed trick that becomes the inspiration, and the inspiration that becomes the catalyst for dreams.

It’s also about building a team, and building it quickly. Where do you find this unique talent? It’s actually everywhere, but its hidden in plain site. There are the once-in-a-lifetime folks with broad skills (unicorns and freaks) and innovators; the dreamers, non-conformists, builders, and coaches, passing down skills. Its practice (hack-a-thons), and open experimentation, and getting that crowd feedback.

It’s about being bold and pushing yourself and your team to do something crazy. It’s getting outside of your comfort zone, and sometimes wearing tights in front of a crowd of strangers and enjoying every minute of it. But it is also about transforming not only yourself but also the culture. Circuses, like development methods and technology, evolves over the years to account for changing expectations. The formula is the same; push yourself, do something rad, entertain, and repeat. It is always about people, the ones on stage and the ones watching.

While in college, I was part of the Florida State University Flying High Circus while obtaining a Studio Art degree from a football factory (a limitation I fully understand). As a performer and coach, including acts like high-wire and teeterboard, my time in the circus prepared me to be a successful leader. I challenge my team to try new things, but mostly to enjoy doing them.

“We are the dreamers of the big dreams.” – Willy Wonka


I will be speaking next week about Circus and UX at GiantConf in Charlotte, NC. Join us.

May all of your days be circus days.


Improving the User Experience of Creating a User Experience

There are two types of users for everything we build; end users and those that build and run the system. Both sets of users can benefit from a better user experience. These benefits can be in the form of a productive, human-centric, quality of life improvements to the process of systems delivery. But it also can lead to uncovering that innovative spark that can be easily missed if we are not looking for it.

DevOps eliminates the all-day all-hands, end of release code push, thus freeing up the weekends of your staff, reducing stress, and positively adding to their work life balance. Adopting continuous development and delivery also reduces the ‘work in progress’ time as code ships when it ready, eliminating bottlenecks and gateways that cause buildup. Project plans are always based on best-case scenarios with some room for the unforeseen, but not much. Removing these bottlenecks improves the efficiency of developed code to be pushed. Communications and automation reduces human error. Projects can be run in ‘human time.’ Continuous monitoring used to track system efficiency, can also be used to track development progress and velocity.

Without employing a DevOps posture, small fixes are sometimes pushed off in favor of new features leading to UX debt. UX debt is the difference between the experience your current digital product versus how it can be improved if it would be given the necessary attention and resources. UX debt can stymie the maturity a product if it is never addressed, or pushed to that never to be realized defect sprint. What should concern the entire team is that widening delta between the original intent and the current outcome.

This can breed a culture in which smaller issues, which may seem unimportant, get over looked or never even attempted. This can also lead to less technical areas of practice, such as user research and concept validation are typically sacrificed for saving time and costs. The pace of feature building usually forces this sacrifice to the point that innovation and viable alternatives are never even attempted. What innovation are we missing by not coming up with and/or testing alternatives?

Instead of skipping steps to save time or money we need to ask, not only what does the user lose by not implementing the better solution? But what does the program or organization lose by not innovating?

Designing for continuous software delivery means being in step with the velocity of development while simultaneously listening to user feedback that gets translated into the next set of improvements. If we ignore UX for the sake of feature delivery, we can lose more than better project. We can lose credibility and future revenue.

At the end of the day for the end user or customer, deadlines, processes, checkpoints, and controls that govern the development of a digital product has no relevance. Satisfaction comes from the actual desired outcome, and that is independent of the internal workings of the organization.