Part 1: How to avoid being viewed as the ‘Smiling Assassin’ but get your people ready for DevOps

By Joanne Milne, Senior Business Change Manager

– The realities and risks of analysing readiness for DevOps 

– How to future-proof the culture for DevOps

For the introduction to this piece, please click here.

Part I

In the first of this three-part series, I will be exploring where DevOps originated, taking a quick tour through the history of business organisation evolution in relation to this relatively new practice. I will explore how revolutionary this practice is and consider the origins of some of the challenges .. including the fear of the smiling assassin!

A DevOps definition

I’ve heard DevOps described in many different ways, something always quite telling in itself. So even at this early stage, this article’s likely triggering some debate… 

DevOps is an organisational design, heavily dependent on Agile and Lean management practice and a generatively learning mindset and culture. 

When successful, DevOps fosters high cross-functional, business collaboration with software development, IT operations, Security, Testing and Quality Assurance. Its main benefit is in delivering software reliably, in a rapid, continuous and stable manner. A particular feature of DevOps is an aspiration to automate manual processes wherever possible.

There are many instances, however, when the organisation is so far removed from this aspiration and definition that professional change management and transformational change expertise is recognised as necessary .. and our involvement is often required to support that. 

It isn’t the technology that proves difficult to change, rather the people, the culture and their ability to behave in ways conducive to DevOps.   

So where does the fear of the smiling assassin come from?

The origins of historic and ongoing tensions lie, I believe, between the opposing theories underpinning more traditional bureaucracies, with a high dependence on process and command and control hierarchical protocols that are slow-to-change versus DevOps with high empowerment, predominance of people over process, a flatter knowledge-led hierarchy, and continual learning for innovation and improvement that is able to adapt and change rapidly. 

These differences will be inspected in this series, to offer an explanation of the fear of the ‘smiling assassin’. Only through understanding the reasons for the fears will we be able to allay them. This will illustrate in fact, that these tensions have always existed, dating back to the very beginnings of the industrial age.

We must also consider the change manager role from all perspectives – a smiling assassin at one end of the spectrum and a trusted, person-centred organisational coach or counsellor at the other. As a business performance improvement consultant as well as a person-centred psychotherapist, I have always considered myself in the latter category, but there is also some real and unhappy justification for the former’s existence in the minds of the workforce. It is important to understand the ‘emotional baggage’ that change usually triggers, often, in part, due to this. 

Looking back through time is useful for knowing how legacy beliefs and so culture will exert huge control over the organisation. Understanding this legacy will help any change manager to put tensions they may be observing in attempting DevOps, into this broader and more complex context. 

These conflicts and tensions usually show up as resistance to change and cognitive dissonance, which manifests as stress, anger, fear and so resistance or even burnout and loss of valuable talent. 

If DevOps is to succeed, this potential for resistance and loss of talent cannot be ignored. Resistance must be carefully change-managed.

And lastly, gaining an understanding of where your organisation is today in relation to the ideal DevOps ‘state’ is often achieved during the earliest phase of change management by way of conducting a current state versus desired future state assessment. This is an important first step and doing so should provide an understanding of your culture and so its likely influences on this future state. 

Here at Automation Logic in the Transformation Practice, we do this in the form of a structured DevOps diagnostic instrument accompanied by experienced culture-change listening, observing, measuring, targeted interviews and focus groups / end user groups, and a period of shadowing the usual organisational routines, similar to ‘walking the Gemba’. 

In this Part I,  I will be reviewing the history of change, the origins of the smiling assassin and general resistances towards and fears of change in relation to DevOps and digital transformation. 

Most people reading this will admit to having observed many times over, and possibly with some disillusionment even, humanity’s all-too-frequent failure to learn from history. 

So what have we learned? 

What do we already know? 

New technology is usually accompanied by a human, behavioural ‘culture lag’

It’s often tempting to assume, in the new age of rapid, digitally-enabled information and automation, that we have overcome the trickier human factors and cultural issues that have tripped up the best of intentions over time. But is this true? In my experience and anyone who has attempted digital transformation, no it is not …

We should not forget that there will be the cultural lag between rapid technological advances and the slower-to-change human values, beliefs and ideals. It took 50 years after the typewriter had been invented for it to become a tool in the office and a similar lag was true for computers. 

Although the lag between innovation and uptake is shortening, it still exists. And in some instances, technology has simply failed to take hold due to this.

