If you are interested in building team culture, you are in the right place. This guide will explain you how to do so, but also why it is important and how to do it right. Let’s start building team culture right now!

Building Team Culture The Right Way

Team Culture vs. Company Culture

Most HR professionals will obsess with company culture. That is important: company culture is “how we do things around here” for the entire company, it is the set of implicit norms that regulate behavior of people. If you have a strong company culture, people can move across teams and have a consistent experience, know how to interact with others and be productive.

Yet, company culture is not the only thing. Quite the opposite in fact. Company culture is general, and can be sometimes even vague. It can be abstract, because sometimes what HR says differs from what happens “on the field” (although some companies have a strong company culture).

Team culture is the embodiment of company’s culture within a team. It is what part of the culture permeates into day-to-day activities and applies to the “actual” work. We are focusing on that today. Building team culture means finding values and behaviors that adapt well to the circumstances and to the specific work items a team has to do.

What Kind of Culture Do You Want?

Why are you into building team culture in the first place? Isn’t company culture good enough? How much should team’s culture differ from company culture? Those are important questions to ask when building team culture, and they all stem from another question. What kind of culture do you want?

Before we can start building a culture, we should spend some conscious effort to define what culture we want. More specifically, what do we hope to achieve through this culture? Why is it important?

The culture is the environment where things happen. Different environments facilitate different things, so you need to consider what your team needs the most. In general, culture works on multiple dimensions:

• Excellence or perfection vs. speed with scrappy but fast-to-build solutions
• Inclusiveness and collaboration vs. independence and autonomy
• Structure (in communication, work, deliverable and so on) vs. organic and informal work
• Risk taking vs. risk aversion and caution

Of course, most of those are valuable items and you will want to have as much of them as possible – considering not all are strict tradeoff. For example, you can deliver great product and doing that at speed, or be strong on collaboration while also allowing for autonomy.

However, in most cases a tradeoff does exist. You cannot communicate in a structured way while also communicating informally (unless you do both, twice the work). You can’t take bold risks, while at the same time not taking them. So, building team culture is all about deciding where you want to be on the spectrum of those dimensions.

Now that you have a general idea of what are the different areas where you can start building team culture, we will give specific levers for you to play and shape the culture that you want.

Before we star, remember that the best way to define team culture as a manager is to set the example. You can’t just preach your culture: you have to live by its values. So, think about what values you can live by as well while reading the next section of this article.

Stay tuned for a bonus tip at the end as well.

Levers for Building Team Culture

Excellence and Speed

Both excellence and speed are great things to have, but they are often at the two ends of the same spectrum. To say this in plain English, you can have one or the other, or not both. More generally, the faster you are, the further you will have to sacrifice excellence, and vice versa.

If your goal is building team culture of excellence, you need to consider behaviors that foster feedback that is often hard to hear, that push the bar always higher and in general are an approach “we are never satisfied, we can always do better”. Measure in that sense can include:

• Peer-review the work, for example code reviews are a common practice in coding where a developer reviews the code written by another developer
• Put engineers and technicians first, for example by having periodic design reviews for solutions. You want people that build the solutions and products take ownership of what they are building, so that they feel the pride and can create great products.
• Always have ONE owner for each activity. If a specific person owns something, he will feel responsible for it and its outcome, and he will be much more likely to excel. Strong ownership is a great value regardless if you want excellence or speed, it is a value that get things done.
• Privilege focused work and avoid interruptions. Encourage people to block time on their calendar to work, and do not expect people to promptly reply to chat and emails.

If you want speed instead, you may want to consider different levers:

• Communicate on a need-to-know basis, don’t share huge updates with people that don’t really need to know about them. They will waste their time reading something that adds no value. Share information only with people who need to know it, but have a public repository where everyone can go and see the information if he needs to.
• Support quick communication such as chat and quick calls to remove blockers.
• Limit dependencies so that a single individual can do his work without relying on other people. This is never possible at 100%, but if you are unsure about splitting some responsibility across multiple team members, it is much better if you stick with just one.
• Design communication to remove blockers, for example daily stand-up meetings are a good way for everyone to say what he his working on and if there is something blocking it.
• Have a flat hierarchy, where people are expected to reach out horizontally to peers in other parts of the organization and where a manager handles relatively large teams (few managers, prefer self-organizing teams).

