Why cultural change is so hard
Breaking through cultural barriers to become more agile necessitates several changes without overwhelming the teams or disrupting business functions.
23 Jan 2020
Why cultural change is so hard
This is an excerpt from our recent paper Practical steps towards an agile digital culture. Download the paper for the full insight.
Cultural change has long been identified as a critical element of digital transformation. The culture of an organization must be aligned with the nature of the business and the demands of the technologies that underpin it. Most communications service providers (CSPs) have risk-averse cultures, where the focus is on detailed planning, centralized decision-making and doing everything possible to avoid mistakes. That has worked well – until recently. But as they aim to compete with new digital businesses by adopting cloud-based technologies and Agile development methods, operators need to adopt a culture that encourages risk, increases innovation and decentralizes decision-making.
TM Forum’s Digital Transformation Tracker has been measuring global progress and challenges to transformation for three years. From the beginning, CSPs have identified culture as a ‘very serious’ barrier to transformation (see graphic opposite). TM Forum members aren’t the only ones who feel this way – a 2018 report from Harvard Business Review (HBR) commissioned by Red Hat paints the same picture, finding that more than half of respondents cited culture as “a significant impediment/challenge to their organization’s digital transformation efforts.” The survey also found that more than 40% of respondents considered process to be a challenge and a third felt that technology was a hindrance.
Cultural change has long been identified as a critical element of digital transformation. The culture of an organization must be aligned with the nature of the business and the demands of the technologies that underpin it. Most communications service providers (CSPs) have risk-averse cultures, where the focus is on detailed planning, centralized decision-making and doing everything possible to avoid mistakes. That has worked well – until recently. But as they aim to compete with new digital businesses by adopting cloud-based technologies and Agile development methods, operators need to adopt a culture that encourages risk, increases innovation and decentralizes decision-making.
TM Forum’s Digital Transformation Tracker has been measuring global progress and challenges to transformation for three years. From the beginning, CSPs have identified culture as a ‘very serious’ barrier to transformation (see graphic opposite). TM Forum members aren’t the only ones who feel this way – a 2018 report from Harvard Business Review (HBR) commissioned by Red Hat paints the same picture, finding that more than half of respondents cited culture as “a significant impediment/challenge to their organization’s digital transformation efforts.” The survey also found that more than 40% of respondents considered process to be a challenge and a third felt that technology was a hindrance.
In surveys like HBR’s, culture, process and technology are often categorized separately, but they are interlinked. In fact, changing culture is tightly coupled to changing technology. For example, Agile methodology (see graphic opposite) places value in the ‘release early, release often’ approach, which is greatly at odds with the traditional telco world of infrequent, tightly controlled releases.
More to the point, not only is it a different process, it also embodies a different cultural mindset. A ‘release early, release often’ approach requires DevOps practices that involve much tighter collaboration between development and operations teams. It also requires technologies such as containers which make it easier to release individual components of a system.
This complex interlinking of many elements can make the process of change seem complex and daunting – not least because it essentially means having to change a number of things at the same time, says Ofek Ben Arie, Chief Architect at Amdocs’ Kenzan Digital Consulting and Software Engineering Division.
“You cannot separate the change of technology and the change of culture,” he says. “But if you change too many things at once, you often find a team is left in a state of paralysis or chaos.”
Thus, breaking through the cultural barrier to become more agile means coming to terms with two key realities: Several changes will have to occur at once, and this must happen without overwhelming the teams or disrupting business functions in the meantime.
The most common approach to overcoming this challenge is to start with one cross-functional team working on a small number of reasonable-sized challenges, says Thomas Waldrop, Director Consulting Services – Global Verticals Practice, Red Hat.
More to the point, not only is it a different process, it also embodies a different cultural mindset. A ‘release early, release often’ approach requires DevOps practices that involve much tighter collaboration between development and operations teams. It also requires technologies such as containers which make it easier to release individual components of a system.
This complex interlinking of many elements can make the process of change seem complex and daunting – not least because it essentially means having to change a number of things at the same time, says Ofek Ben Arie, Chief Architect at Amdocs’ Kenzan Digital Consulting and Software Engineering Division.
“You cannot separate the change of technology and the change of culture,” he says. “But if you change too many things at once, you often find a team is left in a state of paralysis or chaos.”
Navigating the change
Thus, breaking through the cultural barrier to become more agile means coming to terms with two key realities: Several changes will have to occur at once, and this must happen without overwhelming the teams or disrupting business functions in the meantime.
The most common approach to overcoming this challenge is to start with one cross-functional team working on a small number of reasonable-sized challenges, says Thomas Waldrop, Director Consulting Services – Global Verticals Practice, Red Hat.
“I always suggest people start with three minimum viable products (MVPs) and assume that you might not deliver
to the business case on the first two,” he says. Indeed, it’s important to understand that these projects might not be immediate successes – thus, it makes sense to choose market segments that are compatible with that reality. The team needs to be set up for success, but with reasonable expectations, where the most important thing is what they learn, not what they deliver.
As for how to cope with the tidal wave of simultaneous changes, one option is to recruit outside agencies for help.
Red Hat’s Open Innovation Labs, for example, provides support such as an initial technology stack to reduce some of the initial variables and allow teams to get started. Having picked the right problems and set up the team for success, another key area to get right is how to measure progress and success. A key point is that traditional metrics probably aren’t going to work.
“Management teams tend to reach for traditional metrics,” explains Amdocs’ Ben Arie. “So if the goal is to
transition 12 teams to Agile in a year, they will measure success as six teams in the first six months, which makes very little sense. If the objective of the exercise is to learn, we need to measure what we have learned.”
Once the team has established new ways of working that have proven successful, its experience can then serve as a proof of concept for the rest of the organization, providing what Ben Arie calls a “paved road” for other teams. Those teams can start with a process playbook and technology templates that have been road-tested and proven by the cross-functional team.
to the business case on the first two,” he says. Indeed, it’s important to understand that these projects might not be immediate successes – thus, it makes sense to choose market segments that are compatible with that reality. The team needs to be set up for success, but with reasonable expectations, where the most important thing is what they learn, not what they deliver.
Look outside
As for how to cope with the tidal wave of simultaneous changes, one option is to recruit outside agencies for help.
Red Hat’s Open Innovation Labs, for example, provides support such as an initial technology stack to reduce some of the initial variables and allow teams to get started. Having picked the right problems and set up the team for success, another key area to get right is how to measure progress and success. A key point is that traditional metrics probably aren’t going to work.
“Management teams tend to reach for traditional metrics,” explains Amdocs’ Ben Arie. “So if the goal is to
transition 12 teams to Agile in a year, they will measure success as six teams in the first six months, which makes very little sense. If the objective of the exercise is to learn, we need to measure what we have learned.”
Once the team has established new ways of working that have proven successful, its experience can then serve as a proof of concept for the rest of the organization, providing what Ben Arie calls a “paved road” for other teams. Those teams can start with a process playbook and technology templates that have been road-tested and proven by the cross-functional team.