DevOpsDaysNZ — Guiding Principles

I have been eagerly awaiting a DevOpsDays conf in NZ for the last couple of years. I then was able to attend the DevOpsDays Melbourne conf in July last year, man that was awesome. During this time, it did occur to me that, perhaps I could help organise it? I laughed out loud and told myself that there will be someone shortly… I was later to discover, that this voice was my inner critic.

More time passed and still nothing, but I had been talking to some people… Who seemed keen, and most people I mentioned this to were very encouraging. As in they would go, and know of heaps of people who would go. Not organise though, but definitely go!

So I took the plunge, found a great team of people willing to give up their time, to make this a reality. We have a group of contributors that have been coming together since the start of March, getting to know each other, and looking how best we put on a DevOpsDays conference.

One of the things I found pretty quickly is that distributed voluntary teams are very hard, very much seated in the complex domain if you will. Given that my personal DevOps journeys is looking at the paradigm shift of valuing “learning how we do the work” over “doing the work”, I felt we needed some guiding principles to aid our contribution.

So hence this blog post. The guiding principles, our core values if you will. In an attempt to provide transparency of our working model, I am sharing these with you all today (note I had planned to do this earlier, but life got in the way). Being a big Patrick Lencioni fan, I proposed using his mechanism of doing work, namely the Thematic Goal. I am hoping that we’ll be able to share these as we progress, b currently we have some constraints that we’re working through.

We are still working on a venue (and thus city) and a date ( hopefully announcing the city and date very soon), but we are working as best we can. If you’re interested in keeping up to date you can follow our twitter account

Here they are:

Bringing the outside in & The cost to others

This tip I got from one of those “No dickheads rule” blog posts. Paraphrasing it states that we value all of you, which includes your family and others that contribute to make you, who you are. Now that we acknowledge those close around you, we also acknowledge that these people tend to make the sacrifices that allow us to contribute on a project such as this. The “cost to others” is a way for us as a core team to acknowledge that sacrifice. Does it matter that those close to you have met the people you are talking to on the computer for every night for the last week? That they know who you are talking about during a general conversation? I feel it does and to me it’s just basic manners. We the DevOps people preach, influence technical people not to go dark with their work, the irony being this tends to be exactly what we do to those we care about the most.

So I will be doing as much as I can in acknowledging this support. I’m really wanting to plan an event for those “others” where we can all meet and have a meal of some sort. Now given our geographically distributed nature, I’m well aware of the logistical and cost implications, but I am of no doubt of its value to us all, and it is a priority for me.

Caring about our health

Another key focus for me is our health as individuals and a team. Health can mean a variety of things, and no we won’t be implementing a high intensity training session before each meeting (unless you like that…). So this raises the question: how do we care for each other? Contributing on a project such as this, can become a somewhat all-consuming effort, in which puts us at risk suffering from the boiled frog scenario (see for more details). For us to maintain our health we must be prepared to ask those hard questions of those for whom we have concern for. This requires a staggering amount of trust and vulnerability. Burning out any contributor is not an option for me, and the ability to have mechanisms in place to help with the checks and balances, I feel would be a no brainer. Just having a mechanism to say I’m a little out of control instead of waiting until we hit the wall are examples of the kind of health “monitoring” I’m thinking of.

I would also like to think about a protocol for anyone to challenge the health of the conference. This health is subject to the same forces that act upon us personally and as these forces manifest in a gradual means, which can have a dramatic effect on the planning of this conference. Like the Boiled Frog scenario, those of us at the coal face of team can be blinded to these gradual effects, so understanding this and inviting inquiry, especially from those on the fringe of the team, is crucial.

Lack of care and burnout are polar opposites of what I feel the spirit of the DevOpsDays conference is all about.


I’m sure I don’t need to explain the value of diversity, but one thing I would like to articulate is how I value conflict. Ideological conflict is healthy and necessary, but we must acknowledge its dependency on trust. Not a predictive trust like how “Reuben always goes on about his Windows phone”, but a vulnerability trust where we can say things like, “Reuben, I thought you said you would have that task done by now?” Can you see the difference?

Predictive trust allows us to understand patterns of behaviour, regardless if such behaviours are good or bad. Vulnerability trust on the other hand, allows us to engage in healthy conflict, and even, dare I say, come to a decision where it’s ok that some may not agree. The ability for a team to disagree openly, instead of having what we call a “pretend agreement”, where we say we agree, but voice our disagreement privately, is unbelievably powerful.

The trust required for ideological conflict fosters a healthy environment for diversity. Seeing and acknowledging other perspectives cannot happen without this trust and the healthy conflict engagement allows for passion, but not politics. Diversity gets trumped (no pun intended) by politics.

If you have any comments, then I would love to hear them. I find these kinds of things are, well important and we should be doing more of this. If you disagree I would love to hear from you.

Take care sports fans and stay tuned!

Like what you read? Give Reuben Dunn a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.