Stephen Townshend’s Post

Risk and security in isolation don't generate value, unless they help support the underlying business objectives. Yet many risk and security functions spend their time putting up walls which slow progress and hinder innovation. There was a quote in David Marquet's book "Turn The Ship Around!" which I'll paraphrase... if you spend all of your effort trying to prevent bad things from happening then you will with absolute certainty prevent yourself from achieving greatness. I think a better model is when risk and security work with other areas of the business to achieve their outcomes safely. Throwing up walls and tedious processes just slows everything down, irritates everyone, and often doesn't reduce risk effectively anyway. I also think we over-fixate on certain types of risk. What about the risk of not innovating or adapting quickly? What about the risk of staff attrition because of frustrating processes that block the flow of work (and creativity)? There is a way to have high levels of risk management, effective security, and also to deliver business outcomes effectively - but it requires working collaboratively toward the same outcome. #security #risk #digitalage

Check out the latest Observability 360 newsletter which includes my (in)famous "Bad Observability" article: https://lnkd.in/gBe7NX8j

What's this? A Slight Reliability episode on a Friday? My org is moving to a SaaS first model. In this episode I ponder what this means for #SRE: 🦑 How does it change the nature of our work? ⛰️ What challenges does it introduce?  💀 Is SRE even viable in a SaaS first world? #SaaS #cloud #reliability #oncall #observability #tracing https://lnkd.in/g72buSqB

A couple of weeks ago I had the pleasure of joining Artem Yakimenko and Dom Finn on Yana Martens livestream to discuss what #SRE is and how to become one. More of an introduction to #SRE than an advanced session, but I thought Dom, Artem and I had three quite contrasting views on SRE which I found fascinating. Thank you Yana for the opportunity! It's been a minute since I got out in the world to speak after changing jobs, and I got a lot out of the session. https://lnkd.in/gzksp2dP

I'm hiring a DevOps and Environments Lead at IAG. This is a principal/staff engineer level role which focuses around designing and managing environments within large programs of work, and applying SRE and DevOps practices to make them reliable, observable, and easy to operate. You'll need to be comfortable working with and communicating with a wide variety of stakeholders from executives to engineers. You'll also need to be confident working with ambiguity, taking the lead, making decisions, and speaking up when things don't add up. This is a chance to drive strategy and change across the organisation. You'll lead the design of observability, change, release, and incident response process and tooling both within our team and across the program (and beyond). It is more hands off than hands on, so if you need to be writing code every day to be satisfied then this isn't the role for you. You won't be managing people but you will be expected to provide technical direction to our team and the wider program, mentoring junior engineers and graduates, and to advocate for and help implement change in other teams across IAG. I'm looking for someone forward thinking, who understands how organisations around the world are changing their ways of working to adapt to the complexity of the Digital Age. You don't need to have all the answers, but you do need to be able to solve problems and make incremental change toward clear outcomes. As I've found recently, it's tough work for both applicants and hirers to make a good match from a CV alone. It would be helpful to me if you could include in your cover letter an experience you had implementing DevOps or SRE principles and what outcome you set out to achieve - and then how that went. It would also be great to hear about you and what drives your work, and what "DevOps" or "SRE" means to you. For me, I burned out working within unmanageable complexity a few years ago. Ever since then, on reflection, I've been almost subconsciously doing work that makes delivery and operation of technology simpler and more manageable (or even enjoyable) for the people involved. This role will focus on Australian based delivery, so the ideal candidate would be living and working in Sydney, Melbourne, or Brisbane. However, I'm open to candidates in New Zealand as well. You'll need to be located in Australia or New Zealand and have the ability to work there. If you are based in Australia please apply here: https://lnkd.in/g-RvSfSY Or if you're in New Zealand please apply here: https://lnkd.in/g_gGBzbA If you know of anything who you think would be a great fit for this role, please let them know. NOTE: I am not allowed to interact with recruiters, only direct applicants. #hiring #DevOps #SRE #environments

Hey Dan Slimmon our interview on clinical troubleshooting got mentioned in the Observability 360 newsletter! Thanks John Hayes! #observability #sre #ops #incidentmanagement https://lnkd.in/gZqNgc5e

In just over 24 hours I'll be on a panel with these beautiful people. Let's see if I remember what #SRE is all about...

I'm hiring for a couple of DevOps + Reliability engineers at the moment. I'm sifting through well over 100 CVs. On paper, almost every candidate has the requisite technical skills and experiences. So how do I decide? I'm reduced to focusing on one question: Is there evidence of outcome based thinking? Very few have this. Most CVs are overloaded with buzzwords but there's no indication of the 'why'. Maybe it's just me, but I'm not interesting in reading 50 bullet points about all the tools and technologies someone has worked on. I want to know: ✅ What problems you were trying to solve? 🔨 How you went above solving them? 🧯 What went well? (or not) 🧑 And more generally... who you are as a person? What gets you out of bed? It's exhausting seeing the same "CV phrases" re-used over and over, such as: "Proven track record..." "Consistently demonstrates..." "Results driven..." "I am a seasoned..." "Award winning..." If you want your CV to stand out you have to put some of yourself into it. Add a bit more about why you do what you do. Keep it concise and easy to digest. Don't oversell yourself. Make sure you come across as a human being. #hiring #CV #DevOps #SRE

This week on Slight Reliability Dan Slimmon and I discuss using techniques from medicine in how we respond to incidents. We cover: 🧑🚒 The power of the incident commander role 👨🏾⚕️ Clinical troubleshooting 👬 Responding to incidents the same in non-prod as prod 🌏 Getting groups of people on the same page about an incident quickly 🖊️ The difference between tracking the history of an incident versus documenting the state of the problem solving effort ...and much more. #SRE #ops #incident #oncall https://lnkd.in/gk9dX3VC