As mentioned in the earlier introduction,

 70% of change programmes fail to deliver expected value

and as exposed in 2019, from a 6000 respondent-strong survey by the Institute for Corporate Productivity (i4cp), 

only 15% of organisations employing more than 1,000 people rated their efforts at culture change as ‘highly’ or ‘very highly’ successful

It is evident that this ‘cultural lag’, rather than issues with the technologies themselves, continues to slow down digital transformation.

So now, let’s take a brief journey through time to understand what impedes change and transitioning to DevOps .. and feeds this perception of the smiling assassin.

Scientific Management

It is a commonly-held view that the theory of management began with the Scientific Management movement, with these theories about managing people championed by Frederick W. Taylor in the early part of the 20th century. This movement involved Time & Motion studies introduced by Gilbreth to ascertain productivity potential, supporting mass production assembly line organisation, with focus on greater efficiency through measuring the time workers needed to conduct tasks. This idea of measuring productivity and capacity is something that is now pretty much ubiquitous. 

Time and motion studies proved problematic, even at an early stage, with US Government workers walking out in protest in 1911. US congressional hearings that followed resulted in a ban of time studies and performance-related pay for Government workers. 

It seems that the smiling assassin made their first appearance around this time.

Scientific Management involved a ‘command and control’, ‘reward and penalise’ style of leading and managing people, and was typically structured around a hierarchical and bureaucratic organisation, with clearly delineated functions and roles. 

Taylor observed that worker motivation, even in more skilled workers, was generally low with most working at a level only marginally above that of incurring punishment. It is now generally accepted that this way of managing and structuring creates a self-fulfilling prophecy in terms of worker satisfaction and thereby worker motivation and productivity. 

In this dynamic between manager and worker, trust was low, and so workers’ Trade Unions often viewed business performance analysis as a tool to increase the pace of productivity at the expense of jobs, with managers demanding ever-cheaper labour with ever-faster machines. The theory-in-use about people was (and in many instances still is) that the majority of workers need to follow orders rather than understand the purpose, vision, values and bigger business goals or objectives. 

But there’s a downside..

The downside of functionally siloed organisations like this one however is that it creates what those in DevOps circles refer to as the ‘walls of confusion’ i.e. conflicting objectives that create siloed practice, impeding communication, collaboration, productivity and innovation; or in systems thinking terminology, ‘accidental adversaries’.

In software development, it is acknowledged that developers will typically aim to deliver changes fast, however operations will prioritise stability and reliability, resulting in conflicting objectives that create the ‘walls of confusion’, usually between development and operations. 

Systems Thinking is one of the core capabilities of DevOps, that acknowledges the need to think beyond functional boundaries and accept that problems are rarely as a result of clear and linear, cause and effect relationships.  We will come back to Systems Thinking in more detail, in terms of origins and influences on DevOps, later in Part II.

GE Workout, Jack Welch (1980s)

This understanding of the costs and pains of functional silos is not new, nor emerged solely from DevOps. In the 1980s, the CEO of General Electric, Jack Welch, strove to create the ‘boundaryless organisation’ in a process that became known as GE Work-out. This required teams to be empowered to quickly make knowledge-based decisions, referred to in DevOps circles today as ‘self-organising teams’.

Scientific thinking management is by no means dead however. In 2019, it was evidenced in Amazon warehouses. Newspapers reported that workers’ toilet breaks were being timed, people’s productivity measured by units processed and some people fired thanks to an algorithm. The work was reportedly physically demanding, repetitive with little meaning or intrinsic reward. It seems that human motivation depended majorly on simply earning money.

When Psychologists in the 1960s studied car manufacturing workers on assembly lines at the Luton (Bedford), Vauxhall car manufacturing plant (UK), they observed this impoverished motivation, referring to it as workers possessing an ‘instrumental attitude’ to work i.e. workers produce just enough to get paid and sought any intrinsic, personal reward outside of office hours. 

When an instrumental attitude is in evidence, we can predict that it will grossly impede motivation and so productivity and innovation. 

Needless to say, DevOps will fail in this environment!

In organising for DevOps, it is acknowledged that creating an understanding of the values, the business goals and desired outcomes is critical for people becoming more engaged in achieving those outcomes. Removing or reducing functional ‘walls’ and barriers and sharing the vision, purpose, values and bigger goals also builds trust. People who trust, collaborate and communicate more readily are naturally far more enabled to deliver the service or product. With simply a drive for greater automation without doing this, the reasons for fearing the smiling assassins are clear.  

