Contact

The Culture Test: Eight steps to better company culture

Written on June 04, 2015

Have you ever heard of the Joel Test? It’s a simplified twelve-question measure to determine the quality of a software team or company. It was created by Joel Spolsky over a decade ago and steadily gained popularity as an easily accessible quality metric.

Many software companies and startups use the Joel Test to quickly assess what they need to work on. Some developers even ask these questions during job interviews, trying to get a glimpse of whether or not a particular company would be a good one to work for.

The Culture Test is similar in the sense that it lets you achieve a comparable score. Instead of software development it focuses on your company’s culture, determines its current state, and identifies areas for improvement.

Engineering these days is as much about the people, and how we interact with each other as a team, as it is about technology and the code we write. Some say, technology is the easy part.

The Culture Test

The test and its questions are based on and meant as a follow-up to the Open Culture Manifesto I published a couple months ago. “Are you” refers to you as a team or as a company. For every question you answer with “yes” you get a point. The more points, the better your company’s culture. A score of 8 is perfect. Simple enough, right?

Not so fast. You might get different scores based on who on your team takes the test. Different scores will hopefully lead to conversations, reflection and discoveries of cultural successes and shortcomings. It’s not about a perfect score - it’s about identifying opportunities to improve and making your company a better place to work, where the brightest people thrive and want to stay.

Innovation doesn’t just magically happen. In fact, you have to promote it. Create a culture that works as a hotbed for brilliant minds - where ideas find fertile soil and can grow until they’re ready to be harvested.

To create this type of company culture, you first need the right people on your team. Are the people you work with curious, creative and passionate about what they do? Is there a constant desire to learn and an excitement to do so among them? If so, excellent. If not, try to reanimate your existing team and find that lost spark. Begin to hire the right people. Look for team members who understand your vision and align with your culture.

The second part is to have a strong emphasis on learning and teaching. Is your business setup to support people willing to learn and to try new things? Don’t dismiss ideas because they are perceived to fail. Rather accept failing as a way of learning. Invest in your team’s professional development. Send them to conferences, workshops and meetups. Benefit from the new ideas, interests and enthusiasm they bring back. Go ahead and organize your own hackathons and workshops and open them to the public. Reduce your company’s bus factor by establishing knowledge transfer mechanisms through pair-programming, code reviews, open documentation and a flat organization without secretiveness. It won’t happen overnight, but all these things will help your company turn into a more innovative environment.

Try to put yourself outside of your comfort zone now and then, too. Switch roles with other managers and work in a different department for a while. This will change your perspective and help you to better understand the work of your colleagues. It might even lead to interesting discoveries of how processes could be optimized. If the CEO and President of GitHub can swap roles, so can you.

There are too many agile methodologies out there to find common ground. To make things worse, most of them are highly dogmatic and claim to be the holy grail. In my experience, it doesn’t really matter if you’re using Scrum, Lean, Kanban or whatnot by the book. The right methodology is always the one that makes your team most productive. Different agile principles should be understood as powerful tools to help your team perform at its highest level. If it works, great. If not, do something else. Be agile being agile.

There are two core principles that stuck with me as fundamental concepts of agile product and software development.

First, everything you do is a work in progress. Once you’ve internalized this, you’ve mastered one of the biggest hurdles of agility: embrace imperfection. It’s fine as long as you constantly improve your product.

Second, your team should collectively measure what they’ve built and learn from these results. You can’t improve your product if all you have is a gut-feeling of where you should be heading. Backup your assumptions with data, learn from the results, and improve it iteration by iteration until it’s just right.

One more thing. Stop using “agile“ as a buzzword. If your business is working on a waterfall roadmap in iterations and shipping twice a year, you are not agile.

Microsoft finally realized the potential of open source and went full in, by changing the very foundations of its corporate culture. Yes, Micro$oft. Open source brings so many advantages to the table that even Microsoft - under new management - couldn’t ignore it any longer. Things are changing.

Many others have already written extensively - and much more eloquently than I ever could - on this topic and the benefits of open source. Suffice it to say that if your company embraces openness, you’ll eventually gain much more than you have to lose - or at least thought you could lose. Do your research on how to best accomplish the shift within your business - others have done it successfully before. It doesn’t have to be all at once. For instance, you could start by opening some parts of your company to the public and accepting community contributions. Do it.

I mean “open” as in open source, but note that I’m intentionally avoiding the word “software” here because open source encompasses so much more. Also, open source is reciprocal, and you should consider giving back to the community, too. Contribute bugfixes using pull request, donate to projects and organizations and help others in forums and user groups. Karma, you know?

The ultimate goal is to get to a state where your company prefers open source over proprietary. For everything.

