Dana Finster

Hello. Hello. It is great to be here, imagining all your smiling faces staring at your screens. I'm Dana Finster, and I've spent most of the past seven years as a developer and team lead for Walmart in Bentonville, Arkansas, where I've had opportunities to lead change on teams and through grassroots community at Walmart.

Today, I'm going to highlight some research and studies that you might already be familiar with, and I'm going to tie in my experience to share with you how diversity, autonomy, and cohesion are the foundation of organizational culture; how they can work together and overlap to enable high-performing teams; and how they can be misunderstood and leave organizations floundering, wondering why they're not achieving their goals.

I first want to share a little about me and some reasons that I'm really passionate about culture. In college, I majored in East Asian studies with a focus in Japanese, and minored in Romance languages. A large percentage of my studies focused heavily on culture. I'm originally from Maryland outside DC. I spent some years living in Texas, Virginia, and Florida, all pretty much Southern states. I have worked over the past 20 years for organizations in a lot of these states. The majority of my family hails from New York and New Jersey, so that makes me fully qualified to say, "Bless youse guys' little hearts."

Seriously, these things have taught me to appreciate cultural differences in various societies, whether they exist in different countries, states, or organizations. An organization is a society by definition, and organizations are made up of people that interact and share a common culture. An organization is all about the people. They're the innovators, the creators, the supporters, and the maintainers of everything in the company. Within organizations, culture is how individuals define themselves, conform to shared values, and contribute.

So if you're working toward transformation and you're focusing on tools, tech skills, and whether your developers should learn ops or your ops should become developers, I really hope that this talk will help you understand the need to think of your organization as a society and recognize how the culture of the organization greatly impacts its capability for success.

Companies have been striving to transform for over a decade: digital transformation, agile transformation, DevOps transformation. I feel like there's an oversaturation of information around transforming organizations, yet so many still never get off the ground or they fail to meet their ultimate goals, because transformation means real change down to the cultural foundation. And culture is the hardest thing to change. When culture, the basis of our society, changes, people have to find new ways to fit in, and that's often outside their previous comfort zone.

At one organization I worked for, we were given a goal to shift development teams to continuous delivery and an expectation that that would lead to more frequent delivery and higher-performing teams. To achieve that goal, a task was set to centralize the delivery platform. As we evaluated deployment tools and began architecting for a self-service implementation of a popular build tool, I began to reach out to teams for a pilot and put together multiple resources and presentations for the organization on continuous integration ways of working. It could be used to help our teams shift from the large monolith releases they were used to, with long QA periods, to CD: integrating automated testing, small code commits, frequent deployments.

It could be great, but I was not able to really start training and work with the teams. Instead, once the task of creating a centralized pipeline was set, the goal became onboard all the teams. The original goal was lost. Instead, we were asked to just pull all the existing pipelines, with their branches and CD anti-patterns, and build those into the centralized tool. Once everybody was onboarded, then we could start evangelizing and actually changing how we work.

It became clear to me that teaching teams to work better, giving them time for improvement to be truly successful, was not on the agenda. Somehow, it wasn't tangible enough to be the focus. Instead, we could easily show that we built a centralized platform and how many people were onboarded as a measure of success, regardless of any actual improvement. If you don't fundamentally change anything, by definition you are not transforming.

So how can we fundamentally change our culture? What can we focus on, and where can we start? Start with culture.

Ron Westrum studied how information flows through organizations and identified three typical patterns: pathological, bureaucratic, and generative. You may be very familiar with this information. I just want to give a quick overview to guide where we're going to be headed today with this conversation. Ron Westrum's organizational typologies are also referred to in the book Accelerate, which lays out the findings from the DevOps Research and Assessment, DORA, on indicators of high-performing teams. One of those findings was that a generative culture predicts improved software performance.

In generative organizations, they did find a higher level of cooperation. Messengers were trained, not shot. Are you living in a pathological culture? Does anything there look familiar to you in that column? If so, you may want to start transforming to a generative culture. Does failure lead to scapegoating and blame? We want failure to lead to inquiry and finding what about our system caused failure. Is novelty crushed? We need novelty these days. If we are doing the same things over and over, we're not going to get ahead in our business. We need to establish a generative culture where novelty is implemented and innovation can thrive.

