Our Blog

GET INFORMED

Intrinsically Motivated Teams

September 29, 2017

I recently emerged myself into the world of Agile and Devops, and I can say with confidence that this is wave that is not going to go away soon. Yes, there will be people (companies) that try and fail – mostly because they don’t embrace it in its entirety – however I don’t see this as “just another fad”. In fact companies cannot afford NOT TO embrace it.

However this is not an article for those specifically wanting to embrace Agile, but rather to share with other ITIL enthusiasts what I learnt from the DevOps world that I think has sadly been missed in the ITIL operations world. Although to be honest it is spoken about in the ITIL books (and the last couple of slides on the foundation course – but who remembers that anyway!).

In fact, the concepts I want to highlight is not even DevOps per say, but rather something that the DevOps world borrowed from a guy called Daniel Pink, who published a book called Drive. In this book, he speaks about three key aspects that can motivate teams to do their best – Autonomy, Mastery and Purpose. You see in the DevOps world, we try to set up teams that are intrinsically motivated to provide quality, so hence these concepts become important. However, surely you need intrinsically motivated teams within support and infrastructure as well!!

So let’s take a look at how these three concepts can be embraced more into the ITIL Operations’ world.

Autonomy – The need of people to have control over what they do, when they do it, who they do it with, and how they do it.

The thought of it may scare you initially, as surely this is why you have processes and policies? However, the reality is that people thrive when given autonomy, and please know autonomy doesn’t mean free reign, it simply means providing experts the space to do what they know best. How about relooking at your Change Management process and see where you can implement more standard changes? Are there any changes where the risk is known and the procedure to implement is defined? If yes, then by all means add it to the list. Remember when we first started change management the environment looked very different and the risks were perhaps more pronounced. It is time to relook at your change management policies and see where more autonomy can be given.

Mastery – The desire of people to become good at specific tasks. This mindset requires dedication and hard work but also a place to learn and practice.

Yes, we have introduced Standard Operating Procedures to do tasks and we have insisted that technical resources don’t deviate from the norm, and this is good. It introduced standardisation, which brings in predictability, which brings in better quality. However, it could also produce robot type technical resources that are no longer interested in really being good at what they are doing. Where can we provide our technical resources and “playground” to learn and test?

Another one that gets tricky is the optimum resources utilisation of our support staff. We expect our first and second level engineers to be running at optimum levels ALL the time. Leaving no space for learning and exploring, never mind external training. Perhaps we need to consciously allow more room in their schedules for self-mastery in the skill of their choice.

Purpose – People are motivated by the fact that they are doing a task for a reason. Often even a selfless reason. When last was business impact spoken about in the support environment? Yes, we fix things when they break, but do we really know WHY the business needs it in the first place? Technical resources on the Service Desk and desktop support and even our infrastructure senior technical resources often become very divorced from the business, and it’s time that is changed. Allow more purpose to come into the support environment by talking about business impact, and even better introducing technical resources to the business – its purpose and challenges.

It is time we created intrinsically motivated teams within the operations environment as well. Yes, we need processes, and policies are always good to ensure structure and standardised performance, but it is time we look again at what we are trying to achieve with them. They are meant to bring in structure not stifle resources. Ever heard the saying “Happy staff, Happy customers”?