A stand-alone drive to automate will easily evoke fear.

A few years ago, Automation Logic were asked to undertake an engagement to improve performance in software delivery where headcount reduction was the stated organisational objective. We declined and needless to say the initiative did not end well …

.. with the fear of the smiling assassin there is going to be at least a perception that the organisation is using DevOps transformation as a means to cut headcount.

If you are a leader or manager instituting DevOps or further automation, you will eventually recognise that there is a high likelihood that fears such as this, and many others, will become a key blocker of change, at least for parts of your workforce. 

As a result of a 2017 Enterprise DevOps Survey, consultancy firm Gartner predicts that through 2022, 75% of DevOps initiatives will fail to meet expectations due to issues around organisational learning and change. 

“Organizational learning and change are key to allowing DevOps to flourish. In other words, people-related factors tend to be the greatest challenges — not technology.”

In general terms, it is fair to say that fear and resistance to change are far bigger contributors to digital transformation failure than issues with the technologies themselves. 

Introducing the idea of Psychological Safety

Another critical factor of successful DevOps requires building what is often referred to as ‘psychological safety’ as highlighted in sociologist Ron Westrum’s culture typologies. The culture typology identified as needed for DevOps is a Generative Culture. This has been proven in observing the impacts of culture on safety in Aviation, Medical practice, Nuclear Power and Oil and Gas sectors. Cultural impacts will be explained in more depth later on in this series, with cultural attributes recommended for DevOps covered in Part II.  

Experiencing psychological safety means people feel ok about highlighting problems or inefficiencies wherever they may lie, and more readily admit to not knowing, making mistakes and failures. In DevOps terms, this promotes an ability to ‘fail forwards, fail fast’ i.e. readily learning from what went wrong and so able to more quickly innovate or pivot. An industrial espionage anecdote tells of a leading car manufacturer’s designs being stolen by a competitor. The affected manufacturer was largely unconcerned however, safe in the knowledge that the designs would likely further change, and whoever had stolen them would not benefit from the learnings gained from the failures that had led to that point. 

In driving for change applying solely Scientific Management principles however, we can conclude that fears usually magnify and manifest, perpetuated by a typical manager’s lack of empathy, reduced understanding of how changes will be perceived by people, and an unwillingness to admit failure. Communication tends to be delivered using a telling rather than engaging style, also minimising overall buy-in and uptake.

To any organisation wishing to simply pilot DevOps – consider the following… 

… Creating a siloed approach to DevOps in an otherwise bureaucratic organisation usually fails to deliver lasting results due to this lack of overarching culture and feeling of psychological safety. Those who have attempted this report on a ‘DevOps silo’ forming. In this scenario, DevOps starts as a pilot program. A DevOps team is formed to learn the new tools and technologies and then begin implementation. Without the ability to scale, gain organisational support and little-to-no real organisational transformation, the DevOps cohort become their own silo, protecting themselves from the wider circle who they view as incapable of understanding this way of working, largely unsupportive and so to be avoided at all cost.

Thus, another silo is born!

Scientific Management still shows up regularly, as highlighted in the earlier Amazon warehouse example, and is often at the heart of industrial disputes. In many instances, this has involved Trade Unions opposing the Government or executive boards; some of the more notable examples here in the UK being: 

– Thatcher-era mining ‘pit’ closures 

– British Airways and RyanAir pilot conditions and pay disputes

– Southern Rail strikes due to role restructuring

– Public sector: NHS, Fire & Teacher conditions and pay disputes

As discussed already, achieving success from DevOps relies on an entirely different approach to this adversarial and polarising, ‘them-and-us’ dynamic. Even now however, leadership and management style is often underestimated as some kind of fad of offering a ‘softer’ approach.

Transformational leadership and an empowering and engaging management style is critical for establishing psychological safety and ultimately ensuring organisational survival in the digital workplace.

This will be covered further during Part II. 

The ‘fad’ of empowerment, continual learning, adaptation and innovation

At the same time as the advent of Scientific Management, Mary Parker Follett was a management theorist and consultant whose ideals matched much more closely those of the more adaptive, continually ‘learning organisation’ that is the bedrock of DevOps. 