If somebody accidently sent around an email with a list of everyone’s salaries in your company, would there be people who should be upset? Or more likely, would it cause an all-out shit storm?

If you think the latter would be the case, you’re sadly not alone. All too often personal negotiation skills, favoritism and gender are contributing factors for how much an employee earns. It should be clear to everyone what everybody earns - at least roughly - and what it takes to get to that level of income. Have full transparency between your employees on the highest level. Establish trust through transparency.

If you want to get some inspiration on how to be transparent about salaries, I encourage you to read more about Stack Exchange’s compensation plan as well as Buffer’s open salary concept. They’re both awesome.

It’s also essential to establish transparent communication outside of your company’s bounds. Share your decisions, failures and successes frequently on blogs and social media. People trust companies who are transparent. This could not only help you increase sales, but it’s also important if you’re hiring. People are drawn to transparent organizations, and sharing an honest insight will attract the right talent to your culture.

More of the same type of thinking dulls a competitive edge and slows momentum. Companies tend to hire more of the same, and while a comfortable habit to fall into, it has proven to slow progress. Put together people with different views, experiences, personalities and cultures. “Diversity“ isn’t synonymous with women. Ashe Dryden gives us some context on diversity with this comprehensive list of different groups.

Build a diverse and inclusive team. It gives you access and exposure to different talent pools and input from varying perspectives, which lead to exciting ideas and optimized decision-making. Practice inclusiveness by respecting everyone’s feedback, giving each person the same opportunity to contribute and weighting equally each person’s ideas. This puts your team at ease and and allows them to focus on expressing their talents, and in turn, improving your product. When diversity and inclusiveness are part of your team’s dynamic, biases are broken and tolerance is promoted.

Have a “no jerks!“ policy in place and enforce it. Always be intolerant of intolerance. This can be particularly important with external people your team has to work with like clients, vendors and partners. Don’t allow bullying behavior in your workplace. It worsens morale and productivity.

You don’t have to be a non-profit or a “B corporation” to create positive social change. Without being too preachy, try to do some good and find opportunities to serve society over self. Maximizing profit at all costs isn’t always the most fulfilling (I’m looking at you Uber). Will your success story leave a trail of people saying genuinely good things about your company? What kind of dent do you want to leave in the universe?

Sure, your company uses social media to communicate with customers, but that’s not what I mean here. I’m talking about being social in all aspects of your communication, every time.

It’s important to realize that listening to others is the first step to being heard properly. Obviously, listen to your customers and what they have to say about your product. Listen to your team, co-workers and employees. If you have introverts or shy people on your team, create a safe environment for them to speak up. Listen to that college drop-out you’re interviewing today and find out why she spent two years backpacking through Southeast Asia and learn her secret for making a proper bowl of Pho. Listen to everybody, always. Be appropriately humble and show your appreciation by taking the time to listen. Everybody has something interesting to say and the true art is to listen carefully enough to take something useful away from every conversation. Oh, and if it’s critique, listen extra carefully.

The other important part is to always over-communicate, on all channels. Nearly every problem can be traced back to a simple lack of communication at a certain time. That’s why it is so important to over-communicate. As engineers we’re striving for clean code and to not repeat ourselves, which is the exact opposite impulse of human interaction. Repeat yourself, verbally and when writing. Start to archive your communication in a way that is easily accessible and searchable by other members on your team. Instead of sending private messages or emails, start using Slack. Share your documents in the cloud rather than storing them on your hard drive. Start writing a blog, keeping track of things you’ve learned and discovered or when you failed. Don’t be shy asking or answering questions online and contribute to the amazing thing we call Internet. If you’re done, repeat yourself.

Periodically take some time to gauge your team’s happiness. A good way to do that is by having retrospectives and one-on-one meetings. Find out what your team needs to get their work done and to improve working conditions. Make sure everybody is getting the recognition that they deserve. Try to distribute tasks nobody wants evenly throughout your team - the same goes for the really cool and exciting work. The happier the members of your team are, the more productive and less likely to leave they will be.

Give your team the flexibility to work when and where they are the happiest. They’ll spend less time worrying about their work-life balance, and can better focus on how to drive results. Promote job flexibility and encourage remote work by providing infrastructure and hardware. This will also force you to judge your team’s performance strictly by results and not merely by attendance.

Last but not least, make time for reflection and self-improvement. We spend so much time at work and deserve to be happy in what we’re doing. Work smarter, not harder and be happy. Very happy.


The Culture Test was developed particularly for software engineering teams, but I strongly believe that every team can take something useful away from it. I encourage any and all discussion that arises from this test and look forward to learning how it helped your team or company.

Martin Buberl

Developer of all things web living in the city that never sleeps.
If you'd like to get in touch, feel free to shout @martinbuberl.