The Design of Engineering Culture
The Design of Engineering Culture
This author analyzes the word culture in an organizational context and identifies some key elements for designing one.
Join the DZone community and get the full member experience.Join For Free
What is culture? The answer to this question has a deep impact on engineering effectiveness. Numerous books and articles talk about the importance of culture in DevOps, but few teams can successfully define or create it. Many organizations use the terms "culture" and "values" interchangeably. However, there's more to culture than values, and this becomes apparent when looking at how different organizations that espouse the same values, in theory, end up having different cultures in practice.
To illustrate this, consider two organizations that both list "a culture of learning" among their organizational values. In Organization A, post-mortems are widely attended and their write-ups are well-read. When incidents occur, the remediation items that come out of incident reviews are prioritized, and incidents rarely recur. In Organization B, individual teams sometimes hold post-mortems for incidents that affected them, but write-ups aren't read beyond the team. A recurring engineering-wide calendar invite for post-mortems goes unused more often than not, despite frequent production incidents. Remediation items are deprioritized in favor of new features and incidents recur often.
On the surface, Organizations A and B both have post-mortem meetings, write-ups, and remediation items, and both claim to value organizational learning, but the outcomes — the impact of those values on their respective cultures — are different. Culture is more than just the values an organization claims to have. For our purposes, culture is the collection of social scripts, lore, behavioral norms, biases and values, incentive structures, and processes that describe behaviors of a distinct group or social environment. DevOps as a cultural movement is a series of trends shifting instances of this collection — for example, the trend towards social scripts that encourage more collaboration between development and operations teams.
Introducing Designable Surfaces
In this example, each organization has taken the same designable surfaces and approached them in different ways. A designable surface is something concrete that can be directly changed in order to impact one or more aspects of culture. For example, the process of running a post-mortem (such as gathering an incident timeline, discussing the incident in a specific way, and creating tickets for remediation items) can be directly changed (by getting champions to model a different way of running the post-mortem meeting or creating a better template for post-incident reports) and those changes will shift that cultural process. Changing designable surfaces in an organization, monitoring the impacts of those changes, and iterating toward goals is how to build lasting culture change. The heart of culture design is understanding how collections of designable surfaces can be changed in concert to achieve specific outcomes.
The most successful transformations tend to be those that involve multiple designable surfaces working together. Consider the example of post-mortems and how useful people within an organization perceive them to be. Some of the relevant designable surfaces here include:
The processes by which facilitators are trained
The ways in which calendar invites are treated
The format or template used for the post-mortem write-up
The agenda for the post-mortem review meeting
The work-tracking software used for ticketing remediation items
The social scripts around how post-mortems are communicated
While any one of these surfaces alone could have some impact on culture, the whole is far greater than the sum of the parts.
Consider what steps Organization B might take if they wanted to improve the utility of their post-mortem meetings. If they hypothesize that poor facilitation was causing the meetings to be ineffective and thus people considered them a waste of time, then they might start requiring facilitators to attend a more structured training to try to address this. In addition, they would also want to do things like ensure that tooling exists for potential facilitators to sign up for training, provide a way for people wanting to run a post-mortem to find trained facilitators in a timely manner, edit or delete the recur- ring calendar invite that people had gotten used to ignoring, and communicate all of these changes throughout the organization. Any one of these changes occurring individually would not be anywhere near as effective as the collection of them combined.
Making Changes Stick
An important part of any culture transformation is getting changes to stick. To understand how change happens, you need to consider both motivation and attention. A common question often asked when considering a DevOps transformation is something along the lines of, "How can I get the old-school sysadmins to change when they don't seem to want to?" At a certain level, the answer is that you can't. While organizations have some ability to coerce certain behaviors out of their employees with things like threats of being fired, doing so will create an adversarial relationship that is counterproductive to creating meaningful change.
In order for changes to be both significant and long-lasting, people must be motivated to make those changes. This motivation can be intrinsic (coming from within, such as a person with a lot of curiosity and drive to learn to teach themselves new skills) or extrinsic (driven by external factors, such as only being eligible for a raise or promotion if a new skill set is acquired), but it has to be present in one way or another. Any successful change will require understanding the motivations of the people involved, and there is no one-size-fits-all answer. Different people, teams, and organizations each have unique factors contributing to their intrinsic and extrinsic motivations. As a manager or senior IC trying to enact organizational change, being able to work with people to understand their motivations and concerns is crucial.
In addition to motivation, change requires attention. A fair amount of people's attention is devoted to doing their work when everything is business as usual. Any extraordinary circumstances (such as financial stress, workplace conflicts, or outside personal issues) will deplete people's attention budgets further. Be aware of the different factors outlined in Paloma Medina’s BICEPS model of the core needs and motivations of people in the workplace. If people feel that their needs aren't being met, that can take their attention and make them less amenable to change. For example, if an engineer feels like they aren't being treated equally (the "E" in BICEPS) by their manager and that is causing significant stress, it will be harder for them to focus on something that feels less important, such as remembering to use a new post-mortem template.
Company- or department-level stressors — such as restructuring, staff turnover, or organizational financial concerns — will reduce the overall capacity for change. Especially over the long term, bad habits can form, adversarial thinking can become ingrained, and people can become so burnt out that they lose most of their attention or capacity to change at an individual level. This sort of situation makes meaningful change more necessary but also more difficult to enact. In exceptionally stressful circumstances, you may need to wait until big picture issues have been resolved before trying to make meaningful changes — for example, don't try to force a new post-mortem facilitation training program on people right after (or during) a big round of layoffs.
Designing for Change
Ultimately, an engineering culture can be designed, but like any design process, it must be approached with care and rigor in order to be successful. Rather than focusing on the negative aspects of an existing culture that need to be changed, it is more useful to identify which cultural behaviors you would like to see, what values you want to embody, and take proactive steps towards those ends. It cannot be forgotten that teams and organizations are made out of people who each have their own goals, values, and motivations, and as such there is no one-size-fits-all solution that will lead to a quick and easy DevOps transformation. By keeping in mind attention and motivation at both individual and organizational levels, you can use designable surfaces in concrete ways to build and maintain the collaborative DevOps culture you want.
Opinions expressed by DZone contributors are their own.