search

Vastly improve your software engineering culture in three steps

Cathy Reisenwitz

by Cathy Reisenwitz on February 18, 2020

We know intuitively that a software engineering organization’s culture plays a strong role in its success or failure. But recent research has made it possible to objectively measure culture and tie it directly to positive outcomes for software engineering organizations.

The authors of Accelerate: Building and Scaling High Performing Technology Organizations used Westrum’s Typology of organizational cultures to categorize teams into three types: “generative,” “pathological,” or “bureaucratic.” The authors found that teams with generative cultures enjoy shorter lead times, more frequent releases, faster service restoration, and higher levels of job satisfaction.

This post will offer three tips for helping your organization’s culture move away from any pathological or bureaucratic tendencies and toward a more generative culture.

1. Get mission-oriented

Generative teams focus on and dedicate themselves to the mission. Meanwhile, leaders in pathological teams sacrifice the greater mission for personal gain. And bureaucratic organizations prioritize adherence to the rules.

So step one of moving to a more generative culture is to keep the mission front-and-center. But before you can prioritize your organization's mission, you need to know what it is!

As a software engineering team, you may be able to derive your mission from the larger company’s mission. For instance, our mission at Clockwise is to “Help the world make time for what matters.” Therefore our engineering team’s mission is to build the software that helps the world make time for what matters.

You can also use a vision statement for this purpose. Here’s a good article on the difference between a vision statement and a mission statement. Nonprofits are often great at writing compelling, simple vision statements. For example, the Alzheimer’s Association is dedicated to “a world without Alzheimer’s.” Oxfam’s mission is “a just world without poverty.”

What is your engineering team’s mission? Do you have a vision statement that articulates it? It doesn’t have to be fancy.

As a CTO or Engineering Manager, it’s your job to communicate the long-term company vision to your team.

Nailing down the vision can take years, and the task of communicating it never really ends, so start today in order to emphasize the primacy of the mission to everything your team does.

2. Create psychological safety

Once you’re agreed on a mission and everyone is bought in (or on their way), it’s time to clear the hurdles to accomplishing the mission. Fear is the first hurdle to clear, because fear keeps information from moving efficiently through an organization. And without good information flows, success is impossible.

In Indistractible, Nir Eyal points to a Google study of the characteristics of effective teams. Of all the traits, one was by far the most impactful: Psychological safety. Originating with The Novartis Professor of Leadership and Management at Harvard Business School Amy Edmonson in her own TEDx talk, psychological safety means people feel like they’re not going to get punished or humiliated if they make mistakes or submit ideas, questions, or concerns.

Information will never move as well throughout an organization if people are afraid that sharing it will make them look bad or get blamed.

Lack of psychological safety harms information flows

Lack of psychological safety harms information flows TEDx

Better teams made more mistakes than worse teams.

What Edmonson and her research assistant found upon closer inspection was that teams with greater levels of psychological safety were more accurately recording, discussing, and working to ameliorate their mistakes.

Trust is essential to psychological safety. Engineering Manager and Management Coach Ling Abson recently wrote that Trust = (Credibility + Authenticity + Reliability) / Self-Interest.

As a manager, you’re likely not the person on the team who’s most familiar with the tech. Defer to people who know more than you. Nothing will erode trust faster than pretending to know more than you do or having to be the smartest person in the room. Instead, admit when you don’t know something, ask people who do know, and make decisions collaboratively. “It’s okay to admit that you don’t know something,” Ling wrote. “The team will respect you for it. The worst is to assume you have to know it all and make a call that is wrong for the team without working through it with the team.”

3. Critique always, blame never

Right now, less than 5% of product teams actually acknowledge failed projects. Psychological safety makes it okay to not know everything and okay to make mistakes.

“In a healthy organization, there is no shame or harm in raising issues early,” Camille Fournier wrote in The Manager’s Path.

To encourage your team to feel safe discussing missed opportunities, failures, and other learning opportunities start by ditching blame. To remember this tip, try this acronym I made up: CABL: critique always, blame never.

Product, Agile, and UX Consultant Adrian Howard uses something called a Failure Swap Shop with his clients to ensure everyone on the team feels safe discussing mistakes. It’s got four steps:

  1. Hi, my name is NAME and I failed
  2. EVERYBODY CHEERS
  3. Explain your failure
  4. Explain the lesson learned.
Failure swapshop example

Failure swapshop example AdrianHoward.com

“Clearly, being generative is super important to a healthy and dynamic engineering team,” said Gary Lerhaupt, Head of Engineering at Clockwise. Gary facilitates psychological safety among his team in their quarterly retrospectives.

The meeting starts with everyone saying aloud everything interesting that happened since the last retrospective. “This helps everyone get into the same headspace and to pull forward items we had otherwise collectively forgotten about,” Gary said. They then spend some time writing what went well and what needs improvement about each event on Post-It notes. When they discuss “needs improvement” items, blame doesn’t come up. Instead, the focus is on learning and improvement for the whole team.

This way no one is afraid to bring up failures because they know they won’t be blamed for doing so.

Going forward

A software engineering organization’s culture will impact lead times, release frequency, mean time to restore service, and job satisfaction. It’s an important thing to get right. Westrum’s Typology of organizational cultures is a great starting point for learning how to create a culture that facilitates success. To create a more generative culture, it’s helpful to orient the team around a common mission, create psychological safety, and move away from blame while encouraging people to discuss failures and mistakes.

Cathy Reisenwitz

Cathy Reisenwitz

Cathy Reisenwitz is Head of Content at Clockwise where she oversees the Clockwise Blog and The Minutes Newsletter. She has covered business software for six years and has been published in Newsweek, Forbes, the Daily Beast, VICE Motherboard, Reason magazine, Talking Points Memo and other publications.

Sign up for our newsletter

Ready to try Clockwise?

Get started for free