In this blog post, I wanted to give a high-level view of what culture is and what it is not. I will leave most of the tactical parts of how to define, shape, and build the culture you want to future blog posts. The most important thing to know is that you can have all of the information you want but it ultimately comes down to execution. As leaders, we have to do the work.

I want to spend just a moment talking about what culture is not. Culture is not free lunches or ping pong tables or any other benefit you are selling to engineers you are recruiting. Culture is not a poster on a wall or a mission statement. You get the idea.

Definition of Culture

The simplest way to define culture is simply, “What everybody is doing every day.” The choices everybody makes on the team every day makes up the culture of that team. When people start making similar choices consistently this is a stronger part of a team’s culture. The simplest example of this is if a bunch of people on the team shows up late to meetings because they don’t think it is important to be on time, then that is part of your culture. The opposite is true as well, when everyone shows up to meetings on time because they think it is important, then that is part of your culture.

An example that is related to software engineering more directly may be how easy engineers make it to review their code. It is easy to put up a code review, but are individuals make the review easy on the reviewer? Are they adding clear instructions on how to test the code? Is it a small enough review? Are any product specifications linked to help the reviewer understand how this is supposed to work? All of this takes extra work but helps ensure good reviews. This is something most leaders want their engineers to do, but they will only do if it is part of the culture.

Why is Culture so Important?

Culture is how leaders drive the outcomes from the teams they lead. It is as simple as this. Many don’t like this idea and like to think of culture as something that is for the benefit of the team, but these goals are not mutually exclusive. They can’t be.

A sports coach wants to win games so builds a culture designed to do just that. This is aligned with what the players want as well. A software engineering team should have certain outcomes they are trying to get from their culture that benefits the business but is aligned with what the engineers want. Some examples are, writing quality code, writing maintainable code, making good technological decisions, lowering the risk for the business when it comes to things like site outages, and engineers becoming more valuable to the business by building skillsets.

These outcomes are not something you can just request or demand but are symptoms of a healthy, well-planned culture. A leader must decide what outcomes they want and build the culture to drive those outcomes.

How Does a Leader Get the Desired Culture

The first thing to understand is that people are not like code and when changing and shaping a culture you are trying to change how people operate. As engineers we can make changes to code and immediately see change, this is not the way it works with people and especially with Software Engineers. An Engineering leader must have a plan with a clear idea of where they want to go. This engineering leader then must be relentless in getting there. There will be some people that want to follow and others that fight changes. It will be a long, constant grind that never ends. This is one of the most important parts of being a leader. If you don’t build the culture to get the outcomes you want, then you will never get the outcomes you desire.

The goal, in the beginning, should be that everyone knows and can explain what the culture is from the tip of their tongue. If an outsider walks in and asks everyone on the team individually what the culture is everyone should give an identical answer. Without this, leaders and individuals on the team can not promote the culture. Making sure that everyone knows where the culture is going and having clear language around that is important.

To accomplish this first goal, Leaders must constantly talk about culture. They must bring it up in every meeting. Every group meeting, every 1 on 1, every meeting between other leaders. I like to use what I call the Nacho Metaphor.

When I make nachos, I start with the chips. I then add some cheese until I think there is enough cheese. Then I add more cheese, cause you always need to overdo it.

Cheese in this metaphor symbolizes the amount you talk about culture. When you think you have talked about it enough, do it some more. The people on your team need to hear it all the time.

Mistakes will be made

Many issues will come up that engineers will look to leadership to solve or look to leadership for help in solving. Because we are all engineers we often like to think of ways we can automate our way out of a problem. Process and automation have their place but often I see leaders trying to use process or automation where they should be implementing a cultural change. The process and automation traps are easy as it takes much less work on the part of the leader and engineers usually like these solutions better as well.

In reality, most problems are a combination of both. When a process change exists the cultural changes need to accompany that change. If leaders of a tech organization make process changes without making cultural changes to accompany them, they will not see the changes they are hoping for. Mixing these can often be the most powerful.

The biggest mistake by far is that leaders try to influence culture but don’t put in the work. If a leader wants something to be part of the culture it won’t be until that leader does the work. Training, expectation setting, and buy-in, along with the Nacho Cheese mentioned above is the work that needs to be done here. The individuals on the team need to believe it or it is not part of the culture. Ultimately, the real test is when individuals are holding each other accountable to the cultural expectations that the leaders were setting.