Teaching devops to fish ...

(this is not actually about fish)

(picture of a fishing boat)

I've often said that it's my goal to engineer myself out of a job. I never expect to succeed,

because each time I engineer away a problem, a new and more interesting one is revealed by removing the first problem. You've heard the

adage “give a person a fish and they'll eat for a day; teach a person to fish and they'll eat for a lifetime” – I'd like to add to that, “they might

also help you invent a better net”(repairing nets)

But how does this relate to devops? Well, devops is a cultural innovation; it aims to break up silos

and replace a silo culture with a symbiotic culture, because cooperative systems are more resilient, creative and simply more functional.

(picture of grain silos)

I've noticed that as old function-based silos are broken down, new multi-functional ones can

form along lines of business boundaries. Teams naturally conform to sizes of 8-9 people due to

communication issues. So accepting this happens, what can we do to minimise its effects?

(team behind dry stone wall)

You might have heard of Mihaily Csikszentmihalyi (mee-hy cheek-sent-mi-hy-ee); he

described the concept of creative “flow”, but also introduced the idea of a systems model of creativity, in which social interactions and

environmental affordances provide a fertile bed for creativity to grow

(picture of growing ground)

In a devops culture, those social interactions are provided by colocation to some degree, but only within a team; you need to promote interaction between teams which often requires some level of formality and planning to achieve and keep

going.(picture of creative team meeting)

An affordance is a property of an environment which allows an individual action, for example a

map affords navigation. In a devops culture, shared knowledge and understanding of the

infrastructure, architecture, and capabilities of others afford reduced time to market, promote

innovation, reduce rework, and improve quality

(picture of a map).

By providing and improving frameworks to promote knowledge flow and increase social interaction we build a better environment for

creativity. These frameworks need to exist on a continuum of scales and formalities; let's have a

look at some

(image of circles on a number line, overlapping, smaller on the left to larger on the right)

Information radiators we should all know; dashboards and displays which constantly pump knowledge about systems into the environment, with implied context and without interactivity;

they have the dual purpose of informing knowledgeable people, and encouraging

enquiries from those walking past.(picture of sweet dashboard)

“Pop up” classes provide quick, focussed, fairly localised knowledge sharing; eg at the end of a

standup, just before lunch. These tend to happen naturally when a team is functioning well, but

can be kick-started by one or two keen individuals who just want to share something

cool. This needs to be encouraged.

(picture of group study)

Brown bags are slightly more formal, organised further in advance, and last a little bit longer; but

their lunchtime placement keeps the formality low and promotes a more fluid discussion. They

can have speakers from inside or outside the team, department, or organisation; they generally

go for about an hour.(picture of brown lunch bags)

Kata sessions are single-topic focussed, and encourage a larger number of people with a little knowledge to share that in 3-5 minute bite-sized

pieces; eg “cool things we can do in Splunk”.

(picture of tai chi)

Dojos are a little larger again and more formal than a kata session, with a couple of experts

giving a 1-2 hour interactive class on one or two focussed topics of interest; there may be pre-

work or homework. An example might be “using OAUTH for identity federation” or “shell

scripting from zero to hero”

(picture of a dojo)

Hack days are the largest formal knowledge-mixer, creating whole short-lived teams from

individuals who might not normally work together, and having them develop a single

product/idea/process over the course of a day (plus time for display/voting)

(pictures of the REA hack day)

You should aim to share as much knowledge as you can, perhaps even slightly more than you are comfortable with, to counteract the tendency to

build and fortify silos of knowledge. How creative are cultures where only high priests have

the hidden knowledge?

(picture of a high priest)

You should aim to share knowledge of your environments, skill sets, processes, plans,

architectures, successes and failures, especially to those that you don't work with directly

. (picture of sun shining through trees)

You'll help prevent silo formation, engage the curiosity of your peers, increase the recognition

of capabilities of individuals, improve the quality and speed of decision making, short-cut the path

to discovery of good (and bad) technologies, provide protection against human outage, and

improve the environment for creativity to thrive(pictures of thumbs up)

I'm not saying you have to share absolutely everything; some things don't share well, like

root passwords on financial servers; but perhaps you can share the fact that there is a financial

server, and it's replicated across two continents; this might change how a team architects an

application that produces or consumes the data it holds.

(picture of sharing)

… as the sage (might have) said:

“Give a person a fish and they eat for a day.

Teach them to fish, and they'll eat for a lifetime.

Teach them how and why nets are made like this, and they could help you invent a better net”

(picture of mending nets)

A rising tide lifts all boats after all; if I can help you engineer me out of one job, think of the cool and interesting problems we'll be able to work on

next once we've been able to step beyond the current problems and have seen what lies ahead.

(picture of bright field beyond trees)