Posted 10/29/2019
"Culture" is a buzzword. It is talked about often as the key to a successful organization, but is rarely well-defined. So let's start by defining what we mean by culture here. A team's culture is the set of values and processes that enable employees to make decisions autonomously and consistently.
Culture is particularly important as a company scales. It is not practical to provide step-by-step guidance to every employee on every task. But without generally understood values and processes, employees cannot know what is expected of them. By providing the values and processes that drive decision-making, a well-defined culture can remove the need for micro-managing without sacrificing quality or consistency.
High-performance cultures can vary widely. There is no single set of optimal values and processes. However, there are some values I believe every high-performing team can and should share. In this article I'll discuss three (learning, teamwork, and ownership), with a focus on engineering teams.
Technology moves fast, and the pace of technological change is accelerating. Expecting engineers to keep up with advances in the languages and platforms they work with entirely outside of working hours is unreasonable and counterproductive for the organization. Engineers who try will have a poor work / life balance and will likely experience burnout. If an organization hopes to innovate, engineers should also be learning skills and accumulating knowledge that goes beyond what is required to complete their current tasks.
Engineers also don't work in a technical vacuum. They are building solutions for customers. To serve customers effectively, everyone in an organization must understand customer needs. This learning can be even more time-consuming than technical learning. It involves talking to customers, experimenting with existing solutions in the market, and building prototypes that help connect technical and product learning.
Organizations have limited time and resources. If they don't value learning, they won't encourage engineers to spend working hours on it. We should pause for a moment to clarify that the learning we're talking about here is independent. Mandatory training and other learning materials can be effective, and they can contribute to a culture that values learning, but they do not constitute a culture of learning. Remember that our definition of culture enables employees to make decisions autonomously. For learning to be a core value in an organization's culture, employees must be motivated to learn independently.
There are obvious benefits to a culture that values learning. Engineers gain skills and accumulate knowledge that enables them to solve new problems and improve existing solutions. The team becomes more capable and innovative. The team is also better able to predict future needs because they have a greater awareness of how the landscape is changing. A less obvious benefit is that it fosters knowledge sharing within the team. If everyone knows they are expected to learn and improve, and that the organization expects them to use working hours to do it, they will be more likely to seek out teammates to learn from.
There are many ways to translate the value of learning into practical processes. The value is much more important than the specific processes. Do what works for your team! Here are a few things you can try:
For more on learning at work, see my previous post here.
Performance in a growing organization is a positive-sum game. This means that if your teammate achieves great results, you are both better off and not precluded from achieving your own great results. All else equal, success for the team means success for each of the individuals on it. Successful teams are typically given more opportunities, and individuals coming from a successful team are usually seen in a more positive light.
Think about the most and least successful organizations you know. Now imagine you're considering two engineers who seem equally capable, but one works for a successful organization and the other works for a failed one. Who are you more likely to hire? I would guess the engineer from the successful organization. Your team's reputation matters. Fairly or unfairly, your team's reputation becomes part of your own.
Adopting this mindset enables teams of engineers to work more effectively together. The team's goals will become more important than individual goals, because everyone on the team understands that team success has a greater impact on their individual career growth. Practically, this means team members will be less concerned about who takes which tasks and will collaborate and communicate more often.
When team results are valued culturally over individual results, individuals are incentivized to raise the overall standard of performance on the team. This encourages two seemingly contradictory behaviors. First, team members will be more likely to help low performers improve their performance. Second, team members will be more likely to argue that low performers should not be on the team at all. These behaviors can be compatible. It is better for everyone if low performers are able to raise their level, and a certain amount of investment from high performers in that effort is efficient. When it becomes clear an individual won't be able to reach the team's performance standard quickly enough, it may be time to explore a role for them elsewhere in the organization or in another organization.
A few things to keep in mind:
Customers do not care how your organization is structured. They also don't care what processes your organization uses to achieve results (assuming those processes meet their moral standard). Product ownership means prioritizing results for the customer above org structure, plans, and processes. Org structure, plans, and processes should serve the desired customer experience, not define it.
In practice, sub-teams and individuals within engineering organizations that do not value product ownership will bicker over who "owns" what code, forgetting that the customer does not care. When a problem arises, everyone assumes they are better off if someone else spends their time and resources dealing with it. Often this means wasted time and resources arguing about who should solve the problem and a delayed solution. An unwillingness to even collaborate often means not only a delayed solution but a suboptimal one.
How do we overcome this collective action problem? A culture of product ownership rewards results for the customer over sticking to annual plans. It does not mean everyone jumps when any bug is reported. It means the entire organization is incentivized to work together on prioritizing unexpected problems against planned feature development, adjusting plans to new information and determining which individuals or teams are best suited to solve which problems. It means maintaining a master list of the organization's priorities, at varying levels of granularity depending on the context.
To be a product owner, you need to understand how the product works and the customer needs it serves. This goes back to the importance of learning and talking to customers, but it also means training yourself to spot gaps and defects in the customer experience. One important way to do that is to use the product often, going through common customer workflows, taking notes, and asking lots of questions.
Every culture is unique. The possible combinations of values and processes that could define an organization's culture are infinite. In this article I've argued that continuous learning, teamwork, and ownership are three values that should be part of every culture. I've offered some guidelines to consider as you try to translate these values into processes your team can follow, but ultimately it's up to each team to decide how they want to operationalize and internalize their shared values.