Organizations Have Subcultures

An organization does not have a culture.

It has many cultures.

Peter Drucker famously said that culture “eats strategy for breakfast,” and that to create lasting change, an organization’s culture must change. Although, it is really more complicated than that, because strategy influences culture, just as culture influences outcomes, which influence strategy. Nothing is simple!

But if you assume you have a homogeneous culture, you will not get very far.

An organization’s culture is, of course, the work-related values and behavioral norms that prevail in the organization. It should not be surprising that those norms might be different in, say, the advertising group than they are in the finance group.

The problem is that for our organization to have business agility, it is no longer practical to work in silos. If we are in the finance group, we cannot say "We do our thing and development teams do their thing."

Today, development teams often need to talk to accounting teams, due to regulatory risk management requirements, which need to be built into transactional systems. And development teams need to talk to data architecture teams too; gone are the days when teams could wait for carefully crafted updates to an information model. Today, collaboration needs to be real time and just-in-time. Gone are the days when a product design team could spend six months defining a new product and then hand it off to be built - today these activities need to happen together. And gone are the days when new technologies such as a machine learning system could be perfected in the lab and then subsequently productized - today, these activities need to happen together and evolve together - “joined at the hip.”

Today, knowledge of the entire product development and delivery flow and all its major aspects needs to be universal. Otherwise, intelligent holistic conversations about tradeoffs with regard to the product’s initial features, time to market, quality, risk, and how the product is supported become impossible to have.

The way that Amazon maintains its digital business platform, which gives it the ability to deploy new features every day with confidence and continuously measure customer response, is - in the long run - as important as what is on its business platform.

Consider Amazon. The way that Amazon maintains its digital business platform, which gives it the ability to deploy new features every day with confidence and continuously measure customer response, is - in the long run - as important as what is on its business platform. The way that Amazon delivers its products to customers, with a one day turnaround, is as important as the fact that it does deliver its products. And so all business leaders need to have an understanding of the multiple levers that need to be continuously adjusted to keep Amazon successful, and how those levers affect each other.

That means that different parts of an agile organization cannot operate as silos; and it means that any business agility transformation needs to change the culture across the organization - which means that multiple cultures need to change.

Cultural Norms for Business Agility

The Agile 2 initiative uncovered behaviors and norms that are important for business agility. This is not the place to go into a detailed discussion of each of those, so we will summarize them in Table 1 below.

Table 1: Values and behavioral norms (abstracted from Agile 2)

• Encouraging and fair forms of leadership
• Inquisitive rather than commanding before asking
• Thoughtful (not reckless) experimentation
• Measurement as a standard practice
• Continuous transparency
• Working incrementally but still end-to-end
• Open door
• Socratic and dialectic discussion
• Empowerment, accountability, and integrity
• Competitive or toxic behavior is shunned
• Assumption that learning is necessary
• Tolerant of diversity in how individuals prefer to do things
• Safe to voice an unpopular opinion
• Patience to stay with an approach to see it through
• Value deep discussions
• Embrace and leverage of individual and team expertise

Do you think that these values and norms would be the same in the accounting group as in the software development group? And does it matter?

Yes, it does matter because those groups need to collaborate together. Software developers often have to work with the accounting side in order to add traceability into the business processes.

Finance people are accustomed to dealing with datasets. They refine a dataset over time, checking it and checking it again, and finally they deliver it. It cannot change after that.

This is very different from today’s software development process in which rather than crafting a product until it is finished, software developers refine the automated processes used to deliver the product or service. They spend most of their time improving each process, running it to deliver a product or service in a test mode, checking that, and then adjusting the process again. When they are done, they have not completed a product or delivered a service: they have completed an automated process for creating the product or delivering the service. In addition, work is incremental, where one improves the process so that it can produce a minimum viable product; and then one adds to it, to add more features. There is no such concept of incremental working in accounting.

This different way of looking at things can often hamper discussions between product development and finance people: the finance people want to talk about the final result; the development people want to talk about the processes that produce the final result. Thus, these two groups have an entirely different way of thinking about things, and even the words they use might have varying meanings in their different contexts.

Accounting has other cultural norms that are quite different from agile software development. Accounting manages risk using the concept of controls: steps or mechanisms that check results and raise an alert if something is inconsistent. Controls are used widely in software platform operations, but the concept is largely unheard of in application development, unless the application is in a regulated industry such as banking. Outside of applications in regulated industries, software developers think in terms of test coverage - not controls. Thus, we have a mismatch in risk management paradigms.