In general, excellence comes with more structure and speed comes with more informality. Keep in mind these tradeoffs, and consider if your team would benefit the most from excellence or from speed.

Collaboration vs. Autonomy

Another important element to consider when building team culture is collaboration vs. autonomy. Or, on a more general term, how much do you want people to do things together compared to how much you want them to do things independently.

Collaboration is often suited to address unstructured problems with no clear solution, while autonomy is suited for speed and problems with known remedies.

If you are into building team culture for collaboration, you will want to consider the following points.

• Encourage chat and impromptu communication
• Have regular recurring meetings for various ongoing issue, so that people can gather and speak up their point of view.
• Work on-site or have regular team offsites so that people can get together face to face and learn to trust each other
• Give feedback and ask for it, so that people get into the habit of communicating what they thing of other people’s performance and everyone has an opportunity to improve – including yourself

On the other side of the spectrum, we have autonomy. If that is what you are targeting, you should consider:

• Privilege pull communication: who has an information uploads it somewhere (a wiki page, a document share etc.) and everyone can then go there and see at a time that suits them.
• Have people block focused time on their calendar (as we suggested for excellence) so that they have time to work when nobody will bother them.
• Redirect people to Google for “easy” questions that Google knows the answer to (e.g. are domain specific, but not specific to your company or team)

Structure vs. Informal Work

Let’s move to the next dimension to evaluate when building team culture: structure vs. informality. We know that structure is about bureaucracy, documentation, and well laid-out processes. Informality is about gathering organically to solve problems, without a pre-defined approach.

If you are building team culture for structure, consider:

• Have a document repository where you store all the documentation
• Everything that people do over and over should be a documented process with a runbook, that is, a written document explaining how to do it step-by-step
• Store meeting notes in writing after every meeting in your document repository
• Have a specific person run each meeting, and make her in charge of deciding who speaks and then collecting and storing meeting notes (that can be considered the “president” of the meeting)

All that can be good in industries where you have strong regulations in place, such as finance or healthcare. Of course, informality is at the opposite end of the spectrum, and may be suited to other sectors such as software development or marketing. If you are building team culture for informality, here are a few things to think about:

• When something is unclear, prefer meeting and talking about it in general as opposed to writing lengthy documentation that may become outdated quickly.
• Use fast collaboration methods, such as chat channels or groups
• Continuously remind people to ask for help when they don’t know something. This is good when most of the team’s knowledge is in people’s heads and not in written and stored documentation

Risk Taking vs. Aversion

Just like any other tradeoff, your attitude toward risk is worth considering when building team culture. As you can imagine, making bold bets (high risk taking) can be appropriate in a dynamic industry where things change quickly, such as software engineering. Instead, other industries such as healthcare are generally more cautious. This does not apply to industry-level only, but also to team levels: the legal department of a software company is probably more risk averse than their marketing department.

If you want to foster risk taking, you need to enforce the idea that failure is okay, as long as you learn from it. You can do that with the following levers:

• Discuss wins and losses in every meeting: what went well, what went bad, and why
• Push decisions down the chain of command. Decisions should be made as low as possible in the organizational chart
• No approval should be needed for decisions that are reversible

On the other hand, if you are trying to foster caution, you will use different levers:

• Have a well-defined approval process in place for decisions, that involves multiple individuals and that escalate at higher levels in the organization
• Keep a risk journal where you document all risks as they arise (and change over time)
• Define (conservative) risk threshold in advance, and do not undertake any activity that breaches those thresholds

Summary (Plus a Bonus!)

So far, we saw how to build team culture considering various dimensions. For each dimension, we explained why it may be desirable to be at one end of the spectrum or the other, and then based on this we discussed some things you can do as a manager to move your team closer to your desired position on that spectrum.

Now, it is time for a bonus that will help you in building team culture. Write it down! Instead of having a vague idea of your team culture, write it down for everyone to see. More specifically, don’t write a blab of text. Use tenets or principles that you expect to use as a team. A principle should be a general rule that you apply in your decision-making, expressed in the form of a tradeoff. For example “We prefer doing things internally rather than outsourcing”, or “we prefer speed over feature-richness”. Don’t fall in the trap of having empty principles. For example, the principle “we prefer high quality results” has no sense (who would prefer poor quality results?).

Another important piece of the puzzle to consider is how to maintain your team culture when you have a new hire. Luckily, we have a guide just for that on team onboarding.