I recently celebrated nine years as a software developer at Walt Disney World in Florida. It is the longest I have ever stayed with a single company in my nearly 30-year software development career. Not coincidentally, it has also been one of my most rewarding. In this post I will describe a philosophy of Guest Service known as Walt Disney’s Four Keys Basics. In a follow-up, I will discuss how to apply these basics to software development.
In case you are wondering, none of this is secret or confidential information. The company has made much of this information public. If you are interested in learning more about Walt’s theories of Guest relations, take a look at Be Our Guest, a book by The Disney Institute.
Soon after being hired at Walt Disney World (and I presume other Disney Parks), each new “Cast Member” is sent to a class known as “Traditions,” a half- or all-day course introducing the attendee to the basics of Guest Service, company history and culture, and a few surprises. It does not matter if the individual is a new executive or a College Program participant, everyone takes Traditions.
I attended Traditions on May 10, 2011, and it was where I first learned about “Walt Disney’s Four Keys Basics.” Briefly, the four keys are as follows:
The order they are presented is important, as each one supersedes the ones that come after. In other words, safety is the most important key.
I practice safe behaviors in everything I do.
Guest and Cast safety come before everything else.
To illustrate, I was at Epcot with my family one night. We were waiting for the start of Illuminations: Reflections of Earth. If you have never seen it, Illuminations featured fireworks, fire, water, and lasers, all set to a powerful symphonic score. The show was presented primarily in the center of World Showcase Lagoon, which means it is visible all around Epcot’s World Showcase. Unlike most fireworks shows, much of the show took place low to the water. This meant that the “best” viewing spots were right against the railing. Sometimes there were Guests who decided that the railing was not quite close enough.
On this particular night, a young couple decided they needed to cross the railing and get closer. I think they simply wanted to get a cool picture of themselves in front of the lagoon. What they apparently did not know was that Illuminations featured perimeter fireworks, and one of the launch tubes was very close to where they decided to stand. Before I could get their attention and warn them, some Epcot security personnel appeared seemingly out of nowhere to get them out of harm’s way.
I have seen similar concerns for safety with Guests around broken glass, spilled food, and other “accidents.” I have never witnessed a Cast Member put safety aside for any reason.
Safety is not limited to physical dangers, either. A few years ago a number of Technology Cast were asked to inspect and secure every credit card terminal throughout the entire resort. We were provided with anti-tampering stickers and a checklist of things to investigate. Teams of two or three were assigned to a specific area and dispatched prior to opening. My team was assigned to Frontierland at Magic Kingdom. At one point, there were only three of us on Tom Sawyer Island, which was pretty cool.
I go above and beyond to exceed Guest expectations.
The next most important key is Courtesy. As long as safety is not compromised, Disney Cast Members will do everything in their power to make every Guest feel like a VIP. This is not an abstract concept. You may have heard of the “Disney point.” Cast Members are taught that pointing with the index finger is considered rude in some cultures. Rather than worrying about who might be offended, we are instructed to point with two fingers or all five.
Cast are taught to speak to children at their level. You will often see Cast Members crouching down to speak to children eye to eye. They often refer to child Guests as “prince” or “princess.”
If you are visiting as a Guest and are wearing a button displaying a birthday, anniversary, wedding, or other celebration, most Cast Members will go out of their way to comment on it and congratulate you.
Courtesy extends to more than this, however. Disney Cast are empowered to help make things right when things go wrong. This empowerment goes beyond the Cast Members you encounter in the Parks.
One night I was at Disney’s Boardwalk Resort, waiting to meet another Cast Member for dinner. While standing on the boardwalk, overlooking Crescent Lake, I suddenly heard what was clearly an exclamation of frustration. Turning to look, I saw a young family who had just left the ice cream parlor. One of the children had dropped his ice cream cone and was on the verge of tears. I am not an operations Cast Member, but I too am empowered to help wherever I can. I went over to them and introduced myself to the mother, and offered to help them replace the ice cream. I went into the ice cream parlor, explained the situation, and got a replacement. As I returned to the family, the mother thanked me profusely and then proceeded to tell me how that little action had made their day.
Other examples of courtesy can be seen anytime a Guest receives a “Magical Moment.” These are usually minor surprises, and I love being part of them. I have seen Guests surprised with free snacks, Fast Passes, fireworks viewing upgrades, and more. One of my favorites is the “Parade Marshall” family, selected from the day’s park Guests to ride in the front vehicle of the daily parade. If you have ever been the recipient of a Magical Moment, you know how special they can be.
I ensure my area is show-ready at all times.
“Show-ready” implies that the parks, resorts, attractions, restaurants, and everything else are always ready for Guests to experience and enjoy. Appearances, decorations, and theming should be internally consistent. Everything should be clean and free of distractions.
Cast Members can ensure that an attraction is show-ready by keeping their areas free of distracting clutter. They will immediately report any maintenance issues, and take action to correct issues where appropriate.
Every Cast Member is expected to help keep the parks and resorts clean, even when they are not on the clock. If I am visiting a park and see some rogue trash, I will (safely) dispose of it. If I cannot do so safely, I will find another Cast Member who is working, who can summon the appropriate custodial personnel.
You may have heard the story of Walt Disney seeing a cowboy walking through Tommorrowland in Disneyland Park on his way to Frontierland. That jarring juxtaposition is an example not being show-ready. It made such an impact on Walt that he insisted that Disney World in Florida be designed in such a way as to make that type of situation far less likely. The result was the Utilidor (via Wikipedia).
I perform my role efficiently so Guests get the most out of their visit.
Disney Parks are always looking for ways to make the Guest experience more efficient. This has led to such innovations as FastPass+, Mobile Ordering at Quick Serve Restaurants, Memory Maker Photos, Magic Bands for park and resort entrance, and more.
If you have experienced the virtual “boarding parties” for Rise of the Resistance in Star Wars: Galaxy’s Edge, you have seen one of the most recent examples of Efficiency first-hand.
Walt did not have software development in mind when he talked about the four keys. However, I am not an Operations Cast Member. I do not often work with Guests. I do not work in the parks, except for an occasional volunteer shift around Christmas and Easter. Because of that, it was not clear to me how I could leverage the Four Keys in my day-to-day role. As a member of a team known as the “Delivery Center of Excellence,” this felt like an oversight. Our job was, as one manager put it, to be the conscience of the software delivery organizations.
I took it upon myself to try to align some principles and practices to those four keys and come up with my own list. I share this list with you, with a warning that it is by no means exhaustive.
I keep on top of and implement current secure coding, source code control, and data security practices.
How many times have you been more than halfway through a project, and had someone start talking about password storage, PCI Compliance, or a security audit? Working for a large enterprise firm, it has happened to me more than once. Over time, it became clear that security needs to be considered as early as possible in the project. It should not wait until a security audit late in the game.
In the 21st century, you simply cannot skimp on security. Like it or not, you are responsible to safeguard the private information given to you by your software’s users – your Guests, as it were. If you accept payment card information (PCI) or collect personally identifiable information (PII), for example, you may be legally liable should any of information be publicly released or stolen.
If you do not want to be responsible for it, then consider not collecting it in the first place.
Before writing your first line of code, designing a beautiful user interface, deciding on a database, or anything else you may want to do, make sure you understand how you will keep your users’ information protected from unauthorized use.
This concept goes beyond the storage of PCI and PII data. Every layer of your application needs to be secure. It is incumbent on you to be aware of and familiar with the latest secure coding practices. You should understand how your data is secured, whether hosted on premises or in the cloud. Ensure that your network communications are secured with the latest encryption protocols.
Safety does not stop with your users’ data. Your source code is also data, and arguably at least as important.
Not using a robust source code control is irresponsible. I personally use git, which seems to have taken over as the world’s de facto standard. I am also aware of teams still using Team Foundation Server from Microsoft. Others use Subversion, Mercurial, CVS, and more. It does not matter which product you adopt, as long as you learn to use it effectively and consistently.
Ultimately, safety must be the most important aspect of your entire project.
I treat my users with respect, and consider their needs with every coding decision I make.
Treat your users with respect. Try not to insult their intelligence. Do not ask them to enter the same information more than once, unless there is a security reason to do so. Offer Single-sign-on where feasible. Along with safety, if you do not need a particular piece of information, simply do not request it.
Unless you have a legal reason for doing so, do not place tracking cookies on their systems, at least without offering them an easy way to opt out.
Ask users to opt-in to marketing offers.
If your website is free and/or ad-supported, go easy on your visitors. It is possible to provide ads without getting out of control. Visit any click-baity “news” site and you will quickly see what not to do. On the other hand, DuckDuckGo.com and Amazon.com both present ads, but they never feel forced.
Understand that a large plurality, if not an outright majority of your users will visit your website on a mobile device. Make sure it works well on smaller screens.
There is also a significant probability that many of your users will suffer from some sort of visual impairment. Many may not speak your native language. It is up to you to understand at least the basics of Accessibility (a11y) and Internationalization (i18n).
I keep the user experience at the forefront of my application design.
Many years ago I was working on a telephony system modernization project for the United States Senate. I had inherited the project when I joined the company. One of the application’s features was the bulk upload of phone numbers and their physical locations into its database. The user experience for changing a single field was to download a file from the app’s server, edit the record in a spreadsheet, and then upload the entire file back to the server. I am not sure who thought this was a good UX, but it worked, and most customers never complained. At least not until we installed the system at the US Senate.
The problem was one of scale. Most of our customers had a 500 - 2000 phones. The Senate had over 35,000! Let us ignore the question of why a governmental body of 100 members needs 35,000 phone numbers. The fact is that they have that many. Making a change to a single record required the steps I outline above. It was during this project that we finally got around to providing a browser-based edit page, where the user can search for and edit records one at a time if desired. There was one other problem, but I will leave that story to the next section.
As you work on your own applications, try to consider all aspects of the app’s design and functionality from your users’ perspective. Use common UI components, where possible. Unless you have a lot of good research in user experience, try not to create new UI paradigms. Adhere to the Principle of Least Surprise. Buttons should look like buttons. Components that look like links should behave like links.
I use my time, my team’s time, and the company’s resources wisely.
This is the last key, but too often developers put it first. How often have you been on a project that had incredibly complex code for the simple reason than someone thought they needed to optimize something? Try not to optimize prematurely. Before spending too much time on making your code faster, decide whether or not there is a way to improve the user experience instead.
Continuing my US Senate story, the reason we finally provided a web page to edit individual records is because uploading their 35,000 records took our system more than three hours to process! The original request I got was to dig into the code and find out why. The result of that analysis was that each record in the spreadsheet was processed individually, with a MySQL “upsert” command. As you might imagine, this took considerable amount of time.
Before attempting a fix, the customer asked whether there was an easier way to edit just a few entries. In this case, focusing on Show made more sense than focusing on Efficiency.
Eventually, we had to address the bulk upload performance. I ended up building a parallel temporary table in the database that shared the same schema as the Phone table. The entire batch of phones was uploaded to this table, and then the two were merged with a single SQL statement. Our processing time went from more than three hours to right around 60 seconds. This solution had the added benefit of being run inside a single database transaction. Under the original model, a failure in the middle left the Phones table in a usable, but inconsistent state. The only choice would be to try again.
Knowing how to prioritize the various competing concerns is an art. Writing software requires tradeoffs. You can use these Four Keys of Software Development as a set of standards to help you manage these tradeoffs.
- Safety: Do not let anything stand in the way of your writing safe, secure code.
- Courtesy: Treat your users with respect, as long as you do not compromise safety.
- Show: Provide the best user experience possible, while remaining safe and courteous.
- Efficiency: Only after you have done all you can concerning the above three keys, should you focus your time on making your code more efficient.
While I do not necessarily expect you to agree with everything I have written, my hope is that it has given you some food for thought.
Would you like to see more content like this? At the urging of some of my more vocal fans, I am considering writing a book on business communications, taken from my nearly three decades as a software developer. I have made and overcome a lot of mistakes, and am eager to share them with you. You may have seen some of this content before, specifically my blogs posts on spelling and grammar and my recently shared experience on almost committing perjury.
Here is my proposal. If I can get at least 25 people willing to preorder such a book, then I will write it. For more information, please see my Gumroad Page here.