Everyone Should Work On Site

Written by David Ortinau

In February 2013 Yahoo CEO Marissa Mayer issued a company wide memo establishing a new, non-negotiable policy that all employees must work in a company facility, aka “On Site”. A few months later when pressed that people are more productive when alone, Mayer countered “they’re more collaborative and innovative when they’re together”.

In October 2013, Yahoo’s senior director of real estate and workplace Julie Ford-Tempesta is quoted as saying “employee engagement is up, product launches have increased significantly, and agile teams are thriving…(the) workplace has become a catalyst for energy and buzz.”

Who doesn’t want better collaboration and innovation, energy and buzz, especially if you’re in a highly competitive industry where your ability to innovate means sink or swim.

Rendr is a remote company that believes heavily in the value of being on site; we just think of on site somewhat differently than “physically together”.

“On Site” Often Misses the Point

“On Site” is not a goal, but a means to achieving the results of collaboration, innovation, knowledge sharing, energy, and deeper relationships. Those relationships are certainly within the team, but also without.

In the early days of working with the startup ThisLife, our team had vibrant communication between several remote groups in Palo Alto, San Francisco, Boulder/Denver, St. Louis, and Amsterdam. The energy in our Skype chat was excellent. We would have ongoing dialog about what we were doing, why we were doing it, and how we were going to pull off a fantastic user experience.

When the majority of the team was consolidated to an office in Palo Alto, and eventually acquired and moved to Shutterfly, that vital communication died. The team still had several remote workers, but when the majority of the team stopped paying attention to communicating through remote channels such as Skype, that culture withered.

(Source: Glassdoor)

You could say that the “site” moved from Skype to Redwood City. The culture of collaboration and innovation suffered.

If any one person on your team is remote, your whole team is remote.

Remote Is a Reality

The Rendr team grows and shrinks with the demands of our workload, as most teams will. At any given time we may have team members active in Romania, Spain, Brazil, and across all time zones in the US. This allows us to work with the most talented people we can cajole into joining us from anywhere in the world.

“On Site” for us isn’t reasonable in the sense that Marissa Mayer intends it. But we must collaborate. We must be innovative. We must provide the best results to our clients and partners.

We’ve asked ourselves, what could “On Site” mean for our remote team? We agree, collaboration and innovation are valuable and desired. These are culture issues, and have very little to do with physical proximity. You can just as easily foster these through team communication tools. Our team currently uses Slack. (Can someone please put a bounty on a Google translate integration with Slack?)

Remote Can Be Connected

I’ve often seen this scenario play out on teams I’ve managed. A software engineer receives an email report of some bug…some frustration a user has with his or her software. The engineer experiences a wave of disappointment. The user has clearly not used the software in the proper way. Names are called. Things are muttered under the breath. Knowing the obvious solution, our fearless engineer sighs deeply and writes some code to defend against such user ineptitude. A few days after delivering this fixed build the inevitable report comes back. The user is still experiencing the bug. Rinse and repeat.

The not-so-novel solution: screen share.

This is rarely a technology problem. It is most certainly a communication problem. And more than that it’s a relationship problem. The user doesn’t know how to properly express the problem. The engineer doesn’t fully comprehend the goal or the steps being taken by the user. And neither has much empathy for the other in this scenario.

As soon as the engineer sees what the user is actually doing, the whole issue comes into focus. Even more importantly, the seeds of empathy are planted. A little small talk goes a long way in this regard. I’ve learned to not underestimate that. Look for common ground to build a relationship on.

We must build better relationships through better communication.

Field Trips Can Fill The Gap

At Rendr, we campaign to have personal contact with the people who will be using our solutions. Recently I traveled to another city and state just to spend a few hours with sales associates in a retail environment and observe customer interactions. In some cases, this process of investigation can lead to some fantastic revelations of previously unseen opportunities. I call these little excursions “Field Trips”.

(Source: New Balance, Boston)

I would love to now unveil an inspirational story of how that trip blasted open my eyes to some as-yet-undiscovered mobile application strategy that will surely revolutionize how we do retail. Alas that didn’t happen. While “aha” moments are wonderful, and most certainly cherished, something much more foundational and rich happened. I gained understanding. I learned what motivates the associates day in and day out to keep returning to that job, not just as a stepping stone to a “real” job, but as a career. I learned how they compete with one another and yet work collectively as a team to benefit everyone involved. I learned how they truly valued their customers and worked diligently to identify their needs and serve them. I learned how fearful and defensive some customers feel coming into a retail environment, and how they announce “I know exactly what I’m looking for” to try to defuse what they perceive as a threatening situation. And more to the point, I was able to feel it.

