Stephen Walters, Business Consultant, Hewlett Packard Enterprise, breaks down the importance of culture during IT transformation.

Is there anything that can stir emotions or debate more than “culture”? Well, the discussions were certainly lively at the DevOps Focus Groups during the “Culture eats strategy for breakfast” roundtable, but they were also positive and constructive.
There was an excellent mix at the October 2016 event, with IT professionals at all levels of seniority, multiple disciplines, covering Development, Operations and all areas around and in-between. The topic may have been based on the Peter Drucker quote of “Culture eats strategy for breakfast”, but something that became clear is that culture likes a varied, and sometimes contentious, menu.

As we reviewed what was discussed at the roundtable, certain key things came to the fore. They could be broken down into: challenges and solutions, outstanding questions, and statements of fact, and general observations.

Challenges and solutions

There was much discussion around the challenges that were faced by those who were about to undergo a DevOps transformation, or who were in the process of one. Thanks to the breadth of experience in the room, everyone learnt at least one thing new, but it also showed that there was never one simple answer to the cultural challenge.

For example, one particular point that was hotly debated was around team formation and specialism. For some, the goal was to have teams that could cover all roles and be in a position where, regardless of the required task, everyone in a DevOps team could handle the work. However, for others it was about forming a team made from a broad range of specialists. This way, there would always be expertise at hand, but it would require a greater amount of sharing workload between the team members.

A third, middle-ground option was to ensure that team members were mentored to have at least a base level of knowledge across the broad set of skills that provided core support and where specialism was required, certain members of the team could be called upon.

The consensus in the end was that the formation of the team would be down to the cultural set up of the organisation in question.

So although the challenges may have been common across those present, the solutions were multiple and varied according to the culture of the organisation. This underpinned the idea that in order for any strategy to exist, the culture had to be clearly understood and utilised.

Outstanding questions

Yet, for all the challenges for which there were options, there were still some outstanding issues. Examples were, supporting a bi-modal IT framework, where some teams operate agile, and others waterfall. How can the two operate together where systems are integrated? Who owns changing the culture, especially when “Us and Them” barriers can exist in an organisation? At least on that latter point, although there was no solution offered, it was agreed that an approach would be to identify a DevOps champion, and that it was often beneficial to use an external third party to fulfil that role.

The use of a third party can be beneficial in ensuring that there is an unbiased opinion, and one that is offered from a point of view of expertise. However, the third party must not dictate the terms of any change, but must operate according to the desired „ behaviour of the organisation. In other words, a third party must work according to the client organisation’s cultural goals, and not its own.

Statements and observations

Defining success was widely discussed during the roundtable at the DevOps Focus Groups. To achieve it, you must introduce accountability, scale up to DevOps, and then measure and ensure feedback loops are in place.

In scaling up, the transformation must be targeted enterprise wide, encompassing all, with a view to removing siloes, and should be viewed as a journey. It is key to remember that collaboration is not just about working together, but targeting the same goals, the endpoint for the journey.

Changing the culture must be paramount and considered first over enabling tools. Automation must not be ignored, but the tools must service the process and the people, not the other way around. Tooling is a key part of both culture and strategy, however, the difference is that strategy is about how you do something, and culture is about why you do it. Any transformation should be driven from why a business seeks to make the change.

To ensure that the transformation is meeting the business needs, i.e., answering the question of “why change?”, it is important to have the correct measures in place. Key examples for measuring success were customer satisfaction or speed to market, but these are defined according to what is of greatest value to the business.

Feedback is key. Without it, there is no way to determine if there is true collaboration, or that siloes are being broken down. Do it early, get everyone involved, be clear on the information provided and don’t forget to say thank you.

Conclusion

Culture and strategy go hand in hand with each other. Without culture, a strategy cannot be executed successfully. Without strategy, culture can be conflicting and destructive.

However, in performing any transformation, the key question to ask should be “why?”. Without a reason to transform, all we are doing is implementing tools. The tools, and those using them, must have a purpose, and that purpose is driven from the values of the business. The trick is to understand it, because every organisation’s culture is unique.

Edited for web by Jordan Platt.