In the early 1900s, Follett observed that matrix organisations were necessary to share expertise, ideals that were then adopted by Du Pont in the 1920s and then institutionalised by them in terms of recognising the cultural traits impacting for better or worse on organisational safety culture. 

Follett was also an observer of people’s behaviour as a community Social Worker and quite the reverse of a smiling assassin, becoming a person-centred management consultant. Through her work she noticed the holistic nature of communities whereby integration was more powerful than the power that any  individual could exert over them. She referred to that as the ‘power within’ rather than ‘power over’. This has now become key for appreciating the impacts to be achieved from transformational leadership as opposed to more traditional and transactional leadership (to be discussed more in Part II).

She was a prolific writer of politics, management and philosophy and was selected as the US President’s management consultant adviser for nongovernmental and voluntary organisations. She was also a pioneer in the establishment of community centers. History has not well-remembered her however with women in business notably struggling to achieve the same credibility and credit as their male peers. 

Since then till now, these views have grown in credibility but it has taken over 100 years! This has happened also thanks to promotion by Quality Management movement and consultants Shewart, Juran and Deming; the learning organisation writers, academics and consultants, Schein, Lewin, Argyris, Schön, Kotter and Senge; and of course the proponents of DevOps, who stand on the shoulders of all these giants: Belgian consultant Patrick Debois introduced DevOps in 2009; followed by Gene Kim, Jez Humble, and many others.  This will be covered in more detail in Parts II and III.

To be successful, DevOps depends on a more dynamic, person-centred ‘learning organisation’ and transformational leadership and management style. 

Promoting the right capabilities and interactions

Central to Follett’s writings from the early 1900s, and to DevOps now, is an emphasis on recognising the importance of informal processes within organisations, and the idea of the ‘authority of expertise’, both critical aspects of DevOps culture, in creating a learning and continually evolving organisation. Follett recognised the need to enable the right people to make the right decisions at the right time. 

With hierarchical divisions and poor trust between worker and manager however, this empowerment has proven to be problematic. Fostering empowerment and learning is something that many businesses and managers still struggle with. 

Across the DevOps movement there is unanimity in the predominance of people and interactions over process. This a mindset and practice that bureaucracies struggle to embrace. 

The importance of the ‘Hawthorne Effect’, George Elton Mayo and others during the 1920s and 1930s

In considering the DevOps movement, it’s important to talk about what happened during the 1920s at the Western Electric Company’s major Hawthorne Plant in Cicero, a suburb of Chicago, USA.  

Further to Follett’s earlier work, Professor George Elton Mayo, a social scientist from Harvard Business Administration, first observed the often-cited ‘Hawthorne Effect’, specifically that people respond positively to being involved in how to perform their work more effectively, that job satisfaction increased through employee participation in decisions rather than through short-term incentives. 

The Hawthorne Effect itself is often summarised in terms of how people alter their behaviour when they know they are being observed but Mayo’s work demonstrated also that increased satisfaction was as much about involving people in making decisions about how work could be improved. 

As a social scientist, Mayo observed the positive impacts on productivity from increasing rest pauses and making basic working condition improvements such as providing better lighting. In undertaking a digital transformation in the Public Sector, a Director colleague uses the example of improving the conditions of bathrooms (rest rooms) in the workplace before attempting digital transformation. 

Mayo’s work is widely credited as leading to the Human Relations movement (and so HR functions) and a growing awareness of the importance of organisational culture. This movement began by altering how teams were managed and early on this was led by social scientists experimenting to further enhance productivity. 

As noted by Follett earlier, this led to a greater acknowledgement of the dominance of informal interactions over formal processes and procedures; that in the face of strict rules and procedures, informal approaches and groups will make decisions based on emotions, opinions, problems and tellingly, but rather unsurprisingly, social interactions. 

I have noticed that Managers who are guided by the Scientific Management principles typically favour systematisation, standardisation and documenting the ways of working over engaging people in thinking and behaving differently across a complex system, one too complex to accurately predict, the latter requiring Systems Thinking mindsets and capabilities. Manager-preferences on where to focus first to begin improving are usually a dead giveaway to the management style and a good indicator of the organisation’s preferred theory-in-use. 

