By Joanne Milne, Senior Business Development Manager.
Links to precursors:
Introduction to the series
Part I
This is the second of a three-part series considering the topic of how to change towards a DevOps Operating Model mitigating risk to your people and success of the change initiative. Part II will explore further how to build organisations based on trust, collaboration, experimentation and empowerment, all key in managing change and in building a sustainable DevOps culture.
I will discuss how leadership and active, visible multilevel sponsorship are critical to driving change (for culture and practice) for DevOps; for achieving continuous integration, continuous delivery (CI/CD) and automation (this sentence is about as technical as this part gets!). This will highlight how leadership style and managing (and accepting) complexity (and at times chaos) are intrinsically linked – what is simple often quickly becomes more complex and is not easily-managed by more traditional leadership. We believe that developing and recruiting for transformational leadership capability is the most critical, yet often missed, ingredient – for guiding DevOps culture change – for creating the no-blame and psychologically safe environment for “failing fast – failing forwards”. This is as critical at supervision / team leader levels as at ‘C-Suite’ and Directorship levels. For DevOps teams, team leaders and managers are extremely influential mediators of the desired culture.
Furthermore, organisational structure will be explained in relation to its impact on culture, with reference to Conway’s Law.
But first, let’s begin with perhaps a less obvious, but important question for managing change in DevOps:
What does family systems psychotherapy and managing change have in common?
Many people identify who they are with their work, to the extent that when asked socially ‘what do you do?’, many (especially in Western cultures) will lead with their profession. When telling stories about our personal identity, psychologists recognise this as an indicator of an individual’s life story, viewing them as reliable indicators of the preferred culture and how the individual fits within it.
For many people, organisational transformation, and even more simple changes, threatens personal identity. People are often surprised with how they feel when confronted with unexpected changes, and can respond in unexpected ways. Partly due to this, it is important to place people at the heart of any change initiative and so use a model that will build in empathy and considerable support for people experiencing such a change. In coaching our customers’ DevOps capability, we refer to a more psychologically grounded change model, whilst working with other more commercially successful ones, such as the ADKAR model (Awareness, Desire, Knowledge, Ability, Reinforcement).
For those who need more justification than ‘it’s nice to be nice’, there is good commercial justification for managing emotions, more than will be possible from a change model such as ADKAR. Put simply, ‘70% of change initiatives fail to deliver expected benefits’ (according to research conducted by McKinsey Consultants). This failure is due, in large part, to a failure to manage the emotionally-charged experience of change.
Too frequently, change management becomes a tick box exercise that presents as orderly, but fails to have the desired impact. It omits creating the essential emotional connection for the people who must accept the changes and adapt.
Being overly goal-oriented for instance will alienate the stakeholders who must embrace the changes. Having high empathy accelerates change – it is the ‘secret sauce’ of change! Hearts and minds can only be engaged when people believe in the merits of what is happening and feel fully supported in making what can often feel like a leap of faith.
In transitioning people to a DevOps culture, additional complexity results from this largely unacknowledged, emotionally-charged experience that many people are about to embark on. A family systems psychotherapist recognised this first, in changing family behaviour patterns and explained it with the following simple behaviour change model.
Virginia Satir illustrated change as triggering a whole gamut of emotions, through the Growth Model ‘Change Curve’; or as some have described it, the rollercoaster of change! Satir has been cited as the ‘mother of family therapy’ and produced this model to demonstrate how family members will each experience the changes that must be made for the family to stay together.
This model forms part of Satir’s Transformational Systemic Therapy (STST) and considers change from a people-based perspective, with the aim of transitioning people through the expected stages towards change and growth.
When used for planning change, this model builds in empathy and develops far richer change plans as well as enhancing relationships with people. I have also had managers tell me they have changed how they relate to their families in applying this!
‘Becoming DevOps’ i.e. highly agile, automated, collaborative, autonomous, and continuously improving, requires changing how people interact across previously quite siloed functions. The means of leading and managing are quite different. Something I will explore in this article, comparing transformational versus transactional leadership.
In change management terms, the ‘Transforming Idea’ that Satir’s model references, can be experiencing the early green shoots of change, particularly quick win improvements that illustrate the benefits of processes improving as well as having some influence in the changes coming. This is often an important ‘Aha!’ moment for people.
Effective organisational transformation requires a positive emotional reaction to shift entrenched beliefs and elicit behavioural and culture change.
Coaching key individuals through each stage of growth is an essential means of eliciting new behaviours and practice essential for DevOps.
In Part I, the difficulties of transitioning from a more rigidly hierarchical and bureaucratic organisation towards a more devolved, flexible and product or market-oriented ones are discussed in greater depth. Part III will explain how we assess and demonstrate the gap between the current state and the desired future state for our clients and thereby produce realistic and meaningful plans to bridge it.
For now, consider how people experience transitioning from a paper-based service, to one that is online and automated; or from a manual practice to one using cobots or robots. For many this can feel highly unsettling and result in some degree of negative emotion ranging from feeling anxious and demotivated, to downright angry! If you have been part of such a journey, you may have heard comments such as,
‘this stupid system doesn’t do what it’s supposed to’
‘I liked it better when I could just sit with the applicant’
‘it was much quicker before, when I knew where everything was!’
And in relation to fearing the smiling assassin,
‘these robots are going to steal our jobs!’.
These statements expose a likely deficit in factoring user experience (UX) and designing for the user proactively. It might also indicate lack of, or very light, user research and under investment in stakeholder engagement; lacking the necessary empathy-driven feedback loops (e.g. empathy maps; gathering and quantifying ‘pain-points’; contextual inquiry; motivational interviewing; etc.) to tap into the value, reliability and quality benefits the changes will deliver. These tactics and tools are all valuable for assessing and responding early and iteratively to what the users and customers need, to what they think, how they feel and think about the changes, and so how they are likely to behave. UX design and research and stakeholder management are key from an early stage, however it is sometimes missed entirely or left until too late in the service / product lifecycle. This is an area that Design Thinking methods can breach, helping deliver value and connecting ides to outcomes from the early stages of user engagement!
Iterative reviews of how various individuals, teams and groups are adapting to the new ways of working, and how the organisation is realising the benefits, are key in any business change management plan, that we refer to as ‘stakeholder management’, ‘celebrating the quick wins’ and ‘benefits realisation’. In Automation Logic’s transformation team, we place greater emphasis on the importance of investing in structured methods such as Value Stream Management (VSM)* for quantification of expected benefits and service / product design, as a result of how often we see this misunderstood or simply neglected. Without these structured activities, barriers to adoption and greater resistance to change are almost guaranteed.
“Whenever there is a product for a customer, there is a value stream.”
(Mike Rother and John Shook, Learning to See)
Digital performance is no longer measured solely by operational efficiency, with customer experiences, digital products, services and revenue generation all under scrutiny.
Value Stream Management is a management technique or practice that focuses on increasing the flow of business value from customer request to customer delivery. It is a structured, standardised approach for measuring and improving flow helping to shorten time-to-market, increase production, improve quality and deliver desired business outcomes.
In terms software development, Mary and Tom Poppendiek introduced the idea of managing the value stream, along similar lines to manufacturing, and they translated manufacturing wastes into “the Seven Wastes of Software Development”, in their book, Implementing Lean Software Development: From Concept to Cash, as follows:
In Part III I will share how Automation Logic’s Digital Transformation Diagnostic Tool guides our customers to build effective, empathic and iterative feedback loops.
High empathy in leaders, managers, supervisors and change managers or management consultants is also an essential factor for transformation (true across all sectors, not just for DevOps). In manufacturing, for instance, robots and cobots have reduced the number of people required for those parts of the process, and some organisations, although by no means all, have ensured that plans exist early on and are clearly communicated for how their staff will be redeployed. The ones who do regularly consult and communicate what the future holds, empathically, providing examples of what is in it for the individual to change (often referred to as ‘What’s in it for me?’ – WIIFM), are the ones who have a better chance of success. This has been one of Toyota’s principles for fostering Lean thinking and continuous improvement so effectively, i.e. jobs were not at risk and ample support was provided to test new ways of working, and led by competent and culturally-congruent supervisors and managers.
Transformational leaders place high value on consultation, communication and engagement, and we coach our customers where necessary, for instance in dialogue planning and storytelling, viewing these interpersonal engagement methods as important as the more factual change elements. As illustrated by Satir’s Change Curve above, storytelling is an important element for developing and adapting an individual’s personal sense of identity, helping them to incorporate the changes into new practice. Change plans that inspire change involve tracking the early, ‘quick wins’ and gains achieved and celebrating these widely.
And remember this: despite some people within the organisation holding the role of change champion or change leader, it does not necessarily mean that they will be immediately effective. They too need support to develop the competency and confidence, to communicate and behave congruently, to consult and adapt using structured change methods, for dealing effectively with challenges and resistances as they occur. Culture change work frequently involves a high degree of behaviour-change coaching with the change champions, leaders, influential managers, supervisors and team members, taking a cross-sectional, multi-layered approach.
Leaving people behind, or allowing them to fill in the blanks, usually results in people predicting the worst and getting stuck in a cycle of resistance and chaos, as illustrated by Satir’s Change Curve.
The changes required must feel congruent as well as compelling. Development and Operations team members will not be the only ones affected. Supervisors, managers, other functions, and leaders of the business must embrace the bridging, collaborative, and fail fast mindset that supports the DevOps culture.
In terms of congruence, it is important to understand how people think about effective leadership, management and supervision today and how to this shift to achieve DevOps. This is the least predictable but most important change to manage. Satir’s Growth Model is the simplest illustration of how people experience this that I have found!
Leadership and a generative culture of learning from experimentation and continuous improvement for ‘failing forwards’ quickly.
Pathological, Bureaucratic and Generative (Adhocratic) cultures rely on distinct leadership styles, also covered in Part I. Ron Westrum proposes that a Generative culture provides the foundation for necessary agility, innovation and ensuring that the eyes and ears closest to the action are fully empowered to share and leverage their insight and knowledge, pre-empting potential disasters and other negative effects. In general terms, bureaucratic or pathological cultures tend to display a task-orientation, and generative culture a people and relationship-orientation.
It is generally acknowledged that a high task-orientation and ‘command-and-control’ leadership style inhibits the generative learning and continuously improving culture, through reducing psychological safety, trust and empowerment. I have found this to be as true in assessing and coaching for safety and zero harm to people and the environment with large FTSE 10 organisations who operate in high-risk environments, as well as within the tech industry.
The style of leadership is something that we are keen to uncover as early as possible with any client engagement as this will provide greater insight into the magnitude and the complexity of the change required.
The reality of changing culture usually requires leader, manager and supervisory support including but not limited to coaching, to support each level becoming congruent with the new cultural norms. This requires involvement and planning with the wider organisation to ensure the support is provided as the transition will be difficult for some, particularly when the style is so distinct to that being reinforced today, with behaviours previously recognised as effective now becoming obsolete. When this happens, sustainability is also more likely.
This leadership style is one of ‘command and control’, and considered effective in bureaucratic, hierarchically-driven organisations. It relies on extrinsic motivators such as pay, conditions, promotion, etc.
This is quite distinct to transformational leadership, which is far more person-centred, interactive and taps into the internal, intrinsic motivations of individuals. Rewarding or penalising and even punishing followers requires very different behaviours to those of empathic communication for inspiring change and empowering people to become highly agile and autonomous. Transactional leadership is often cited as appropriate for maintaining the status quo, however this need is quickly becoming obsolete and we recommend the transactional style be used only as a small part of a more evolved and transformational leadership style.
It is critical that learning and development and HR functions are aligned with the need to develop distinct leadership for the following reasons…
…transactional leadership poses particular problems for DevOps.
In terms of applicability for DevOps, or for any organisation seeking to achieve empowerment and agility, there is a particularly problematic dimension of transactional leadership – that of management-by-exception.
Active management-by-exception is highly controlling, requiring managers or supervisors to take action whenever corrections are needed. This poses the greatest risk to empowerment and agility however.
At Automation Logic we often experience times when a Scrum Master and a team of DevOps-ready engineers are needed to work within our customer’s existing culture. This is often not yet transformationally led, agile-mature nor ready for DevOps. We acknowledge in collaboration with them the limitations associated in working outside of the ‘ideal’ model for DevOps. In undertaking Automation Logic’s Digital Transformation Diagnostics with them early on, we can quickly and relatively simply highlight where the people, process and technical gaps are, and importantly for them, agree which gaps they can prioritise, and which they must accept – at least for now. We support our customer’s journey and match the DevOPs ideal ways of working to their needs, introducing improvements wherever the changes can be made.
Important to note: a transactional leadership style is still favoured by many organisations who operate Production Line continuous improvement and Lean methods. For instance, team leaders will be notified immediately when production variances are outside of the tolerances / the operators’ control. In this scenario, the team leader will be proactive in dealing with the issues; actively participating, watching team members and intervening to prevent mistakes. The same can also be true of a Scrum Master or equivalent. Used in this context, transactional leadership is still an effective style. Used in isolation it will work against the expected gains from DevOps.
Examples of transactional leaders are, of course, plenty and this is still the most common leadership style, particularly in long-standing, more traditional industries. An obvious example is evidenced in how football (soccer) clubs manage their organisation, with managers typically hired and fired based on winning matches; team members hired / fired depending on the matches won and lost.
The US senator, John McCarthy during the Cold War (1950s), used this style for weeding out communism and uncovering Soviet spies. He demonstrated this style through rewarding those who brought him Soviet infiltrators and threatening those who did not comply or obstructed him.
General Charles de Gaulle of France also displayed this active transactional style during and post-World War II. A quote from his experience of cooperating with the British during this time is an interesting anecdote:
“When I am right, I get angry. Churchill gets angry when he is wrong. We are angry at each other much of the time.”
Churchill’s wife, Clementine, responded to these comments, saying “General, you must not hate your friends more than you hate your enemies” to which de Gaulle famously replied, “No Nation has friends, only interests!”
A transformational leader will rarely make these sorts of comments, however de Gaulle was pivotal in leading the French resistance movement during Nazi occupation of France, at a time of complete crisis for France. This active, transactional style can be effective, in a crisis for instance, but typically will yield short-term results around something tangible.
Transactional leadership is not wrong and can be effective and expected, particularly in more hierarchical organisations, however…
… DevOps benefits will not be sustainable where transactional dynamics dominate over those needed to support DevOps. The culture currently operating in your organisation today will exert huge influence. It is vital that congruent behavioural interventions can be identified for building a stronger, more sustainable foundation for DevOps and digital business transformation. These must foster the transforming ideas that provide leaders at all levels the insight and desire to grow!
Transformational leadership requires being empathic and humble (providing this is authentic .. more on this a little later!). It is described in models such as servant leadership, authentic leadership and the three-level leadership model, whereby the leader shares vision, distributes power, puts the needs of the employees first and helps people develop and achieve unprecedented results.
This style is effective in fostering DevOps thanks to the empathy involved in building highly adaptive, empathy-led change plans, in communicating WIIFM, as well as the care demonstrated for individuals, which is necessary for building trust and engaging hearts and minds.
Unlike transactional leadership (‘if you do x, I will give you y’ or ‘carrot and stick’), the transformational style is acknowledged to be a way of life rather than a prescribed set of techniques. To be demonstrated authentically and congruently, it can require an element of behavioural coaching for making deeper psychological shifts. Being authentic has sometimes been described as the ‘true north’ of being effective as a leader, and this is essential for being congruent in communicating the vision and purpose of the change as well as the WIIFM.
In coaching a zero tolerance attitude across leaders, managers, supervisors towards harm to people or environment in offshore oil and gas operations, this involved developing coaching plans for all layers and functions, particularly supervisors and team leaders who are extremely influential for mediating the culture with operational levels. This coaching supported them in making, for some quite significant changes, developing their empowering, trust-building, servant leadership behaviours and underpinning attitudes. It supported them in communicating and behaving authentically, yet congruently.
Transformational leaders will not typically employ a ‘telling’ / ‘command and control’ style, rather preferring a coaching, inspiring and empowering one that ensures people feel safe to accept greater autonomy. The high trust afforded them is also due to their ability to defer to those with the most authority and competence in any given area; to resist the need to be the ‘superhero’ manager.
Trust is the essential ingredient for empowerment and autonomy. Transformational leaders do not need to have all the answers and are comfortable displaying vulnerability. This builds healthy, trusting relationships (at home and at work)!
“It’s often said that ‘data is the new oil’. Instead, we’d argue that it’s trust that will decide whether businesses – and the fourth industrial revolution itself – succeed. There is both a moral and business imperative to do more than increase profits.”
(Mark Hawkins, President & CFO, Salesforce)
It is clear that the fear of the smiling assassin is more closely associated with a transactional leadership style, and minimised where there is improved trust and so cooperation, experimentation, learning, improvement and innovation.
Transformational leaders are excellent enablers of others, communicators, networkers, connectors and influencers, key for DevOps.
Transformational leadership can be learned through coaching, responding to feedback and being empathetic to the end-users, the customer and people experiencing the change.
In Part III I will discuss how we work with our customers to evaluate and develop the practices needed for transformation towards DevOps.
Claims are often made in the DevOps community that organisations can begin their DevOps transformation journey by starting out small, by changing one team at a time and I agree … to a point. Yes, this can be useful for ‘proving the concept’, but watch out, as it also risks prematurely disproving it! It also risks creating silos of excellence that do not easily collaborate with the wider organisation. At some point, the wider system (and culture) is going to work against the principles needed unless they are equally invested in and collaborating with the wider business purpose of DevOps (the idea of the DevOps ‘silo’ being covered in Part I). Teams can become isolated practitioners who will eventually be overpowered by the structures in place and Conway’s Law will prevail:
“Organizations which design [IT] systems…are constrained to produce designs which are copies of the communication structures of these organizations… The larger an organization is, the less flexibility it has and the more pronounced the phenomenon.”
In other words, the organisational culture and structure will destroy your beautiful architecture…
Every.Single.Time..
One of the ‘grandfathers of DevOps’, Gene Kim (noting that DevOps is still a young discipline!), considers 3 broad structural archetypes – Functional, Matrix and Market. These 3 archetypes cover what is required and points to one more conducive for structuring for DevOps, as organisations structuring according to people having a market or product orientation.
This structure allows for responding quickly to customer needs, for optimising delivery of customer value. These organisations tend to be flat, with multiple, cross-functional disciplines working closely together (e.g. marketing, engineering, etc.). To note is that this can lead to potential redundancies across the organisation however (and strong likelihood of the fear of the smiling assassin emerging when moving towards this).
This is how many prominent organisations adopting DevOps operate – in extreme examples, such as at Amazon or Netflix, each service team is simultaneously responsible for feature delivery and service support.
How an organisation is structured will have tremendous desirable and undesirable effects on the software produced, the resulting architecture and business outcomes. Autonomy and collaboration are wholly interdependent with structure.
Kim makes the point:
“…broadly speaking, to achieve DevOps outcomes we need to reduce the effects of functional orientation (“optimizing for cost”) and enable market orientation (“optimizing for speed”).
Which means having many small teams working safely and independently, quickly delivering value to the customer.”
He also acknowledges that even functionally-oriented organisations can implement DevOps, with a caveat:
“many of the most admired DevOps organisations retain functional orientation of Operations, including Etsy, Google, and GitHub.
What these organisations have in common is a high-trust culture that enables all departments to work together effectively, where all work is transparently prioritized and there is sufficient slack in the system to allow high-priority work to be completed quickly.”
Over the past 30 years, the de-facto process for managing risk in software delivery has been ITIL, developed by UK government agency, the Central Computing & Telecommunications Agency (CCTA) in the 1980s.
A core objective of ITIL is to assure service quality and to manage costs. This typically includes adherence to a stringent set of processes to ensure that application or environmental changes will not risk service quality.
In theory, the framework of checks and balances decreases the risks associated with introducing change to an environment.
In reality, it often led to a culture of risk-averse and overly cumbersome processes that could ultimately increase risk through change bundling, corner-cutting, and extended delays for approval from resources with only a cursory understanding of the environment.
Ensuring teams are kept small enough to share two pizzas (applying Amazon’s famed ‘two-pizza rule’ as it moved away from a monolithic code base in 2002), with people, process and technology working together, minimises bureaucratic change approvals and accelerates delivery. (That’s another blog!)
A switch to DevOps can reap significant rewards for your organisation but the challenge should not be underestimated.
In summary, here are 10 key points discussed in Part II:
One: Effective organisational transformation requires a positive emotional reaction to shift entrenched beliefs and elicit behavioural and culture change.
Two: Coaching key individuals through each stage of growth and change is an essential means of eliciting new behaviours and practice essential for DevOps.
Three: Leaving people behind, or leaving them to fill in the blanks, usually results in people predicting the worst and getting stuck in a cycle of resistance and chaos, as illustrated by Satir’s Change Curve.
Four: In terms of congruence, it is important to understand how people think about effective leadership, management and supervision today and how to this shift to achieve DevOps. This is the least predictable but most important change to manage. Satir’s Growth Model is the simplest illustration of how people experience this that I have found!
Five: Transactional leadership is not wrong and can be effective, for instance in more hierarchical organisations, or in times of crisis. However, DevOps will not be sustainable when transactional dynamics dominate.
Six: Trust is the essential ingredient for empowerment, autonomy, experimentation and improvement. Transformational leaders do not need to have all the answers and are comfortable displaying vulnerability. This builds healthy, trusting relationships (at home and at work)!
Seven: Transformational leaders are excellent enablers of others, communicators, networkers, connectors and influencers, key for DevOps.
Eight: Transformational leadership can be learned and enhanced through coaching, responding to targeted feedback from being empathetic to the end-users, the customer and people experiencing the change.
Nine: How an organisation is structured will have tremendous desirable as well as undesirable effects on the software produced / service delivered, on the architecture and business outcomes. Autonomy and collaboration are wholly interdependent with structure.
Ten: Ensuring teams are kept small enough to share two pizzas (applying Amazon’s famed ‘two-pizza rule’ as it moved away from a monolithic code base in 2002), with people, process and technology working together; minimising bureaucratic change approvals and accelerating delivery. Many small teams working safely and independently for quickly delivering value to the customer are needed.
Over the years, DevOps advocates have become more heavily focused on the people elements of change. Ian Head, Research Director at consultancy firm Gartner states:
“We estimate that, by 2018, 90% of organisations attempting to use DevOps without specifically addressing their cultural foundations will fail.”
“Changing the behaviours and culture are fundamental to the success of a bimodal IT approach.. ”
Part III will complete this ‘How to Avoid Being Viewed as the Smiling Assassin’ series, sharing how we work with customers to transition to new digital ‘operating models’, to more effectively demonstrate a congruent leadership style and create the culture.
Key points will include:
-What can other organisations learn from the Tech Giants?
-How can organisations apply value-based systems thinking to deliver the right outcomes?
-What gets measured gets managed .. but to what effect? What are some of the key metrics for optimal delivery and how can you avoid the pitfalls associated with measuring performance?
Learn how Automation Logic assesses People, Process and Technical organisational capability, using our structured approach and simple to administer Diagnostic Tool.
We work with our clients to de-risk and accelerate their business goals realisation. Our approach is based on tailoring our services to fit your needs leveraging our portfolio of strategy, execution, innovation and service delivery offerings to help you reach your objectives
We’re always on the lookout for exceptional talent and people who share our values. Even as we continue to grow, we maintain a family environment with respect and teamwork core to our culture.