Due to the risk-focused nature of accounting, it emphasizes attestation and traceability. These ideas have been left behind by the DevOps movement, which replaces these approaches to risk management with a more fluid “real time” approach, again based on test coverage and feedback loops at every point in the flow of product or information.

The attestation approach has a strong cultural impact on accounting. Attestation requires individual accountability. The Agile movement has de-emphasized the idea of individual accountability, in favor of focusing instead on process improvement, using metrics to inform on progress in that regard. Thus we have a strong difference in attitude about something as fundamental as accountability and its importance, as well as process measurement.

If one examines other areas of an organization, one will find different cultural norms in each area, reinforced by the practices and beliefs of that profession. It is unreasonable to expect that a single horizontal cultural transformation initiative can impact everyone in a uniform way. Some people might be so confused by the requested changes that they feel that they will not be able to do their job anymore if the changes take effect.

What To Do

The first thing to do is determine if your organization’s culture is in the way!

If you are considering change, then you must have a goal. If that goal is to increase business agility, then it is crucial to consider the cultural norms that are needed to enable the changes that you have in mind. The next step is to assess your organization’s actual cultural norms.

A powerful way to do that is through a cultural assessment. There are organizations that can help you to define what norms you need, and assess through surveys and interviews what your organization’s norms actually are. For example, if you have come to realize that Agile 2’s values and behavioral norms are important for achieving agility, then your assessment should focus on measuring those, to see what the gaps are.

It is critical to perform this assessment in each functional area, because as we have explained, culture varies from group to group.

Once you know what your cultural gaps are, the hard part begins: you need to plan a way to gradually adjust your organization’s culture while you also begin to transition people to Agile 2’s ways of working (or whatever way of working you have defined as desirable).

By “ways of working” we are not talking about a new set of processes. We are talking about new leadership models, new collaboration models, new ways of growing people, and new expectations and assistance regarding learning and awareness of the broader set of business functions. These new ways of working not only need to be inculcated throughout, but they need to be internalized and demonstrated by leadership, so that everyone can see that these changes are for real.

Business process changes will follow.

Most likely you will need help achieving business agility, because it is a huge transformational undertaking. It is also not something that can be planned like a process change, with a big plan that merely gets executed. It is what Agilists rightly call a learning journey, because just as the Marshall Plan to rebuild Europe following World War II was continually adjusted based on results on the ground, your outcomes will need to be measured and the plan continually adjusted accordingly.

The Marshall Plan is an interesting case, because its directors wisely realized that it should be mostly directed indigenously:

“Marshall stressed that it would be “neither fitting nor efficacious” for America to try to direct Europe’s economic recovery “unilaterally.” Common objectives were necessary — and they had to reflect a broader vision of political order for Europe, the Atlantic region and, ultimately, the world. The Marshall Plan inspired a new international order by enabling the nations of Europe first to rediscover their own identities in its pursuit, then to go on to build systems transcending national sovereignty, such as the Coal and Steel Community and, eventually, the European Union.” [1]

Conclusion

Cultural transformation needs to account for the naturally different sub-cultures that exist within any large organization. Cultural change is about changing behavioral norms and values, so that as the change takes root, people behave differently on their own, because they have internalized the change and now identify with it.

To achieve this, one must learn the reality and challenges of each group within an organization. What does not work is to broadcast a set of values and expect everyone to suddenly embrace those. A few eager people will, but most will not, and behavioral norms will not change.

Instead, organizational leaders must take an inquisitive approach, working with each group to help them interpret the changes through their lens, discussing their particular challenges, and then helping them to define new behaviors and processes that align with the new norms that are desired, and embodied, by leadership. In the course of that, it will become clear that key individuals need coaching and mentoring on forms of leadership that are new to them. Indeed, everyone can benefit from that.

While process improvement can lead to valuable changes, focusing on process can limit positive outcomes once they hit the brick wall of cultural resistance, as the organizational immune system kicks in to fight off the perceived threat to “how things are done here.” Transformational change is about empowering the right people and helping them learn the styles of leadership that will be most effective in their unique context. By identifying the current subcultures, and thoughtfully nurturing individuals to become leaders in cultural change in alignment with the organization’s leadership, a true business agility transformation becomes possible.