Recently, I read the excellent book “Delivering Happiness” by Tony Hsieh, founder and CEO of Zappos. For my entrepreneur friends starting up and those already in “the struggle” – and for those who are running large groups within a company, it’s a very good book about developing culture and values of an organization.
For those of you who don’t know the happy ending of this book, Zappos was sold to Amazon for a whopping $1.2 billion (with a b).
There are a number of great lessons in this book, but one of them stood out to me that applies to our business at Brainjocks. Now looking back at my own career and time in engineering, I see how this lesson applies to developers, designers, analysts and others in the software development industry.
Delivering Happiness
In the book, Mr. Hsieh tells the story of customer service. More specifically, how Zappos focused it’s energy and passion into customer phone interactions in order to be known for amazing customer service and customer care. By doing so, the company earned free marketing and attention from the media, and the market noticed. And, naturally customers loved it, the market grew. Finally, unbeatable customer service became an integral part of the Zappos corporate identity and culture.
You might be asking your self, what the heck does this have to do with CMS project? Well, let me tell you.
In order to make sure customer service was the focal point of the organization – Mr. Hsieh created a company policy that anyone entering the organization at any level would begin their tenure by spending their first few weeks on the customer service phone lines. Yes – that’s right – if you took the job at Zappos as the CFO, your first assignment is to answer customer support phone calls.
The Why of CMS
In the world of CMS, never forget to ask yourself – “why did this organization purchase a CMS?” The answer is obvious, but many times forgotten. Organizations purchase CMS platforms because they wish to manage digital properties with teams that aren’t engineers. So, one of the best measures of success of a CMS project is – can the content teams use it to actually manage content with dependencies on engineering teams?
Making a CMS solution operationally sound is a combination of several things – making the system flexible enough to adapt to emerging content requirements and building enablement programs and adoption plans to ensure the teams are prepared and capable. These are both important – but there is one more key thing you must ensure – it has to make sense and be adoptable by non-technical teams.
When CMS goes wrong
The things that can derail this are many. Developers like schemes – and sometimes they end up building a Rube Goldberg machine to manage your main menu, which you don’t want as a CMS user. In other cases, design interactions on the front-end of your system are complicated, and it isn’t obvious how to decompose that design into something digestible for a content management team.
Welcome to the Content Team
In order to develop empathy for our content managers, we took a page from Tony’s book and applied it to our own teams and how they work. By allocating time from designers and developers to integrate into the content management team and build content pages during a project, they develop empathy for the role of the content manager and apply more care to their work to ensure operational success.
It might seem extreme, but it works. In our own practice, designers immediately understand the relation between design variances and content complexities, and developers can clearly connect any crazy schemes they have created to friction and difficulty for the content teams. Making all of them remember the reason we’re here is a good thing.
