It’s more important than ever for software organizations to build a healthy engineering culture. Healthy cultures rally developers around common goals: shipping high-quality work, continuously improving, and having fun in the process. Your culture is key to recruiting and retaining the talent you need to ship exceptional customer experiences.
This article is based on an interview that Bas Peters (Solutions Engineer at GitHub) conducted recently with me on software engineering culture. A webcast of the complete interview also is available.
I addressed these topics long before developers used GitHub, as in my 1996 book Creating a Software Engineering Culture. These writings are more relevant than ever. More and more organizations wish to create a culture where people can take ownership of their work, where all work directly contributes to the company’s objectives, and where people can work on projects that are meaningful to them.
Karl, how would you define culture?
Formally, I consider culture to be a set of shared values, goals, and principles that guide the behaviors, activities, priorities, and decisions of a group of people working toward a common objective. In short, culture describes how we do things around here, how we work together, and what we think is important.
How does culture reveal itself in a software organization?
Culture reveals itself in how the organization sets goals, the technical practices people use, the ways people collaborate on projects, how the team members make decisions, and how management sets priorities and communicates with team members.
Another indication of the culture is whether or not management behaves in ways that are congruent with the values they claim are important. If management says one thing but then does something different, or if they say they value certain behaviors but then reward others, that’s a problem. Maybe it’s really a culture of deceit or confusion, not a culture of integrity and openness.
Is there such a thing as a bad culture?
Sure. You could have a culture in which there really is no set of shared values, goals, or principles. People believe different things are important, they don’t agree on project priorities, and they don’t have shared expectations that help them work effectively toward common goals.
The culture provides a foundation for the decisions people make and the actions they take. If you apply those decisions and actions consistently, that reinforces the culture. If decisions and actions are chaotic and inconsistent, that’s still a characteristic of the culture, but it’s not so healthy or predictable.
A project manager recently asked me for advice. He said at his company “Speaking the truth will get you fired.” That sounds like a very toxic environment. If you can’t be honest about issues that you see, estimates you prepare, or commitments you make, you’re dealing with a bad culture.
How do you recognize a bad engineering culture?
One sign could be high staff turnover. Nobody wants to work in a place where people are afraid to be truthful, or where people with power don’t want to deal with reality. Sometimes, certain individuals just don’t fit into an existing culture well, so it’s best for everyone if they decide to move on. But if a lot of people want to leave, the culture might have problems.
In an unhealthy culture, people don’t trust each other or their managers. Management might lie to technical staff. Developers might feel they have to lie to their managers or colleagues about their estimates or task status. In a blaming culture, where people worry about being accused of holding up progress or writing code with too many bugs, people will lie to protect themselves.
One of my consulting clients told me that in his previous company, whenever a project got into trouble, management would announce that they would start holding code reviews to find out who to blame for the project being behind schedule. Would you want to work in a place like that? I wouldn’t.
As we are talking about software development, what is a "healthy" software engineering culture?
I think there are three essential components, with commitments at three levels:
- A personal commitment by each developer to create high-quality products by applying effective software engineering practices.
- An organizational commitment by managers at all levels to provide an environment in which software quality is a key success driver and which enables each team member to achieve this goal.
- A commitment by all team members to continuously improve how they work, thereby continuously improving the products they create.
These three commitments imply that team members should devote a certain percentage of their effort not just to project work but to training and to ongoing improvement of their software development processes.
In a healthy culture, people share their knowledge. Some people selfishly protect their knowledge, thinking that gives them job security or power or control. I knew a man like that once. When I’d ask him a question, he would give me just a portion of the answer. It’s like he was thinking, “If I give Karl the whole answer, he’ll be as smart as me. I don’t want that, so I’ll give him half the answer and see if he goes away.” I don’t respect people like that.
Mutual trust and respect are other characteristics of a healthy engineering culture. Free and open exchange of knowledge and ideas also is good. One way to exchange knowledge is through peer reviews. A successful review program requires that people be comfortable and trusting to share the work they do with their colleagues.
Do you think a healthy software engineering culture can help organizations to reach their goals?
Effective collaboration in a healthy culture can definitely help organizations achieve their goals. People in a healthy culture recognize that each of the roles involved in developing a product is complex and requires specialized skills, training, and knowledge to be effective. Management provides the team members with the training, the tools, and the resources they need to be successful at whatever they do.
For instance, it’s not realistic to expect every great developer also to be great at eliciting requirements, planning projects, estimation, testing, and all the other activities that go into building complex systems. So a healthy culture staffs projects with a team of people who have all the necessary skills to get the job done well.
People who work in a healthy culture are realistic about what they can achieve. They rely on data from previous experience to make sensible estimates and commitments to other team members, management, and customers. Teams in a less healthy environment are more likely to make impossible promises, and they more often fail to meet their commitments. Nobody wins in a situation like that. I’m not going to promise to do something that I know cannot be done. I prefer to under-commit and over-deliver.
Do you have any practical advice regarding how organizations can start to improve their engineering culture?
I suspect most organizations haven’t thought about just what the characteristics of their culture are. So a first step could be to build a short list, perhaps 10 or 12 items, that describe what the members of the organization think is important about how they work together to build software.
Everyone in the organization should have the opportunity to participate in this discussion. They might not agree with every principle someone proposes, but most of the organization’s members should buy into some set of shared concepts like this. Everyone is affected by the culture, so it’s empowering if all feel they can help shape it.
As an example, here are a few of the cultural principles that one group I worked with many years ago came up with:
- Never let your boss or your customer talk you into doing a bad job.
- Ongoing education is every team member’s responsibility.
- Customer involvement is the most critical factor in software quality.
- Quality is the top priority; long-term productivity is a natural consequence of high quality.
- If you measure what you do, you can learn to do it better.
- Your greatest challenge is sharing the vision of the final product with the customer.
Those were just six of our fourteen principles. Your teams might share some of those values, or they might not. But discussing just what principles, values, and attitudes are important will help align the team members so they can make decisions and take actions that are consistent with that shared philosophy.
The last principle you mentioned is interesting: your greatest challenge is sharing the vision of the final product with the customer. Where did that come from?
I realized long ago both how important and how challenging it is to define the requirements for a software system. Customers, business analysts (BAs), and developers all need a common understanding of what we’re going to have at the end of the project. Any disconnects lead to an expectation gap, a difference between what’s delivered and what people thought would be delivered. That’s a problem, because then you’re going to have to fix the product until it matches the real customer needs.
Unfortunately, customers often aren’t very good at expressing—or even understanding—their needs. That’s why we need BAs to facilitate the conversation between customers and IT so we can reach that shared vision, a chunk at a time. This principle led me to my focus on software requirements; I’ve written four books and many articles on that topic.
If you believe this principle, you’ll work hard to engage appropriate customer representatives in the development process. The way my group started doing that back in 1985 was first to identify our important user classes, and then to identify specific individuals who could serve as key representatives of each user class. We called those people “product champions.”
The product champion model was a great way to engage with customers so we could build software that really met user needs. A culture that’s less concerned about achieving this shared vision might not have adopted a systematic way to work with user representatives.
Do you have any advice on how to sustain the evolution of a healthy software engineering culture?
The organization’s leaders should be conscious of the principles the group has agreed upon and look for opportunities to reinforce those with others. It doesn’t hurt to remind people about them periodically, such as when someone makes a decision based in part on the group’s values.
Of course, culture evolves over time. You just hope it doesn’t devolve. I’ve seen that happen too, like when a new manager came in to take over my group after I stepped down as the manager. He didn’t share our commitment to a quality-driven culture and continuous improvement, and some of what we had achieved gradually eroded away. That was discouraging.
One way to sustain the culture is to keep it in mind when you’re interviewing new candidates to join the organization. People who strongly disagree with aspects of your culture and do not accept it could undermine your efforts.
One of my groups started a metrics program that included tracking how each of us spent our time on project activities like requirements, coding, and testing. The data helped us to understand how we really did our work, compared to how we thought we should do our work. I once interviewed a candidate to join my group who objected to this time-tracking. Maybe he was afraid the data potentially could be used to harm him. That’s a risk with any metrics program, but it wasn’t our intent. He clearly wasn’t going to accept an important aspect of our culture, so I didn’t hire him.
Do you have some specific advice to managers on how they can help build and sustain a healthy culture?
Managers have a big impact on shaping an organization’s culture. They must align their own actions and priorities with the values the group agrees are important.
Suppose a manager claims that quality is a top priority. But then he doesn’t want to give project teams the time to perform peer reviews, or he penalizes people if bugs are found in their work during a review. Maybe the manager praises team members who deliver on schedule, even if their products are riddled with defects. Such incongruent actions can harm your efforts to grow a healthy culture.
My Creating a Software Engineering Culture book describes several dozen each of culture building and culture killing actions. These are things that someone—often a manager—can do that will either reinforce a focus on a healthy culture or will undermine it. It’s worth looking at those lists of culture builders and culture killers to make sure you’re doing a lot more builders than killers.
Managers—and enthusiastic team members—must recognize that people and organizations can only absorb change at a certain rate. You can’t radically change the beliefs, behaviors, or technical practices of an organization overnight. I follow this principle: “Gentle pressure, relentlessly applied.” As a leader, you should always be steering the organization in some improved direction, but it must be a gradual process, not a sudden transformation.
Management turnover is a big obstacle to sustained improvement efforts. Each time a new manager comes in who wants to change the direction, you start all over. This gets highly frustrating for the team. After that happens once or twice, the team members will conclude that the company isn’t seriously interested in changing at all.
How should you deal with resisters?
Often, people who don’t agree with where an organization is heading will decide to go work somewhere else. So it might be a self-correcting problem in many cases.
If certain people actively resist culture changes — or passively resist them by not performing actions that the group has agreed upon—there must be some consequences. Start by talking with those resisters to understand their concerns and try to make them comfortable with the organization’s direction. They could have legitimate concerns that should be addressed.
But it’s also fair to establish certain behaviors as job expectations and to hold team members accountable to conform to those expectations. If the disconnect is too big, you can’t let a resister undermine everyone else’s genuine efforts to improve how the team works. The resister might have to move on.
Do teams need a leader or are they better off as self-organizing teams?
The idea of self-organizing teams is popular, but that doesn’t mean they don’t have leaders. In almost any group, certain individuals will step forward and lead in certain areas, whether or not that role is assigned to them by management. They could be leaders in technical areas, project management, customer relations, or anything else.
Different people have different personalities, aptitudes, and interests for different kinds of work. We’ve probably all known people who were strong technically but did not want to take a visible leadership role. That’s perfectly fine. It’s important to make sure all team members are comfortable in the work they perform and also to give them growth opportunities to move into other areas at the right time if they wish to.
But I do believe someone needs to steer the team toward a common objective, set goals, monitor progress, make adjustments when necessary, and ensure the right people are on board and doing the right work well. I’ve worked in teams where everyone was equal on paper, but someone typically still emerged as the leader to whom others turned to set the direction.
Do you have any final thoughts for us?
Every organization develops a culture of its own, whether spontaneously or with steering. If you want to create a healthy software engineering culture, you must decide what that means in your environment and help lead the organization in that direction.
Author: Karl Wiegers is Principal Consultant at Process Impact, a software development consulting and training company in Portland, Oregon. He has a PhD in organic chemistry. Karl is the author of numerous books on software development, most recently Software Requirements, 3rd Edition (with Joy Beatty). He’s also the author of Successful Business Analysis Consulting: Strategies and Tips for Going It Alone, a memoir of life lessons, and a forensic mystery novel, The Reconstruction. You can reach him at ProcessImpact.com or KarlWiegers.com.