I want to share how I see diversity, autonomy, and cohesion as the building blocks working together to create the foundation of an organizational culture, and how the right recipe can grow and support a generative culture, and misinterpretations can backfire.

Cohesion supports the shared mission. It encourages a high level of cooperation, and people collaborate more effectively. Teams with autonomy have ownership, and they share the risks. A higher level of trust and psychological safety comes from a combination of cohesion and autonomy because people are not blamed for failure and messengers are not shot. Diversity heightens innovation, and autonomy allows for the implementation of that innovation and new ideas.

This is how we get to generative culture. Think of these as foundational layers. Start with the individuals: people with a variety of demographics, skills, experience, and interests. Then build autonomous teams made up of these individuals within a cohesive organization that's aligned to defined goals and purpose.

So start with diversity: the condition of having or being composed of different elements, variety. I want to talk about people and individuals. This diversity iceberg identifies some surface-level, or observable, traits and deep-level diversity, unobservable traits, because there are many characteristics that make up an individual person and that make us all different.

In a generative culture, the focus on the mission allows diverse individuals to set aside personal or departmental issues and openly share their varied perspectives, skills, experiences, styles, and talents to collaborate and produce better solutions than they could achieve individually. We get the most benefit from individual diversity when ideas are actually shared. Working together as a team, we get not only better solutions, we also get more innovation.

Diverse experiences and abilities give teams that variety and perspectives. As an example, a friend of mine was on a team developing the application for distribution centers, and one of his teammates was colorblind. The team was able to benefit from the super-immediate feedback on UX changes that would not look good for colorblind users.

Another example are times when I've seen myself and other senior members of my team kind of go rogue with a solution to save the team time, because we've done this before, and I would just take care of it. I have seen that backfire. It's bad for the team not to be part of the design in general, but in this case, when the logic was completed and wasn't working as expected, it was brought to the team. A junior developer, who was not as experienced in the business domain or the technology, asked a few questions that we might have thought of as beginner or silly questions. But those questions immediately shed light on what the senior devs had overlooked.

We need the diversity in our teams, in our skills, and our tech stacks, to take advantage of the best tech for the purpose, to take advantage of different perspectives, and to get those ideas and innovation.

But caution. We're going to talk about how these can be misapplied, too, because there are some things that are important to remember to avoid unwanted outcomes. Obviously, we always want to have diverse individuals. We can't really do that wrong. But it does require the culture to be inclusive. We don't gain the benefits if everyone's ideas and opinions are not considered, and lack of inclusion erodes trust, eventually shutting people down.

While the right tech for the right purpose is a benefit of having diverse skill sets and tools availability, added complexity and cost to the team and organization must be considered. Tech for the sake of tech often leads to unnecessary complexity. One team I worked closely with spent 18 months working on a solution in totally new tech because it was cool and interesting. It's what they wanted to do. None of this new tech was supported by the existing infrastructure teams. The team's goal was to replace an older system with a new one with super-fast processing, and in a way that was fun to build.

After less than a year in production, my team ended up inheriting this new solution. When we added logging and learning, we discovered reliability issues, and reliability was the customer's primary concern, not speed. We were also faced with one product that our team now had to support that was completely outside our wheelhouse in terms of tech. We ended up spending six months replacing it by upgrading the original system. In an enterprise, reliability and maintainability should be considered over fast and fun. Don't overcomplicate things with diverse tech for the sake of tech.

Without a shared mission, diversity of thought can result in arguments instead of discussions with an outcome of consensus. Again, I've been in a situation where my team had unclear goals and a cacophony of product responsibility. We were a group of people that had a hard time seeing eye to eye. Everyone at every skill level was incentivized by management to stand out on their own and lead their own projects. Our diverse mindsets and skills, coupled with personal egos, made it literally impossible to get along as a team. We ended up splitting into a couple smaller teams, determined by tech interest and preferred ways of working, and then we struggled to split up work between the teams. I don't recommend this approach. A lot of the fundamental disagreements that put us in this situation to begin with could have been avoided with a clear mission and incentives to collaborate to provide better solutions as a team. Without that shared mission, we had chaos.

