On October 7th I gave a talk at the IPExpo show about getting from legacy IT to the modern idea of DevOps.
Mostly I talked about the core idea of DevOps being communication, about breaking down silos. I went on to suggest ways technology can support that idea.
Before we get going — who works in an organisation of less than 150 people? More than 1000? (Later on we'll come to Dunbar's number).
#
I'm still seeing organisations using 'runbooks'; a list of things to do to deploy applications/systems. I've spent my career automating — sometimes upgrading manual processes to automated, and sometimes being lucky enough to do greenfield engineering. Repetitive, manual, tasks can be a massive drain on an organisation and detrimental to keeping the best engineers.
#
Typing from a list of instructions _can_ lead to mistakes. We've all got stories of that one deploy 'fat fingered' and suddenly a whole production system gets killed.
#
Automation ensures consistency. It shouldn't be a mystery why most auto manufacturing is robotised.
#
Suggesting automation often gets the response "I'll just type it for now, it's quicker". They could've just typed the same into a Play. So it's caused to me to ponder why people would actively choose to make life harder for themselves. The obviousness of that being, they don't think they are making it harder. Quite the opposite. There are usually one of four reasons.
#
The fourth one being the most powerful "won't I just automate myself out of a job?" (answer: no, but that's a bigger story)
#
This was a graph a customer once showed me. "The green line is the business's expectation for revenue growth". "The blue line is the number of people we can have to do that growth". So how do we fill that gap? Automation. . .
#
Ask the audience — who's heard of Dunbar's number? (At the time, this was delivered in front of an audience of roughly 200 people. Two raised their hands) DevOps — story of its origins. Dev & Ops pulling in opposite directions. Silos. Let's get them to talk! This should be common sense.
#
I watched this TED talk with Yves Morieux a while ago, and love his first principle.
#
Create digital 'feedback loops', so departments can work together, and learn from each other. A cohesive organisation, versus many small 'tribes' doing their own thing. A great collaborative example — Wikis versus old-fashioned Word docs. Arguably any online collaborative documentation tool is better!
#
Another of Yves Morieux points was to create feedback loops — creating internal dev practices based on pull requests is a great example of this.
#
As much as chat systems can be an overload of 'noise' (whole other conversation on the culture of implementing signal vs noise practices) they can be a good centralisation point for communications.
#
ChatOps — use everyday communications tool with centralised automation
#
Thinking back to slide 6, and the reasons why people don't automate — or adopt anything new for that matter — it's about making 'change' easy. So even when people default to resisting change, if you can demonstrate something productive within 10 minutes of picking up a product/technology, the resistance is far more likely to subside quickly. So "K.I.S.S.". With tech, the talented folks will prefer text based systems. Typing scales far better than moving a mouse and clicking. You won't build a creative organisation — and engineering is totally creative — with GUIs. Get stuff done in text, report on it in GUIs.
#
This being the output of the previous slide 😂 Anyone remember Perl Golf?
#
Common tool - everybody goes off to do their thing, with a clear direction. 'Meet in the middle'.
#
Closing anecdote: IB Wiki (in 6 months more docs done than in previous 3 years - ease of use/access/finding information) i.e. ** make it easy ** // Create a collaborative culture by default - INS 'Knowledge Quests'
#
