It Ain’t What You Do, It’s The Way That You Do It

Why are developers and operations people so different? There is a theory in psychology called ‘regulatory focus theory’. This theory states that when a person pursues a goal, they’ll do so in a way that matches their own values and beliefs. When there is a ‘fit’ in the way that someone goes about achieving their goal, they feel good about it. So, if you want to pass an exam and you are diligent by nature, you may diligently prepare and swat up (this was my method). If you go on to get a ‘B’ you might be annoyed you didn’t get an ‘A’ but you’d be pleased you went about your preparations in the right way.

In regulatory focus theory people are divided into prevention focus and promotion focus. A prevention focus person cares about responsibilities, security and safety. They will achieve their goals by playing by the rules and following guidelines – and they’ll feel there is a good ‘fit’ when doing so. I suspect that not only will many operations people fall into the prevention focus category but so too will many people in the finance industry.

Promotion focus is about hopes, accomplishments and aligning tasks to ambitions. A developer who is promotion focused might try to achieve securing a web-application using the latest tools and techniques. This is almost certainly not what a prevention focus ops engineers would do (and for the record, it’s not what I would do, either). My guess is that most developers are promotion focussed.

Regulatory focus theory tells us that regardless of the goal, people prefer to achieve it in their own way. It also tells us that if they can’t do this, they’ll feel lousy. (Common sense also tells us this, of course.) If I am right about my assumption, that most developers are promotion focussed and that ops engineers are prevention focussed, and if it’s true that having to achieve your goals in a style that is not your own makes you feel lousy, then this may be an explanation as to why dev and ops people often resist each other’s ideas.

It’s the developers who say, ‘use Docker’. It’s the same developers who get pissed off when ops engineers say, ‘no’. The former say that latter are stuck in their ways. The latter says the former are reckless.

The way out of this is respect. Respect in this case means letting someone do their job without interfering with them. I also think that the narratives which currently divide us need re-writing so that they can bind us. If the prevention focussed say follow the guidelines, maybe we should write guidelines together.

I also think leadership, which is often a dirty word in technology, is important. A good leader understands the needs and fears of all their people. The leader’s job is then to help create the unifying narrative I just spoke about along with providing the safety and space to air concerns. (Even the most cold-hearted amongst us tend to view others in a different light once we hear their fears.)

Achieving DevOps is not easy and will never be easy. An understanding of regulatory focus theory might be one step that can help us along the way.

The following two tabs change content below.

Jamie Dobson

Jamie specializes in innovation and technical strategy. As the CEO of Container Solutions, he is primarily responsible for the direction of the company and the well being of the team. He occasionally works with clients on tricky strategic problems, teaching executives how to ‘win’ with technology.

4 Comments

  1. I think Jamie you are too harsh to operations guys. They frequently put entire systems at stake, when they migrate data centers, introduce OpenStack or CloudStack, redesign routing. etc. They simple do it and don’t tell to developers, as they wouldn’t be able to understand what was done anyway. They simple can’t see anything beyond their little applications.

    Your view (prevention focus vs promotion focus) is quite common, but I believe operations guys are also promotion focused. They simply have different views than developers.

    When you drill down, you will realise that DevOps was invented by managers and for managers. To make them feeling better. Note that this is their typical modus operandi – when there are 2 fighting groups, so what is needed? – a blessed leader that will step in and tell: let’s love each other and walk together toward bright future. And how to call it to express the new everlasting bond? Perhaps by joining names of 2 fighting parties? Perfect! Call it DevOps! And the entire glory for solving conflict belongs to managers. Isn’t it so?

    I don’t believe in DevOps. I believe in Continuous Delivery and Programmable Infrastructure – solutions that allow developers to work without the need for having operations. This is what I meant by http://container-solutions.com/2015/03/dev-and-ops-in-the-time-of-clouds/

  2. Thanks Lukasz. Maybe the model is too simplistic?

    Although just because someone puts a system at risk, it doesn’t mean they are not prevention focussed. This just tells you the way they go about putting the system at risk.

    I don’t believe in DevOps, either, or any other religious system. However I am interested in management and leadership.

  3. PS – maybe we should be careful about using regulatory focus theory as a way to understand and label. It could be more divisive than useful. I think I am right about narratives, though, and maybe that is what DevOps aims to achieve.

  4. Putting DevOps aside, I also believe that leadership is important. Sadly too many managers picture themselves as Napoleons that lead entire armies to a distant goal. That’s why they tend to order “work together” instead of trying to understand the conflict. Not surprising that victory disease is so common in business. IMHO arrogance is a great problem of management nowadays. That’s why seeing Selflessness in Netflix cultural manifesto, was for me a great discovery.
    http://image.slidesharecdn.com/netflix-freedomresponsibility-140707071536-phpapp02/95/netflix-freedom-responsibility-18-638.jpg?cb=1404717500

Leave a Reply

Your email address will not be published. Required fields are marked *