It’s been 10 years since I first started learning about DevOps. I was in some airport waiting to go home from a pentest and I was looking through ruby and chef videos on youtube when I came across Jez Humble’s ChefConf 2015 Keynote and it blew me away.

I started my career as a Linux and Solaris sysadmin and moved into security consulting about a decade later. I must have heard some mention of DevOps before then. I had a copy of The Phoenix Project, but didn’t get that far into it. It reminded me too much of my old jobs and I didn’t want to read a book that mirrored my past experiences.

I’ve since watched countless hours of conference talks, attended multiple DevOps Days cons, and read multiple books on DevOps. This led me to the lean manufacturing movement and books by Demming and Goldratt. There’s two ideas that have stayed with me since I first heard them.

Taking Advantage of Technology Requires Change

Beyond the Goal is an amazing set of lectures from Eliyahu M. Goldratt. While there’s a few topics he goes over, the first one is the most applicable to my job. Dan North also did a talk on it in 2017 called How to Break the Rules, which provides more modern examples.

“Technology can bring benefit if, and only if, it diminishes a limitation” – Eliyahu M. Goldratt

Eliyahu starts off with this quote, then provides four questions we can ask ourselves relating to this.

1. What is the power of the technology?
2. What limitation does the technology diminish?
3. What rules enabled us to manage this limitation?
4. What new rules will we need?

The idea is that when we start working we find a set of limitations that we have. In order to deal with these limitations we create rules. These rules help us cope with the limitations and provide a framework we can use to handle them. Before teleworking became common we were limited to getting jobs that we could reasonable get to every workday. If there was a job in another state we normally had to move if we wanted to work there. With the rise of high speed internet and the numerous communication methods that we now have this limitation has diminished. Some jobs no longer require being there in person to complete. This allows us to change the rules to allow people the ability to work from home.

This also means that we should take a look at anything we implement and determine what it provides and what limitations does it diminish. Let’s say your team did integration testing once a month due to issues with the tech stack and the amount of hardware and cooperation required. It’s then decided that they want to bring in a platform team and develop a build pipeline that can do an end to end integration test every night. You’ve gone from being able to do this task 12 times a year, to 365 times. This is great news!

However, there are some questions you should ask yourself in this situation:

• Did anyone look at what rules were in place due to only being able to do this once a month?
• Did someone take a look at all the meetings and change approvals that were implemented to deal with the difficulty with the old way?
• Were you able to change those rules to take better advantage of the technology?
• If you don’t change how you perform your work to take advantage of the new technology, then what benefit did the new technology actually give you? It may not be needed for your day to day feature implementation side, but any time you change your teams workflow you should ask yourself Eliyahu’s four questions listed at the start of this section.

Provide Context, Not Solutions

“It is not enough to do your best; you must know what to do and then do your best” – W. Edwards Demming

There’s a common pattern I see all over. A system gets designed by managers and architects and then the solutions are handed down to the workers to implement. The people doing the implementation aren’t given the time or leeway to learn what they’re doing or how to do it. They’re not even given much context beyond the solution. Maybe they’ve never even been taught that they should have more than this. The solutions are created based on previous experiences and grand idea conference room designing. The design is implemented. Tested based on the prescribed solution. It goes into production and breaks. It isn’t designed to handle the scale, or it has a bad data model. Maybe the solution provided had nothing to do with what the problem actually was.

I’m not sure how anyone can expect someone to succeed if they don’t know what they’re doing. While this does relate to people needing to hone their skills outside of work, I’m mostly looking at it from the perspective of providing context and the ability to learn and experiment. People are not mindless machines designed to perform a singular task. They need to know why they’re doing a task. Management needs to provide context. Demming talks about this in one of his interviews.

Provide context, not solutions. By giving your employees the ability to grow and the opportunity to have their say in the work they perform, you’ll find greatness. They will generally be able to make better decisions because they are closer to the problem and have more hands-on information than the people who white boarded it 4 months prior to the start of the project.