Because what we also had was autonomy: the quality or state of being self-governing, self-directing freedom. Organizations themselves can have varying levels of autonomy. Governments or parent organizations might put restrictions on organizational autonomy. Teams and individuals can only achieve autonomy within the boundaries of the amount of autonomy that the organization has.

At a team level, autonomy means the teams are allowed to define their own processes and culture in order to work in the best way for that specific group of individuals, rather than adhering to global process mandates dictated outside of their context. Individual autonomy means the freedom to do the right thing, the right to ask for what they need to get things done, the authority to perform their role aligned to the organizational mission, the responsibility that comes with being a member of society, and the right to hold themselves and other team members accountable.

An important concept is that autonomous teams does not mean the team has the freedom to focus on whatever they want. If we're not aligned and have a high level of autonomy, it results in chaos. That's exactly what happened on that team I talked about earlier. Chaos might be okay at the beginning of a startup, but it's not sustainable for long-term success. For an innovative organization with a collaborative culture, the generative culture we're looking for, it's important for both alignment and autonomy to be high. That's what allows teams to own their business problems and have the freedom to experiment and continually improve.

Ownership improves quality. When the entire team is affected by each team member's contribution, each individual has a vested interest in performing as well as they can and real incentive to help each other succeed. When team members share ownership, they can decide together what is best within their context to deliver the outcomes expected of them. They can choose how to work together and the tech stacks they use.

For example, on my current team, we have a lot of products and tech stacks to support. We chose to streamline those tech stacks in order to reduce our overall cognitive load because it was slowing us down and making it harder for us to collaborate as a team. Shared ownership and incentives help team members set aside egos and allow knowledge to be shared freely. Individuals want to share and learn from each other. Problem solving gets better. Immediately, when you have more brains working together on a problem, you're probably going to solve it faster, but it also contributes to building a more resilient team for the future because the whole team is involved and knowledge silos inside the team are broken down. When teams are able to direct their own work toward common goals, seek regular feedback, and are more involved with the purpose of the work, they are going to be more engaged and more motivated.

But caution again: autonomy can also get wrong. The amount of autonomy matters. Too much or too little autonomy leads to low performance. I once heard a VP from another organization talking about how he didn't want to micromanage teams, so he would not give the teams direction. He expected teams to self-organize. That's a good buzzword, right? But that was too much autonomy for the teams. They actually had no idea what it was they should be self-organizing around, and several of the teams were duplicating efforts, working to solve the same problems because they happened to pick the same things to work on.

On the flip side, teams are not trusted with full ownership of their business problems, and solutions suffer under mandates on how to do work that are often determined outside the context of the team. They lose their feeling of accomplishment, and morale and engagement just get destroyed. To avoid giving mandates, give teams desired outcomes. If we need to cross the river, that's the team goal. Don't tell the team to build a bridge, but let the team figure out the best solution. It might be a bridge, but it could be a boat, airplane, or even swimming, depending on the context.

Poor structure also leads to ineffective interdependencies. Tightly coupled teams lose their ability to make decisions autonomously. Hard interdependencies, whether it's having to use the same tech stacks or having to coordinate deployments, take the team's focus outside of the team's mission, and efficiency is lost. To prevent this, focus on deliberate structure and build loosely coupled teams.

Finally, we've seen how autonomy without alignment results in chaos. So let's look at alignment and cohesion, which is the act or state of sticking together tightly. In the context of teams, cohesion means that team members are aligned to the mission, respect everyone on the team, assume good motives, are fully committed to team decisions and strategies, and can communicate effectively.

Cohesion is really important because cohesive teams are happy when the team succeeds. They feel like they're part of something significant, which increases self-esteem and morale, and in turn increases performance. A well-defined organizational mission, vision, and goals create the focal point for cohesion. It encourages autonomous teams to rally around those goals and understand the business value that they can provide. Morale becomes higher because of the increased team member communication and friendly team environment and the sense of pride in their contributions.

