If you’ve seen my Career History page, you’ll have seen that as of July 2026, I’m in my 5th year of DevOps & SRE. With that, I thought I’d write down the lessons I’ve learned over the years.
Soft skills in DevOps is incredibly important. In some organizations, this is even more important than tech skills! There was a really good talk on this back at ChefConf 2016 which I think still applies very well today. Here it is if you’ve got 45 minutes spare.
Soft/social skills are so important in the rest of life as well. I’d made the recommendation in my list of books to read to read ‘How to Win Friends & Influence People’ for people who wish to improve their social skills and really get stuff done with others when talking just tech doesn’t work. I’d recommend this to just about anybody even if you are a social butterfly.
Changing or making new processes is oftentimes more impactful than changing tech stack.
In yet another plug to my last article, there’s another book that’s relevant here - ‘How Big Things Get Done’. There’s a good reason for that though. In IT, it’s so easy to get lost in the technology and forget the reason that we’re implementing that technology in the first place. I don’t mean what you want to use it for, but the actual benefits you want to see. Whether it be increased customer retention, or to make people able to have a good experience from more places in the world, I’ve seen more and more that it’s the process side of things that needs more work than anything else. That might be the SRE in me speaking, but making processes more efficient and then automating them is what’s been my go-to as of late.
Documentation is a pain, so make it as easy as possible.
If you love and do documentation whenever anything changes, good for you! Lots don’t, and you’ll be a great force multiplier if you make documentation as easy as possible for everyone. Make it part of the delivery process , with standardized automations/templates for docs with style guides so everyone knows which ways they should be writing things down. While you don’t need everything in the same place, you should have everything searchable in one place.
LLMs won’t fix or break everything, but there are benefits to be had in every area.
A solution in search of a problem seems to have been the play of .ai startups as of the last few years, but LLM’s do definitely have some uses! This differs massively based on the organization, but generally if you just consider LLM’s in the back of your mind for any real problem you see, you might just have a useful tool on your hands. Some good examples are using an LLM trained on internal documentation to act as a chatbot for newbies or people exploring newer areas.
Having LLM’s summarize bigger repos is a popular use as well, and there’s many skills already up for this. There’s lots of skills (and .ai startups!) aiming to reduce cognitive load during the code review process as well.
The “Google Way” of SRE becomes more useful the more you look at it in an abstract manner.
Yes, Google are massive, and nobody expects companies worth less than 1% of them to be able to copy everything that they do. Adopting the ‘Google mindset’ is free though! That’s a bit of a nebulous term, but in short I am referring to a focus on reducing toil and improving reliability over a focus to deliver first and ask questions later. If you want to know more, go and read the Google SRE books from O’Reilly!
Case Studies > All (in some use cases).
Chances are, whatever you’re doing isn’t unique in many ways. It might not be unique in any. That means case studies save you from lots of pain suffered by the people that truly have done something for the first time.
If you want a good example, I’d recommend looking at the Evernote and Home Depot SLO stories for what the state was, and then what good looks like for them.
Carrot > Stick Again, a bit of a vague term, but hear me out. It’s generally a thing that’s true. There’s a few studies on how positive reinforcement is something that benefits development as a child. Turns out, it’s also true when SRE/DevOps want to do things that affect teams, especially if it’s expected to be a rough transition period.
Remember that every person or team does things for a reason. That means that if they’re not doing what you want, they probably don’t have a reason to do what you want them to do (or that reason isn’t good enough yet!). If you give them that reason, they’ll comply much easier than you may expect. And no, that reason can’t be ‘because I have to’. That’s a culture of fear, and not the SRE way!
Getting people out of their comfort zones, albeit temporarily, is part of our job. It’s only fair for us to do the same for them.
For me, that means being the bridge between teams to stop siloiing and enable more proactive collaboration. It also means working on my soft skills whenever possible to really put myself out there to understand the
- Everyone wants the same thing as you (to an extent)
That same thing can be as granular as implementation details, or it could be as broad as saving the company time and/or money. If you find that common ground and work from there, you’ll have a much better time. Everything in life is a compromise, so if you realize that and find what you agree on with anyone you collaborate with, you’ll have a better working life in no time.