Photo credit: https://flic.kr/p/pNB7hX
In a previous post, I shared my approach to visualizing and understanding the culture of an organization. Assuming you agree with my approach to understanding culture, you might find yourself asking the question, "Great! How do I get started?" In my experience, I tend to look for an organization’s cultural artifacts as a starting point for understanding their culture. So what are cultural artifacts and why are they useful?
A cultural artifact is something that a team creates, shares and/or somehow emits outside their team that can be observed. You can use these artifacts to gain insight into the culture of a team or organization. Cultural artifacts can provide you with insight into the potential culture of a team. Similar to archaeological artifacts one might find in an ancient Egyptian pyramid, cultural artifacts provide you with clues to what a team might expect from you. Identifying cultural artifacts can be a quick way to understanding how a team works and what they believe.
So what does a cultural artifact look like and where do I go to find them? I suspect that there are dozens of cultural artifacts that be used to discover the culture of a team. For me, there are a few that I tend to lean on in particular. The cultural artifacts of a team I seek out are managers, behaviors, tools, and domain.
The first cultural artifact I look for is the manager of the team. The manager of a team or organization is responsible for setting priorities and holding team members accountable for achieving these priorities. Managers are particularly special to the culture of a team because they influence the shape and direction of a team. The personal values and behaviors of a team manager will manifest lead to biases in how the team is molded, hence shaping the culture.
The following are the primary means by which a manager shapes a team:
Managers are responsible for hiring. Managers are responsible for deciding who will be a member of their team. If the hiring manager is self-aware, they will recognize their own biases, and hire team members to compensate. If a manager is not self-aware, the team they create will end up looking and behaving like them. The beliefs and biases of a team’s manager guide who they hire.
Managers are responsible for firing. I come back to one of my favorite quotes from Andy Dunn, the founder of Bonobos, “The most important people to your culture are those who leave…the people you fire are more important than the people you hire.” When a manager lets somebody on the team go, the remaining members of the team will look for lessons on how they personally can avoid a similar failure mode. This will strongly shape how the remaining team members behave. It is important for a manager to fire team members who are toxic to the health and performance of the team. Firing is one of the hardest parts of a manager. If a manager tolerates a brilliant jerk for too long, this sends a signal to the rest of the team that being “brilliant” is more important than being a collaborative or respectful. Whether the manager knows it or not, they are shaping a culture that embraces brilliant jerks. Inaction can be just as important as action, especially when it comes to terminations.
Managers are responsible for rewards. Behaviors that are rewarded can be one of the potent and dangerous indicators of a team’s culture. When a manager promotes a member of the team, this sends a signal to the rest of the team regarding how to get promoted. Meaning, the rest of the team will look at the newly promoted individual’s behavior as promotion worthy. Not just their good behavior, but ALL their behavior. This is very important. If a manager promotes somebody who never delivers on time, but is great at code reviews, then the rest of the team now knows what the manager values. Many of us have worked in an organization where those who were promoted were also the ones that backstabbed other leaders and worked in their own interest. This organization never stated that internal competition was a core value, but those who were successful knew it to be true. An organization that promotes leaders who backstab each other is creating a culture that says “we value backstabbing”.
Managers are responsible for modeling behavior. When one joins a new team, they will often look first to their new manager to understand which behaviors are accepted, expected and rewarded. If the manager tells everyone on the team that giving candid feedback is important, but they themselves are unable to provide feedback, then their words are merely wind and the culture of the team shifts slowly away from being candid. Actions speak louder than words. It is also likely that a manager’s behavior indicates how they hire, fire and reward members of their team. So, in observing a manager’s behavior, there is a chance that members of the team may model similar behavior.
When looking at the manager of a team as a cultural artifact, one last thing to consider is how long they’ve been the manager. Tenure plays a huge role in the potency of a manager as a cultural artifact. The longer a manager is leading a team and the more they hire and fire, the stronger their influence on a team. If a manager is new to a team, then you can use the manager as a predictor of the team’s future culture.
While the manager shapes the composition and direction of the team, a team is still composed of individuals. These individuals will each exhibit their own behavior, based on their personal values. Whether you are working with another team or joining a team, the majority of your interactions will be with its team members, so their behavior makes an excellent cultural artifact. Managers are cultural artifacts that help you understand how the team’s culture came to be, and where it’s going. But the behavior of the team is an artifact of the team’s current culture.
Within an organization, there are plenty of opportunities to observe the behavior of another team. In a meeting. At lunch. In the hallway. At a happy hour. In a Slack channel. Each time you observe the behavior of an individual, you are collecting information about their team’s culture. Through these observations, you will begin to understand what they believe and value.
There are behaviors that are directly applicable to the work one does in software engineering, such as unit testing or bi-weekly sprints. Observing this behavior in another team is definitely a cultural artifact, especially if their behavior deviates from any organizational norm. When working with a team that has strong engineering practices, you can assume that they will expect you and your team to share in their beliefs. They will likely assume that you should be building software the same way that they do. And if you don’t subscribe to their approaches, you can expect some level of friction and disappointment.
Beyond engineering practices, it is also important to assess how the team communications, gives feedback and shares ideas. Do individuals treat members of other team’s with respect? Do they share feedback readily or do they gossip and undermine each other? Do they communicate their plans and designs with the rest of the organization? Do they work towards establishing collaborative relationships or competitive ones? These are some of the most interesting questions you should be trying to ask of a team.
This is often the easiest artifact to identify and also one of the weaker indicators of a team’s culture. The tools a team uses can indicate the potential beliefs of a team, especially if their tool choices are unique. I am using the term tools to cover a wide range of things. Programming languages, version control systems, chat clients, runtime frameworks, and even a sticky notes are all examples of tools. A team will select a tool because they believe it solves are a particular problem or need for them. While tools are designed to solve problems, they all carry with them constraints or limitations that must also be accepted. By adopting a tool, a team is shaping their culture.
If a team adopts an open source tool, then there is a chance that a community exists around the use of this tool. This community formed around a shared set of beliefs that binds them and shapes the direction of the tool. When a team adopts an open source tool, they are also adopting the beliefs of the open source community surrounding that tool. For instance, the Ruby programming language has a global and passionate community that believes strongly in 'developer happiness'. So by choosing Ruby for a project, the team is either already aligned with the 'developer happiness' belief or will eventually align with it. Why? Well, they will likely hire engineers with Ruby experience who believe in 'developer happiness', thus further "infecting" the team with this belief.
So, by looking at the tools a team or organizations uses, you can make some guesses as to what their culture may be. I feel this point is often overlooked and I have observed it to be a constant source of unspoken tension between teams.
When an organization forms a team, it does so in order to address a particular need within the organization. "We have a lot of data, so let’s build a data engineering team." "Our deployments are slow, so let’s build a release engineering team." "Our engineers waste a lot of time, so let’s build a developer productivity team." Teams are born from a need. When the need is gone, there is a chance that the team will go as well. The need, or problem domain, that the team exists to address, can be a valuable cultural artifact.
I have spent the last few years leading engineering teams focused on providing development infrastructure and tooling to the larger organization. These teams were formed to address the organization-wide need for centralized development support. Each of these teams needed to provide domain expertise, tooling, and support to the rest of the company. I was hired to lead these teams due to my passion and expertise in this space. I, in turn, hired engineers who were also passionate about providing this domain. The history, legacy, and composition of the team is embroiled within the domain of the team. The tools we choose and recommend are based on the organizational need. This is a cultural artifact.
I once made the mistake in assuming that two engineering teams that we were supporting shared the same beliefs. Both were product teams, focused on the UI, and both built their product in JavaScript. I was surprised to find these two teams were asking for conflicting features in the tool we were building for them. Upon digging in, we realized that these two UI teams were formed to solved very different business needs. The first team was formed to build a robust, reliant and performant experience within a small yet important portion of the product’s UI. As a result, they believed in building solutions themselves from scratch, as third-party products often fell short of their performance and telemetry needs. The second team was formed to build a user experience that changed based on hundreds of A/B tests, most of which would fail and be thrown out. As a result, this team valued developer velocity and cared more about high level abstractions and less about lower level details. Once I understood how the domain influenced the culture of these two teams, it became clear how we might build solutions that met both of their needs.
Cultural artifacts are extremely valuable to beginning the process of identifying and understanding the culture of a team. I use them all the time. But they have their limits. Cultural artifacts are an indicator of a team’s potential culture. They are clues. And these clues need to be validated. It is possible that an artifact may lead you to an incorrect conclusion. It’s always important to validate your initial read, and to give a team the benefit of the doubt.
My hope is that you be able to use cultural artifacts to improve your understanding of the teams you work with everyday. Identifying cultural artifacts may be uncomfortable at first, so I recommend looking at the artifacts of the team you are on as a starting point. What are the artifacts that you and your team emit? What are the tools you use telling others about your team’s culture? How does your manager influence the culture of the team? How do other team’s view your team based on your behavior? These are all important questions to ask, as it is likely that others are using these artifacts to assess you and your team.
Share this: