Digitalisation. Six: Culture

Digitalisation in a Post-Covid19 World (6/6)

Previously in digitalisation...

Welcome to the sixth, and final article, in the series on Digitalisation and the Digital Maturity Model aimed at helping demystify an often-confusing realm for leaders, by translating technical terms from the argot of engineer-speak to logical constructs that help leaders navigate modern computing concepts.

The first article provided a backdrop as to why digitalisation will accelerate post-Covid19, set out the six aspects of the Digital Maturity Model, and covered the first of these, Cloud Platforms. The second article covered Cloud Native Applications, the third, DevOps and Site Reliability Engineering (SRE), the fourth provided insights into what Agile Delivery means and when to use it, and the fifth looked at the Operating Model. In this article, we’re going to look at Organisational Culture, the glue that helps cement the digital maturity model.

A Word to the wise

This series of articles has been aimed at helping leadership understand digitalisation. It is not aimed at understanding leadership per se, an important topic in and of itself that will be explored elsewhere. However, any discussion of culture necessarily touches on aspects of leadership, because leadership and culture exist in a symbiotic relationship, with both primarily being relationship driven.

Defining Culture

A definitive answer to the question of what culture is seems elusive, if not illusive. It’s a question asked about organisations (political and otherwise) for centuries and answered in literally tons of ways. Its etymology is rooted in the Latin word colere, meaning to cultivate or grow. Often people talk about culture as manifestations of collective achievements (art, music, customs). Cultured people are said to be refined. So, where does it come from and what does it mean in the context of an organisation?

Culture comes from the informal rules and norms as well as formal rules set through the polity (page 19 in the linked document). Either may be inherited or planned, and, in this way, culture accretes into a thing that can feel intangible. But is it? Intangible?

A thing that arises from formal and informal rules and norms, and manifests as an ever-changing set of recognised collective achievements is nothing more than the reified collapsed wave function of relationships with each other, our environment, and technology. The observant reader will recognise this as a nod to the Heisenberg Uncertainty Principle; that part of quantum mechanical theory that states the position and the velocity of an object cannot both be measured exactly, at the same time. Whilst the validity of this theory is not in doubt, it doesn’t provide the hapless motorist with a defence to a camera-based speeding ticket because the police can make an accurate enough determination measuring two or more points in space and calculating the missing information, speed. Interestingly, the speeding motorist also has potential to impact a number of things: people (passenger angst, danger to those outside the vehicle), environment (higher rates of pollution, noise), and technology (faster wear on the car and the road itself).

Symbiosis

Culture, then, is the symbiotic relationship between people, environment, and technology; the glue for those aspects of digitalisation discussed previously in this series and, thus, it occupies the middle of the picture, because it touches and is touched by everything.

Cultures evolve in tandem with those other aspects. Resistance to the evolution of either is a serious threat to the success of a digitalisation project because old value systems may be inadequate to cope with new ways of working and new tools.

Top Down

Change initiatives require buy-in from the very top of the organisation in order to be successful. After all, what value is there attached to following a path that doesn’t have the blessing of the leadership team? And how do you know what has the blessing of the higher echelons of the organisation?

We all look to authority to guide us, whether in times of relative calm or times of change. We want to know that what we’re doing is important, has validity, that we’re not veering off path or off message. This is why communication from leadership is so important. Lip service won’t do, because if leaders don’t walk the walk, if they don’t broadcast and reinforce the message, it atrophies exponentially as it traverses the lower rungs of the organisation until all that’s left is the residue of an idea that some people think is quite neat, but will never be applied “around here”.

Cultural catch-up

Public Cloud enables the fast development and delivery of software engineering products from a technology perspective through the platforms and the native applications it provides. Agile working practices allow faster development of solutions that provide value to the business and the customer through constant (re)prioritisation and the fail-fast philosophy that allows us to pivot and course correct without the bureaucratic processes that can slow down Waterfall deliveries.

Why, then, is application delivery still such a slow process in so many organisations? Why aren’t delivery rates even faster than currently?

One of the main reasons is that culture hasn’t evolved to keep pace with available technology. Bureaucratic rules, originally introduced for valid reasons, are no longer fit for purpose as they provide blockers to the flow of work, whilst too often executive hide behind the ignorance of others, often stating opinion as fact or repeating what they think their counterparts want to hear. It takes courage to break with the pack even if doing so is of benefit to the organisation.

Myth Busting

It’s time to do some myth-busting. Refuting each of the myths below and, instead, replacing the, with clear rationale, has a positive impact on culture. This, in turn, boosts productivity.

Myth 1: Public Cloud is insecure

On 19 July 2019, Capital One, suffered a security breach of its AWS ecosystem. The reasons have been documented extensively elsewhere, but in summary it was human error. Within hours of the breach executives at many banks sat in meetings and congratulated themselves loudly for either not being in the Cloud or not using AWS – the. breach was the fault of neither.

By failing to discover the true reasons and instead broadcasting what was effectively fake news, executives provided staff with the message that, in their opinion, Cloud was inherently unsafe, even though this is demonstrably true (a quick look at the blog of any well-respected Cybersecurity firm will throw up articles about Cloud and non-Cloud security threats, and tips of how to avoid the pitfalls). Many people lower down the corporate hierarchy, without direct experience of Public Cloud, took this as gospel. Thus, the communications of the executives, based on syllogistic reasoning, made it harder for the organisation to derive value from its executives and its teams and held up progression of the corporate culture.

Myth 2: Releasing imperfect code is dangerous

Here, I’m not talking about insecure code, but code where not all of the features requested in a Sprint have been delivered. Consider the case of a Project Manager who blocks the release of code at the end of a Sprint because one of the requirements wasn’t completed. The unfinished requirement is pushed into the next Sprint, but the PM states the output from both must be implemented at the same time.

It’s not uncommon, especially in the early days of a Project, for some requirements to be missed as the team calibrates its delivery capabilities and its ability to work together (Bruce Tuckman’s Forming, Norming, Storming, Performing model). The same thing then happens at the end of the second Sprint – the original missed requirement is delivered, but something from the second Sprint is missed. This often occurs because the PM refuses to allow the content of a Sprint to alter based on changing requirements or priorities.

As the situation compounds, delivery is continually deferred until, at some point, a crisis arises. The crisis is often blamed on Agile, but had the PM allowed prioritisation and release, no crisis would exist. Why did the PM behave in this way? In my experience this happens because the PM has no formal training in Agile (or has oversold their own credentials) so instead, mistakenly believes Agile is about doing work in two, or maybe, three-week stints (Sprints) and calling someone a Product Owner. This type of problem is generally fixed with a small amount of training, yet all too often organisations try to do Agile on the cheap by “saving” on training costs. This not only costs them in the aforementioned delay costs, but stifles the innovative culture that firms long for because team members become conditioned to a lack of progress being the norm whilst accusations mount as to who is to blame.

Myth 3: We must negotiate exclusive contracts with Cloud Platform Providers

In the old world of large systems provided by expensive suppliers, it often made sense to manage the costs of a contract by negotiating an exclusivity deal with the provider, in many cases spanning a number of years. But in Public Cloud, doing this stifles innovation because it restricts the available toolset. Worse, “legacy thinking” costs money because it allows unscrupulous salespeople to drive consumption models (Cloud is charged, and its salespeople commissioned, on a consumption basis). The monoculture pervades and the firm suffers the consequences. With free reign to use whatever tools the engineers think will best do the job, creativity is enhanced and the competitive negotiation position maintained because the providers know that you’re free to go elsewhere to satisfy your needs.

Myth 4: As a leader I should delegate attendance at meetings

Often leaders are busy. It’s a fact of life that leadership is, in part, a balancing act. It’s, therefore, tempting to delegate responsibility for attendance at meetings such as the Sprint demo / sign-off to others. In fact, there’s nothing wrong with the occasional b it of delegation, but all too frequently delegation turns into abdication and the leader fails to attend any of the meetings. Apart from sending the message that the leader doesn’t care (when perhaps they do), it presents missed opportunities for learning and communication.

When a leader is present, actively listening, and communicating, the workforce are able to understand how their performance is. They may ask for guidance, direction, help with prioritisation, for the leader to present a challenge function to their thinking. These are valuable not only because they can stop the team going off at a tangent earlier than might otherwise be the case, but because the leader becomes more connected to the team. The culture itself evolves through the symbiotic exchange of ideas and value – as well as trust – in relationships is created or enhanced.

Myth 5: Leadership is a command and Control paradigm

There are, undoubtedly times when command and control (do as I say, no questions) is the right thing to do. This is a classic (and correct) response to a Critical Problem. There isn’t time to devise a plan, so everyone springs into action. A great example of this was the lockdown for Covid19, where workers had to quickly ensure that colleagues could work from home.

Using a command and control approach at the right time is not only important, but will normally command the respect of the workforce. However, using the same approach when not called for (for instance for Tame or Wicked Problems) not only risks undermining respect at the individual level, but potentially at the level of organisational culture. This is because it breaches the trust in the relationship. Understanding when to delegate (true delegation, not abdication) and empower people to make their own decisions is a powerful tool in creating a cohesive organistional culture.

Myth 6: I lead, you Follow. Ergo, do what I say

A close cousin to Myth 5, this is really talking about the relationships between team members and leaders. The German philosopher Martin Buber wrote a book called I-Thou. It’s not the easiest read being a mix of philosophical poetry and prose, but it does provide a concept that is incredibly important for relationships (in any context). His idea was that there are two parts to a relationship. The first is I, that part of you that is you. The second is a choice but one that you choose to bring. It is either Thou (the archaic singular form of you) or It (as in the transactional).

When you select I-Thou it is not merely to offer a relationship, but, rather, to bring your authentic emotional self to the relationship in a presence that is the representation of the two parts. If, instead, you opt for I-It, you bring a transactional presence into the room, one that is bereft of emotion. This latter relationship is appropriate in some circumstances – if you’re paying for something at a shop you’ve never been to before, I-It may be the right relationship to bring. But if you only ever bring the transactional relationship into meetings, it sows the seed for a transaction-based team and, by extension, a transactional culture. But culture, like leadership, is not simply transactional (despite what some modern leaders may think). Good culture, like good leadership, requires good relationships.

Myth 7: We cannot influence Culture: it evolves

Of course, culture does evolve. Constantly. And this is necessary if organisations are to adapt to the world around them. But, hopefully, this article has given you enough information to conclude it can be influenced. Our actions, our words, and our ability to bring a presence into the room all impact on the culture of the organisation.

Continuous Improvement

Don’t worry if your existing culture needs some work. That’s far more normal than the other way round. Culture, like the wave functions of uncertainty, doesn’t have defined end state. It’s a distribution of behavioural probabilities over time, with probability levering up and down according to multiple factors in play at any one time. There is no stopping condition because the context in which a culture exists continually changes. But it is possible to introduce practices aimed at providing a ideal culture in the context of your organisation for digital maturity to flourish.

Cultural change, like technological change, isn’t achieved overnight. There may be resistance, a lot of it. You can’t overcome strong resistance with a click of the fingers. It may be necessary to negotiate the path to a new culture incrementally. Resistance can be ameliorated by the behaviours of leadership and the incremental introduction of new processes.

Tips for Achieving Cultural Change

In closing, I offer the following tips to help you start the journey towards a culture that enables digital transformation:

Be present in your team relationships. Bring I-Thou into the room. Attend demos and Sprint wrap-up meetings (or whatever similar functions you have);
Delegate, but never abdicate responsibility. Empower team members to make decisions. It’s rare that they will make a catastrophic one (indeed, I’ve yet to hear of it in the context of empowerment). Even if they do, most decisions can be course corrected. But people who feel unempowered will often watch as the car crash unfolds for fear of getting in trouble.
Remove blockers that prevent the engineers and other specialist members of the team from achieving their goals (your goals).
Engage with team members outside of meetings. Speak to them about their lives, their needs, their wants. Empathise with them.
Communicate goals and expectations frequently. People forget. It’s natural. Repeating the same message, in different situational contexts, breed familiarity (not contempt) and helps make the messages authentic.
Be prepared to pivot if things change. There’s nothing wrong with changing direction if you think that’s the right thing to do. Do it as early as possible (fail-fast).
Use coaching – for you and for your team. A different perspective helps people gain a grounded view of their own place in the team.
Send people on courses. It’s far cheaper in the long run to have resource who know what they’re doing that having them guess what the right thing to do is. Continual Professional Development has its roots in Freud and Jung – not bad people to take a leaf out of the book from.

And now...

We have come to the end of the series of articles on digitalisation and digital maturity. Space and time constraints mean there is much has not made it into the series that is worth coverings. Look out for other articles on leadership. In the meantime, you may want to check out some of these articles that are already available here:

If you’d like to discuss any of the concepts in this series or any of the other articles on our website, please do get in touch.

Additional Resources

Web Resources

Of course, we would love to engage with you on the leadership piece – helping leaders to navigate the complexity and set the goals and outcomes for those they engage – but, at StoryPositive, we’re not the engineers. We have worked with the following companies to provide successful outcomes on Agile-based Delivery. Here is a selection:

Adaptavis – A company focussed on Agile methods, efficiency, and the removal of Delay Costs
eSynergy Solutions – Delivering pre-formed software engineering teams and projects related to DevOps Transformation, Cloud Computing and Data Engineering.
Think Above Cloud – A firm focussed on delivering high-value change through Public Cloud engineering
Secure Delivery – Experts in Application Security Consulting, Training, and Assessment.

Before you Go...

If you’ve found this article informative, please consider sharing it with colleagues and others in your network.