How to use a compass

As long as I can remember, I’ve disassembled nearly every electronic device I could lay my hands on. Starting with the old pick-up from my parents, my first hi-fi set and Mini Disc player, I continued to perform this exercise professionally as the lead editor of a Dutch audio and video magazine. As soon as you lift the cover of a device, the layout of the PCB and corresponding cabling tells quite a lot about the product. The differences in design can result in a major difference in audio quality. Even with the same components, like the DA-converter, Integrated Circuits, and capacitors. Nice to know, but what does this have to do with DevOps, you might ask? Let’s find out.

Lots of books, articles, and blogs are written on the subject of DevOps. They contain implementation examples, share success stories, and warn you of pitfalls. Still, there is not a single source that tells you exactly how to “do DevOps step-by-step”. There are, of course, some best practices. The Spotify Model is famous and broadly used on the Web as an example and DevOps succes story. Their model uses squads, chapters, tribes and guilds so it’s great for extending your DevOps slang vocabulary as well. Also various consultancy firms have their own set of rules and experiences. Since LEAN, Agile, and Scrum, are the main components of DevOps, the major differences between all best practices can be found within the “design” of those best practices. Sadly, in contrast to audio equipment, even once you have a great design, DevOps can not be reproduced over and over again within different companies. This is because every company is unique.

Instead of searching for a golden DevOps blueprint, or documenting every action within the company, use all available information about DevOps as a guideline. Just the way you use a compass to help you to navigate. DevOps is not a super accurate GPS navigation system that precisely tells you where to turn left or right. It will help you to get to your destination, but you will have to conquer all the challenges on the route, and the route itself, by yourself. The reason behind this bears repeating: every company is unique, so every route towards DevOps is unique. Moreover, the final destination of every company is also unique.

Simply starting DevOps within a company by using a blueprint will not make it a success. No matter how good your blueprint is. In a way, it is comparable to what sometimes happens with ITIL. Some “ITIL fundamentalists” strive to implement ITIL according to the (comprehensive) booklet. Every process has an extremely precise description that defines all steps and actions to the smallest detail. To defend this bureaucratic disaster, excuses like “we need to be compliant,” or “this is demanded by our corporate policies and directors,” are often used. With DevOps, the same form of process madness is perfectly possible. It should be avoided at all costs.

With DevOps, every company needs to reinvent the wheel a little bit. From a LEAN perspective, this sounds like waste, but it comes with a big advantage. Customizing DevOps to the specific needs of your company will make sure it fits your corporate culture, the products and services you (want to) deliver, and most importantly, it will help you to involve and keep your engineers and specialists.

As with those old audio devices, the same DevOos components, but with another design, may give a different result. Start by understanding the components. Learn to use this as a guide . . . as a compass. Then, when choosing your route towards your destination, write your own blueprint. During the journey, continuously adapt your blueprint until it fits your company’s situation best. 

One last thing. You might want to draw with a pencil. If you do it right, you’ll be making changes, and pencil is easier to erase than ink.