Working together as a cohesive unit allows for faster feedback and helps eliminate long deployment testing cycles that result from handoffs and siloed work. I've been lucky to have several team experiences in my career where I've worked with a cohesive team executing CI, working independently or in pairs on the same small feature. The first time, it was such an aha moment for me when I pushed my small piece of code and saw it all come together both faster and better than if I built it alone. It's a great feeling as a developer, and it solidified the idea for me that reaping the full benefits of continuous integration requires a cohesive team.

Building cohesive teams can take some effort and requires the right incentives and social opportunities. There are some important tactical ways that we can build team cohesion. First of all, the right incentives are the foundation. Team incentives need to be in place. If rewards and recognition are only focused on individuals, then individual performance will be valued over team performance. Egos and competition will destroy any hope of team cohesion.

But incentives can't do it alone. It's hard to feel part of a team if you don't know your teammates. Social events are a good way to start building team cohesion. They let teams get to know and understand each other better. Remember, our organization is a society, and it's important for individuals to find their fit within that society. Social events can be anything from a team lunch to a multi-day retreat. When teams are comfortable with each other, mobbing and pair programming feel more natural, but it also provides ongoing team building that strengthens cohesion.

One team I know would take Friday afternoons and go off-site to have mobbing sessions or mini-hackathons, to get out of the daily work environment and have a little more fun working together. Off-site collaboration can be used effectively for a variety of purposes: informal brainstorming, cross-team community collaboration, or to build internal tools to improve team process or architecture that might not be prioritized otherwise.

Finally, some things to watch out for with cohesion. Cohesion requires a solid mission that aligns to business value. "Be hardcore" or "zero defects" are poorly defined missions that can result in unwanted outcomes. We can write a lot of useless software that no one needs or wants, but it has zero defects, and mission accomplished. We work long, hard hours and produce lots of code. That's hardcore, but useless if it's not deployed.

Forced cohesion negatively impacts autonomy. In another organization, I saw the CTO who wanted to ensure everyone was doing things the same way take it to the level of micromanaging, in that he personally coordinated all of his departments, not allowing them to speak directly with each other, mandating all designs and changes be approved by him personally. It's an extreme way to kill autonomy, innovation, and any need for diversity, and it results in people leaving the company.

Another example is when all teams in my area were told to use two-week sprints. My team knew we worked better in shorter sprints, so we asked why it was being mandated. As it turned out, it was all about reporting. They wanted to report in two weeks. We said, okay, we can report in two weeks, but we're going to work in smaller increments. That was fine. So think hard as to whether mandates for standardization make sense in all contexts, because where they don't, the teams may appear cohesive, but it may be hurting more than helping. Even team-building activities that are set outside the country club and can't be enjoyed by everyone on the team can negatively affect cohesion. Individual incentives lead to low cohesion because they encourage developers to only do what's good for them, not for the team as a unit. And remember: high cohesion between teams does not mean tightly coupled. Tight coupling of teams can destroy team autonomy.

To sum up, cohesion with autonomy gets us aligned to our mission. We feel ownership, but we have less innovation without diversity. Autonomy with diversity gives us freedom, but a little bit more individual focus. It leads to chaos without that cohesion to keep our eyes on the mission. Diversity with cohesion: we'd be pretty innovative, but suffer some poor quality because we don't have ownership or responsibility without that autonomy.

High-performing teams can thrive in a culture with the proper balance. Cohesion results in collaboration toward the shared mission. Autonomy enables ownership. Diversity fuels innovation. What do we get when we layer them right and put them together as the foundation of our society? Happy people working together on high-performing teams to fulfill the organization's goals and deliver business value.

Now what help do I want? How are you gathering information needed to recognize that individual people are excelling or struggling while also incentivizing cohesive teams and maintaining trust? That's a hard one. HR does still need to be able to understand when people should be paid more money or promoted, and that's something that I continue to search for and struggle with, although I have a few ideas on that. I would love to hear yours, and I want to hear your stories. Have you had similar experiences? Have you experienced different results?

Reach out to me via email, LinkedIn, or Twitter, and I'll leave you with some recommended reading. I mentioned Accelerate and Westrum's psychology of organizational cultures. If you're looking to build a culture where high-performing teams can thrive, Team Topologies and The Phoenix Project are a couple of resources that you really don't want to miss. Thanks so much, and I hope you all enjoy the rest of the conference.