How could that not help me to provide a better solution for them? Now my code has a much better shot of being aligned with the strategy. At a minimum, when we introduce a developer into that environment it fosters a deeper understanding of why we are building a software solution and who it is impacting.

It Changes You

How could that not help me to provide a better solution for them? Now my code has a much better shot of being aligned with the strategy. At a minimum, when we introduce a developer into that environment it fosters a deeper understanding of why we are building a software solution and who it is impacting.

Ed Catmull, President of Pixar and Disney Animation, describes the common practice of “Research Trips” within their process.

You’ll never stumble upon the unexpected if you stick only to the familiar. In my experience, when people go out on research trips, they always come back changed.

If you haven’t read his book *Creativity, Inc.: Overcoming the Unseen Forces That Stand in the Way of True Inspiration*, make it a top priority.

(Photo Source: Disney/Pixar)

To capture the kitchen scenes in *Ratatouille* they visited high-end French restaurants. To accurately portray something as seemingly trivial as the clang of the trolley bell in *The Princess and the Frog*, the Disney team attended the Krewe of Bacchus parade on the Sunday before Mardi Gras in Louisiana.

I realize that this level of immersion and experience isn’t possible for everyone or in every situation. It would be unrealistic to fly 100 developers to another city to do this kind of observation. While finding ways to have a UX professional gather that intelligence and communicate it to a team of developers (cue Office Space) is a good start, we can certainly find ways to augment the experience.

Be Your Own User

Riot Games, maker of the very popular League of Legends game, has a policy encouraging their staff to spend time every day playing the game. This makes sense since their manifesto states: “We aspire to be the most player-focused game company in the world.”

(Photo Source: RiotGames.com)

Though not explicitly encouraged, when working on ThisLife we would regularly spend time using the service, loading media, matching faces, tagging photos, creating stories to share, and so on.

This certainly doesn’t replace the importance of getting your product into the hands of your target audience and observing them closely. What I’m talking about here is more than the age old concept of “dogfooding” to test and promote a product. It’s about gaining an understanding of what your users are experiencing and feeling as they engage with a product and service.

When I think of those who use apps we build, I often think of Scout learning to empathize with Boo Radley:

Atticus was right. One time he said you never really know a man until you stand in his shoes and walk around in them. Just standing on the Radley porch was enough.

Plan Your Own Field Trips

At Rendr we encourage “Field Trips”. Perhaps we cannot all be the person traveling to exotic retail locations, but we can come up with other options. If it’s a retail environment, we go find that environment or a similar environment to experience and observe. If we are building an application for a specific activity, we want to put ourselves into that activity to understand how it’s going to feel.

We want to know what it’s like to be the person using the product. We get outside. We go to the store. We talk to family, friends, and complete strangers. We buy gadgets and adopt them into our lives to experience them first hand.

Perhaps “I once used a Windows Phone for 6 months” is the new “I lived in Europe for half a semester”.

(Photo Source: Flicker: nokia_fan)

I love this statement by Jared Spool:

“The big difference that’s arisen in this new agile world is how integrated the team is. No longer is UX design owned by the UX designers: everyone on the team now has design responsibilities. That means that everyone needs to be informed about what the design is trying to do.”

In that spirit, we prototype applications for our target audience, and more so for our entire team. Everyone gets a shot at it, to experience it, and to provide feedback. Using tools like Sketch and InVision are a great way to get up and running with that workflow quickly.

Get On Site, Out There

When a team is confined to a singular channel of communication, whether it’s the physical 4 walls or the walls of your Slack channels, it has the opportunity to become an echo chamber. At some point someone has to go outside those boundaries and bring new insight and new perspective into the mix if we are truly to be innovative.

Travis Sheridan is a founding Executive Director of Venture Cafe in St. Louis, a foundation dedicated to fueling innovation through “conversation, collaboration, and storytelling.” At a recent local event “XperienceLab Xchange: Innovation St. Louis” he commented that one of the ways that Venture Cafe attempts to foster innovation is by bringing diverse perspectives together in conversation.

Consider your current projects and ask “what field trip could I take this week for _____?” Take an opportunity to talk to a friend, or even better a complete stranger about what they do. Eventually they will ask what you do, and you can describe some aspect of your project. Get their input. Chances are very good they will have a different perspective from your own. Don’t condemn it, just listen and try to understand it.

Guess what? You just collaborated with a complete stranger. You are now innovating. That’s the best “On Site” of all.

(Feature Photo Source: Flickr, Manuela S. Scheuerer)