Mayo’s work noted that in improving productivity, managers needed to become more person-centred, with an ability to relate to people, empathise, counsel, communicate and lead. This has also been a key element to be improved on through improving a safety culture in higher risk industries such as aviation, nuclear power, oil and gas and the health sector. It is a key ingredient of successful DevOps teams and organisations. 

Theory X and Theory Y, Douglas McGregor (1950s, 1960s)

Douglas McGregor, another social scientist, produced Theory X and Theory Y as two opposing theories about managing people in the workplace, to illustrate the need for managers to apply a more effective theory in seeking to motivate their workforce. McGregor argued that this was Theory Y. 

He proposed that two opposing management styles would evoke quite different worker responses. Theory X he proposed was a ‘hard’ approach, reliant on close supervision, intimidation, and immediate punishment (applying motivational forces external to the individual), with managers quite untrusting of workers’ ability to work autonomously. He proposed that this style evoked unhelpful ‘them-and-us’ divisions that yielded reduced workforce cooperation and so grossly hindered performance. 

Theory Y he proposed as a ‘softer’ approach, one determined by intrinsic motivation (something to be tapped into, that exists within the individual, potentially lying dormant in a Theory X environment). He proposed that workers should be encouraged to work without direct supervision, with the added reward of greater job satisfaction. This, he proposed, could yield far superior results, resulting in far less conflict and resistance. 

He also warned however that too ‘soft’ an approach could result in an entitled, low-output workforce. So, in his view, a tension was required between the need to deliver coupled with a Theory Y managerial style for delivering the best results. 

Theory Z, Abraham Maslow, (1960s)

Further to McGregor’s Theory X and Theory Y, humanistic psychologist Abraham Maslow proposed Theory Z that stated in adopting a different managerial style, this would help cultivate worker creativity, insight, meaning and moral as well as work-related excellence, which he referred to as ‘self-transcendence’.  Self-transcendence can best be understood in terms of imagining the ‘starving artist’ who values self-transcendence above all material values. This resulted thanks to MacGregor’s Theory X and Y and Maslow added self-transcendence as an additional dimension to his pyramid of hierarchy of needs which previously placed self-actualisation at the top, describing individuals seeking to attain material success at the pinnacle. 

In the world of IT, this might be a ‘White Hat Hacker’, i.e. a computer security specialist who voluntarily breaks into protected systems and networks to test and assess their security; using their skills to improve security by exposing vulnerabilities before malicious hackers (‘Black Hat Hackers’) can detect and exploit them. 

Steve Wozniak, Apple’s original co founder with Steve Jobs, and pioneer of the personal computer revolution, appears to fit the description of someone naturally motivated by self-transcendence. 

As we can see from the description below, he appears to possess quite different personality traits to those seeking to meet any of Maslow’s original pyramid’s needs (from basic to self-actualisation); motivated by quite different achievements. It is widely acknowledged that he was motivated very differently to Steve Jobs, and chose a different life-path as a result:

Steve Wozniak has a compelling sense of himself as a spiritual being who is the searcher and the seeker of truth. That said, Woz’s life is devoted to investigations into the unknown, and finding the answers to the mysteries of life. Monumental as it is, Wozniak is well-equipped to handle his mission. He enjoys a fine mind, and is an analytical thinker, capable of great concentration and theoretical insight. Steve Wozniak enjoys research, and putting the pieces of an intellectual puzzle together, and once he has enough pieces in place, Woz is capable of highly creative insight and practical solutions to problems.

Steve Wozniak enjoys his solitude and prefers to work alone. He needs time to contemplate his ideas without the intrusion of other people’s thoughts. He is a lone wolf and a person who lives by his own ideas and methods. As a result, close associations are difficult for Woz to form and keep, especially marriage. Wozniak needs his space and privacy, which, when violated, can cause him great frustration and irritation.

It seems to me that there is a cohort of ‘highly self-directed’ Technical Architects, Software Developers and operations people who could more naturally fall into a category of being motivated similarly. This cohort potentially derives joy more from achievements such as breaking new ground, solving problems, being true to their beliefs of what matters most to them, more than more money, perks, esteem of colleagues, status, etcetera. Producing ‘beautiful’ architecture and code, for instance, may be key to their feeling satisfied and a key behavioural driver. 

Side anecdote – early on, as a student, Wozniak was reportedly expelled for hacking into the university’s computer system and sending prank messages on it. 

