Little Earthquakes (part I)

Those of us who use Google (which may be everyone) and those of us who pay close attention to Google's web site (which may be a smaller number) know that from time to time Google adjusts their logo. The "Google" that appears on the web page is often decorated in the style of the day: green on St. Patrick's Day, fireworks on July 4th, and so on.

While these changes appear whimsical and without purpose, that may not be the case. Changing the design of the Google logo can serve a purpose beyond the amusement of their users.

Changing the logo (really, changing the image file that holds the logo) requires a process to update their web site. At the very least, they must replace one image file with a second image file. (There are other ways of updating the web site, such as changing the HTML on the home page to refer to a different image file. The result, a process to update files on their web server, is the same.)

Most organizations isolate their production web servers (the ones that customers actually see, not their internal test servers) and carefully guard against changes. They limit access to one or a few teams. They put procedures in place to review all changes and test them prior to "moving them to production". They create an environment which discourages changes to web servers, probably out of fear that a change may cause a failure.

The result is that their web sites change infrequently, and when they do, the changes are usually a bunch of changes that have been tested in advance and patiently waiting for "update day".

This kind of thinking was (and is) used with other computer systems: PCs, minicomputers, and big mainframes. It is not tied to a technology but derived from managers' confidence (or lack thereof) in their people.

Indeed, this kind of thinking extends beyond the IT industry. Magazines will revise their layout, changing the "look" of the publication. They spiff up (or slim down) the table of contents, add (or remove) graphic elements, and change the typeface used for articles. They make these changes all at once, usually with some fanfare about their new look. Even the magazine Fast Company which espouses 'fast' principles and decries the 'old' way of doing business uses this "all redesign at once" philosophy.

Google takes a different approach. Rather than hold all changes for one big update, Google makes small changes over a period of time. It updates a single application one week, and then updates another a following week. Google changes their web site slowly, in small increments. A magazine could do the same thing, by changing the typeface in one issue, adding graphic elements in a subsequent issue, and revising the table of contents in a third issue.

Google's approach is the "little earthquakes" method. Rather than one big earthquake of short duration but large magnitude, Google accepts smaller shifts over a period of time. I think that this works well for them, and for users. (I am a user of their applications.) Google benefits by getting feedback on changes earlier and with fewer risks per update. I benefit by having to learn fewer changes at any one time.

To make this happen, Google needs a reliable process for updates. It must have a process that it can count on. And the best way to create a process that one can count on is to run the process frequently.

So Google's "whimsical" changes to its logo (which requires an update process) on a frequent basis is a way for Google to test its process and see that updates are easy to deploy. And maybe that is not such a whimsical idea.