How to infuse gamification into IT Organizations.

The term “coin-operated” usually refers to sales people, i.e. you put certain incentives in place and sales people quickly change their behavior. This conduct is core to their DNA, but it really is a human trait –  we all like to be rewarded.

So how come we don’t do that in other professions?

Well, first it is much easier to identify a deal and its clear monetary impact on the company, but it is harder to measure other functions and even harder to clearly identify the right behavior to incentivize. Measures such as CSAT in customer service or NPS for product teams are trying to abstract the value, but it is generally hard to individualize these metrics and thereby drive individual and daily behavioral changes.

Why would we want to do this for IT Ops teams?

We need a much higher level of end-to-end automation and we need it urgently so IT can absorb the growth in requests, tickets, changes, problems…and did I mention changes? Most IT departments continue to see growth in tickets and incidents and it is not likely to slow down with the advent of IoT (Internet of Things). A brute force approach with more staff is no longer a viable option, there simply is not enough skilled people.

None of this is new, yet we have seen little structural changes in the behavior of most IT departments. Employees get dragged into the day-to-day work, trying to keep everything up and running, and responding to the most urgent requests. Morale can take a hit, leading to attrition.

We need a catalyst for change and I believe the catalyst is to incentivize IT staff to literally automate their current job away.

Nobody likes to make themselves redundant, so the program has to be combined with a career path toward becoming a dev/ops or automation engineer, i.e. moving up the stack. Implementing an organizational change program with education, certifications, measurable milestones and incentives can successfully drive the behavioral changes needed for a highly responsive IT organization.

What is even more important is cementing a mentality of “Automation First” within the culture of the IT organization.

At IPsoft, we have seen this change and the associated results multiple times with our clients, but it is not a guarantee nor a quick change as these initiatives can become “false starts” as the organization and individuals slowly retreat into their old behavior.

How have we implemented this?

We have taken a multifaceted approach.

  • First, we have implemented “gamification” at a team (shift) level. The teams compete on a weekly basis across a multitude of SLAs, SLOs and MTTResolution. The winning team gets pizza and other “prizes” on a weekly basis.
  • Secondly, simple surveys are automatically sent out and results are incorporated into algorithms driving auto-assignments and bonuses. We’ve instituted these surveys ourselves and our response rate is an amazing 28% because they are simple and our customers and employees are aware that their opinion matters.
  • Lastly, we have been very open with our engineers that autonomics is the future. We have trained and certified every single of our more than 1,000 engineers in the art of writing automations. We have also changed the incentive-structure so they are now paid monthly bonuses based on the number of automations they create.

Lessons learned

Just like working out commissions plans with proper incentives for sales team is a learning experience, getting an autonomics conversion for IT organizations in place has resulted in lessons that we can pass along.

  • Pay for real change, not busy-work. We do not want to incentivize people for doing their work, i.e. it has to be something “beyond” which requires a change from their normal behavior. Peer review and validation of uniqueness was critical to get this right.
  • Technical change is simple, organizational change is not. As mentioned before, nobody wants to automate their way out of a job, so proper education and certification is vital to make employees comfortable with the changes. And don’t just pay lip-service to their concerns.
  • This is not scripting – there is an art to writing automations. Writing proper “virtual engineers” takes design thinking and experience. This is not acquired overnight or by taking a 3-day training course followed by a certification. Shadowing, lunch-n-learns and peer reviews have been key to creating new “artists”, but it is also important to note that not all engineers can make the transition to become “artists”.
  • Governance is key to avoiding “false starts”. Peter Drucker famously stated: If you can’t measure it, you can’t improve it. Metrics and KPIs rule the world of improvements, so define goals and monitor the progress constantly and be very wary of slipping back into day-to-day operational mode.

If you want to do something new – you have to stop doing something old

The above is another quote from Drucker. I previously wrote a blog on the future composition of IT where I get into the new roles and capabilities needed and which roles we should transition people away from. The world of IT Operations is rapidly changing due to Dev/Ops, Autonomics and AIOps. So, don’t be the last person manually restarting a service… we have virtual engineers for that. Instead, get started on an organizational change and incentive program to move your employees towards an automation-centric culture.