Sharing the bigger purpose is key in DevOps but especially so for this group; and, it is safe to say, that Theory X managers would have a disastrously undesirable effect! 

How many people do you know like that? 

How can you identify the likely different motivational drivers in a team? 

What style of leadership and management does it take to tap into this and engage everyone in the organisation’s purpose?

These are questions that every transformational leader and people manager must be able to answer.

The Quality Movement: Kaizen, Lean and Six Sigma (1950s till now)

Further work has been undertaken to improve production lines and mass production performance, particularly in Japan. This is often referred to as Kaizen (Japanese for Continuous Improvement) and ‘Lean Six Sigma’. 

Dr. William Ouchi proposed a Japanese Management approach, one that was popularised during the Asian economic boom of the 1980s, also calling this ‘Theory Z’. He proposed that organisations must promote stable employment and security, which would then lead to higher productivity, employee morale and satisfaction. He wrote about this in his book ‘Theory Z: How American Business Can Meet the Japanese Challenge’ (1981). 

Kaizen, the foundation for all Quality Management practice, can be traced back to the American Quality Management Consultant, William Edwards Deming who consulted with the Japanese in the 1950s and ‘60s, and delivered the mantra for organisations to ‘drive out fear’ to eliminate defects, reduce variability, enhance productivity and so competitiveness. This was at a time when Japan was only known for cheap and poor quality products. Although he was clearly a scientific management thinker, much of his work centred around this need to involve and more fully engage the hearts and minds of the workforce. 

In fact, Deming derived his understanding of how to manage variation from Walter Shewhart. 

Interesting side fact – at an earlier time in their careers, they were co-workers at the famous Western Electric Company, mentioned in the Hawthorne Effect example above, Deming having learned the Plan-Do-Check-Act cycle from Shewhart there – calling it the Shewhart Cycle.

He knew that a fearful and untrusting workforce would impede learning and innovation more than anything else. At its core, the Quality Movement, and Deming in particular advocated the principle of respect for people. One of the best ways to demonstrate respect for your employees is through involving them in any necessary improvements to their processes and ways of working. 

At its heart, DevOps success rests on demonstrating respect for people. 

Concluding comments for Part I .. what’s coming next in Part II..

History has shown a steady progression towards person-centred, organisational restructuring, leadership and management, with more focus on culture now than ever before. This is also clearly a realisation that dawned long before the advent of the digital era. 

It is interesting to witness that now, even with a greater push towards automation, there is an even greater reliance on devolved responsibility and flatter structures for more seamless people communication, collaboration and so enhanced delivery of value across the usual boundaries. 

The following 10 points are a quick recap of the main points that I have highlighted so far as important for DevOps, and for survival of the digital organisational today: 

1) Resistance to changing beliefs and behaviours, rather than issues with the technologies themselves, are still the largest contributors to digital transformation failure. 

2) It is evident that this ‘cultural lag’, rather than issues with the technologies themselves, continues to slow down digital transformation. 

3) When an instrumental attitude is evidenced in the workforce, we can predict that it will grossly impede motivation and so productivity and innovation. DevOps will fail in this environment!

4) Fears and feeling psychologically unsafe, particularly the fear of the smiling assassin, risks a perception that the organisation is using DevOps transformation as a means to cut headcount. Organisations will struggle to realise the benefits where these fears exist.

5) Transformational leadership and management style is critical for establishing psychological safety and ultimately ensuring organisational survival in the digital workplace.

6) Across the DevOps movement there is unanimity in the predominance of people and interactions over process. This a mindset and practice that bureaucracies will struggle to embrace. 

7) Functionally siloed organisations create what those in DevOps circles call the ‘walls of confusion’ i.e. conflicting objectives that create siloed practice, impeding communication, collaboration, productivity, improvement and innovation; or what systems thinkers often refer to as ‘accidental adversaries’. 

8) To be successful, DevOps depends on a more dynamic set of person-centred ‘learning organisation’ and Systems Thinking mindsets and capabilities. 

9) Sharing the organisation’s bigger purpose is key in DevOps.

10) At its heart, DevOps success rests on a value of respect for people.

In Part II I will examine the particular challenges faced when transitioning to DevOps and through examining  more closely the tech leaders in this field (FAANG), highlighting some of the key practices as well as the underpinning theories that are commonly understood as necessary to ‘be DevOps’ (highly agile, continuously improving, consistently innovation in value delivery).