Guest post by former Warner Bros. Records digital exec Ethan Kaplan of Live Nation Labs. He blogs at Black Rim Glasses.
A year ago I walked out of the Warner Bros. Records building, put a box in my car and drove home. I left with a collection of memories, but also a sense of unfinished business that I intended to keep in mind when I started my next venture.
When it started becoming apparent what my next venture would be, I sat down and started writing.
I proposed this question to myself:
Given a green pasture, how would I architect a company or department?
All of this thinking ended up in one place: Culture.
What is culture anyhow?
A lot of companies throw around the word culture. Zappos has its 10 core values. At one point, Google's 20% time and "Don't Be Evil" defined it. Apple has a well-known culture of secrecy. Github uses its culture as a way to shape their product messaging, its community and best practices for its use.
Over the summer I spent a lot of time looking at how culture was defined by various companies. My brother-in-law works for Zappos, so I got some good exposure to that. I have friends at a lot of other startups and big companies, so I collected info from them as well.
Culture is a Product
One of the key things I learned after leaving WMG and examining my tenure there was that we focused more on projects than products. Products help you frame a holistic view of what you are building, from plans to deployment. Projects are only judged by the duration of time you spend on them, and forgotten quickly.
To that end, at Live Nation Labs, I wanted to be a product-oriented company, treating the products we build as their own independent companies, and staffing them as such. Included in this was the application of "The Lean Startup" build->measure->learn->(repeat) methodology.
When I started writing our department documentation, it occurred to me that if the culture of the department was treated as one of our products, it put "how the department works" on the same level as "what the department works on."
I've seen culture referred to as the immune system for your company. I believe that strongly, but I also think it is the most important product you create.
The Product
Here are my rules for the "Culture Product":
The Culture Product has all the same needs as a Web or Mobile product.
When you make a web application and adhere to lean-startup/agile methodologies, you start with a loose set of requirements, usually framed as user stories. From there you move toward prioritizing stories, developing them and shipping.
Stories
The Culture Product has the same needs. For Live Nation Labs, I even went as far as to start using Sprint.ly to shape them.
As a <noun> I need to <verb> so I can <noun>.
So for instance: As a developer, I need to have a continuous integration system so I always know if my code is valid in my branch.
Or more colloquial: As a team member, I need free soda in the refrigerator so I don't have to go to the liquor store on Hollywood Blvd. when I need caffeine.
Build
From here, you can "build" these features into the product. For us, the soda concern was solved by a Vons.com delivery every few weeks, and the continuous integration system was a combination of Jenkins, Janky, Hubot and Github.
These stories should be iterative. If you frame cultural issues as stories, it helps shape them as actionable concerns rather than complaints or "issues." And making them stories makes them not merely a problem for one team member, but things everyone can solve.
Ship
Shipping a Culture Product feature is not like pushing to Heroku, but still involves implementation of a process along with documentation. Usually, when we "ship" a Culture Product feature, it is through Evernote, and then into our internal Playbook.
The Playbook is a wiki/blog that is used by our team to document cultural practices and recipes for how to perform certain things (such as how to use our chat room or the Sonos system).
Learn
Once a feature is shipped into the culture, you can and should proceed with validating the story through "learnings." Sometimes this is quantitative learning through metrics, and sometimes it's a qualitative "feeling" if things are working out well.
Iterate
Nothing is set in stone. Our Culture Product is an iterative thing, as is the Playbook that documents it. We talk regularly to define and refine our culture.
The process of editing and changing the Culture Product also has the added benefit of exposing all parts of our organization to all aspects of its infrastructure.
The Playbook is in Github and the product management system is the same we use for our normal web and mobile products. The Culture Product's implementation serves a dual purpose for us: defining our organization and educating in a cross-domain fashion while doing so.
Culture must be fed
When you define culture as a product, it becomes easier to define its boundaries, and then constrain and nurture it to maintain them. This means, like any product, your Culture Product should operate within the constraints and allowances of a defined budget.
Too often, the things that constitute "culture" are seen as additive or "perks." I hate defining things as "perks" because it relegates them to things that should be seen as optional if and when times get tough. Similarly, in recruitment, "perks" mean "these are not core, but are additive in order to be attractive." I've found perks are always the first things to go as cultural efforts in a company's decline. And more damaging still, perks aren't an element of culture. They are frosting on a thin cake.
Zappos has a lot of perks, but if you strip them out the culture still stands. I suspect that if Facebook cut the perks in Menlo Park, the offices wouldn't be vacated any faster in the late evening—but the pizza delivery drivers in the Valley would have a new frequent destination.
If your culture is a product, it needs to be fed with money, time and enthusiasm. It can't be an afterthought or the recipient of "maybe if" budgeting. Like any product, innovating only through a balance sheet, meeting schedule and checkbook can kill it.
The Culture Product should be seen as a qualitative risk: a product whose very existence validates all others.
Culture Should Be Exportable
One of our mandates at Live Nation Labs is to export our culture to the larger company. By treating our culture as a product, one of the things we do ends up being "packaging" it for exporting. This includes all things from our social media presence, external blog, and internal documentation, and all the way down to the tools and software that enable us to work day to day.
Culture is an ephemeral thing, but part of treating it as a product is to force ourselves to make it reified, that is to say: concrete in some fashion. Forcing reification enforces a discipline of colliding reality with fantasy, and helps temper some less essential cultural aspects (i.e. foosball tables) in favor of more prosaic and pragmatic initiatives.
Culture is your Platform
Ultimately, the Culture Product is the platform on which you build all your company's other products. Much in the same way the Facebook Platform or Amazon Web Services form the foundation of those respective companies product roadmaps, so too should your Culture Product form the foundation on which you build everything.
Culture is not just the immune system for your company—it is the basis of how you build, function and evolve as a producer of products. It should be omnipresent on your roadmap, given attention and never thought of as an option or afterthought when resources get constrained.
The Culture Product is simply the most important product you'll ever manage.
