Lessons learned about shaping company culture at RealtimeBoard
Recently RealtimeBoard hosted ProductCamp, well-known event for product managers community. I shared with product managers how we started to treat culture as a product and what we have learned during our journey so far.
As I mentioned in the previous note, in the beginning we were inspired by article about Asana and took it quite literally. We decided to approach our company culture as a product and started with a research, then moved to an MVP design, then tested and fixed some bugs and, finally, released the first version and continued to iterate again.
Here are some highlights about our learnings along the way.
You can check the slides from my ProductCamp speech or scroll down and check the detailed notes about each phase.
Start with empathy & engagement
I truly believe in bottom-up approach to values definition. For a company which is more than 3 years in operation and with more than 20 employees it’s almost irrelevant to discuss values in a smaller group of top-managers.
There are two ways to engage people in collective product creation. If you are a small group of people, less than 30, in-person interviews would do well. We were about 70 at that time and for us online survey worked better.
In both cases the most important thing is to ask right questions. Your goal at this research phase is to activate emotions and dig deeper. That’s why don’t follow easy path with giving list of pre-defined company values to score and rank. Don’t ask surface questions. Ask for stories and people’s explanations, what stays behind them.
Collect stories, not numbers.
Meaning first, frequency second.
Research will be gone, stories will stay.
We started with a simple survey asking people what kind of behaviour led us to success in the past. Here are some of the questions we used:
Later on we organized a small working group for survey answers’ analysis, but the very first step engaged every single employee.
Follow a process you can trust
I tried to combine the methodology I used before (Appreciative Inquiry) with Culture as a Product (CaaP) approach. Honestly, wouldn’t recommend to do it. Stick to one process that the group could follow confidently. Otherwise, you and your participants will lose a lot of energy and focus trying to improve the process on the go, and you will reach results slower.
One more discovery about the process was meeting unexpected enemy: affinity mapping. Why I call it enemy? Because no one expected to get any troubles with such a simple and commonly used practice! However, it might become messy, especially if you mix it with a certain set of conditions, for us they were: quite a big group (about 10–15 people), limited time and sensitive content.
We have found useful tips in a document about Affinity Diagramming and used it for our values definition workshop. It saved us time and gave clear process that everyone could follow. Feel free to use these supporting slides too:
Define working group super skills
Talking about company culture it’s very easy to fall into pure emergence and give tasks to the most active people. Of course, it’s cool to see them engaged and taking initiative, but at the same time you should be clear on what kind of skills are needed for each step of the process.
If you assign the tasks to the enthusiasts, you might miss the quality of the work to be done. It might lead to a situation of doing the same task twice or working with a poor input at the next step of the process.
For us these skills worked the best:
- Analysis and synthesis, content analysis: for going through the input collected at the Research phase.
- Text-related skills, love for language, dictionaries, meaning: for wording the values names, descriptions and behaviours examples
- Communication, listening and interviewing skills: for validating the v.0.1 of our values list, testing it and finding the first culture bugs
- Collaboration skills: for the working group to be effective at the workshops
- Facilitation skills: for me as a workshops leader and process owner to help the group progress over the course of several days
Testing & bug fixing revelations
This is probably my favourite phase in a product cycle. Approaching culture as a project would also include research and design phases, but approaching culture as a product means we never over-design in the beginning. We go with an MVP and test it on real users, ask for their feedback, find what’s not working (the bugs) and fix it.
This approach changes the way we see our role and eliminates fear of making mistakes. Taking culture as a project, I have to define values precisely and I am afraid of facing resistance while implementing them. Using product approach, I come to my colleagues and ask them: this is our values MVP, what do you like about it and what do you see we need to fix? There is no resistance to change, because employees become co-creators, not mere objects of an HR initiative.
We tested our values list through interviewing employees. The process was simple: we have chosen 6–10 people to validate each value. It’s best to look for leaders, opinion makers, diverse group of people, preferably for experienced employees who work in a company longer than others (not newbies). Here are some questions we used:
Another big revelation for me was the culture bug definition. We use term “bug” in software development so often, I even forget it’s a slangy word.
A software bug is an error, flaw, failure or fault in a computer program or system that causes it to produce an incorrect or unexpected result, or to behave in unintended ways (Wikipedia)
So what does ‘culture bug’ mean then? We defined it in two ways:
- We say we’re about X, but what we’re really doing is Y
- Described values/way of delivery lead to wrong behaviour
Both things mean there is some flaw in our culture definition or in actual behaviour, our ‘culture system’ produces incorrect or unexpected results.
We’ve got two ideas for fixing culture bugs:
- We agree the values are defined properly and question actions inconsistent with our values, and try to fix behaviour.
- We review the Culture Code and admit we were wrong while defining. There is nothing productive in living in illusions we are X while we are actually Y.
After our first debagging phase we have reduced number of RealtimeBoard values from 7 to 6. On of the values was marked by our employees as “we maybe strive to behave this way, but not always do that”. Users decided it’s not correct to confuse our dreams and ambitions with actual living values. This is how debagging works.
Usually people ask for examples of culture bugs. I will be ready to share few in the next articles.
First release & Iterations
Finally, coming to the last phase of the iteration, we brainstormed tons of ideas for our values delivery:
Most of these ideas got to our backlog and waiting for the next iterations to be realized. That first release we had at the end of our HR sprint resulted in several simple things:
- Values v.0.2 presentation. We presented 6 values: their labels and definitions, and some stories that lead to defining them.
- Telegram sticker pack. We’ve made funny internal stickers with RealtimeBoard team members faces and frequently used phrases, that demonstrate our values.
- Stories around the office. We printed out the stories people shared in the survey during research phase and put them around the office. People could read them and mark as related to one of the 6 values.
- We have invented value juicing tradition. It will stay as our internal secret, just believe me it was a very funny one :)
Why product attitude is the right attitude?
RealtimeBoard is a product company. Everyday, every team member builds realtimeboard.com — the world’s most popular whiteboard for visual collaboration. Using product analogy for shaping internal things, such as our company culture comes natural to us. It’s quite effective because we already have this common language, we use similar terms to define product life cycle and metrics to measure it’s performance.
Familiar processes give all the people in the company opportunity to participate and feel comfortable with the whole topic.
MVP concept helps us to move faster with small steps. It makes our Culture Code alive.
We understand that we live in the world where nothing to be carved in stone anymore. If we want to stay competitive with our product we need continuous improvement. The same works for our culture product: it’s never final version, because the company evolves every day and its culture does too.
And again, it’s simply easier to manage. Traditional top-down approach to such a project would generate a lot of stress during the implementation stage. Instead, we have a chance to replace change resistance with culture bugs hunting and user feedback. It gives all the employees better environment for a dialogue and open opinion sharing.
What’s next?
Our journey just begun.
More user researches to be done, more MVPs to design, more bugs to fix, more versions to release.
At the moment of writing this note we are finishing our 4th iteration of creating culture as a product. Right now we are in the process of testing and debugging Culture Code v0.1 and starting our first Culture fit recruiting guide.
Probably, this is the most important piece of learning I have: never stop. The values list is not enough to understand and shape your company culture.
Go further and create at least:
- A selection tool for assessing culture fit during candidates interviews
- A culture code presentation for new employees onboarding.
We are almost there. What about you?
I am sharing these learnings because I want to reflect on our experience and inspire other startups and young companies to think of their culture as something manageable and worth investing in.
Also, one of the best ways to learn and develop for me is to discuss learnings with others, so I am looking for productive conversations and experience sharing with others who are same passionate about Culture as a Product.
Let’s talk!
You can share your thoughts and experiences here in comments or access the full presentation in RealtimeBoard format both in English and Russian (no registration required). You can add comments and check the links to related materials right there:
