Blog

DevOps was one of the most recent topical reads taken on by the Omnitech crew. To help level set a group with wide-ranging experience, we read The Phoenix Project. This novel was a quick, enjoyable read that brings the all too common struggles faced by technology folks everywhere to life through a host of familiar characters and situations that will have you laughing and groaning along with them.

If you have observed or lived technology battles, let me set your fears to rest straight away. This work of fiction has a happy conclusion! The good guys - IT and development teams- wins while the unnecessary corporate bureaucracy is vanquished. So how did they manage to wrangle the mess of undocumented processes and procedures to achieve this glorious ending? Along with gaining a solid understanding of the four types of work and the "Three Ways" to manage that work, our team honed in on the following points from the book:

Tribal knowledge:

Every team has that one indispensable person, the last line of defense, and the person counted on to solve significant problems when everyone has hit a wall. Without this person, the team would be sunk. One of the big problems with this is that these brilliant, dependable people end up only fighting fires. Because their time is tied up in emergencies and no one else knows what they know, they become bottlenecks rather than helping to move the department and business forward. The knowledge, processes, and procedures stored in the brains of these folks have to be captured, documented, and shared. It is a big job but a critical piece of managing the work in our IT departments.

Change management:

Another function that demands our attention is the discipline of proper change management. And yes, I said "discipline."It is beyond difficult to alter the habits of individuals let alone whole teams. When you have spent years doing "favors" or "only take a minute" changes for friends in other departments or favorite clients, it is tough to say "no" and redirect them to a ticketing system. It is even harder to put something on a list of low-impact changes when it would take you as long to "just do the work." However, we have to! We must know every single change that is being introduced into our systems or risk returning to unmanaged chaos. Plus, providing visibility to the backlog of items helps to spotlight bottlenecks (areas and people) and show us how to improve the flow of work. It requires discipline and accountability from everyone on the team.

Trust:

At one pivotal point in this story, the team comes together, shares something about themselves as people, and starts to develop a genuine relationship and trust. None of the lessons learned from this story mean anything if you do not feel safe sharing your thoughts, knowledge, and yourself with your coworkers. Teams may be reasonably efficient without trust but will only accelerate themselves and the business when trust exists. The possibilities seem endless when the politics are set aside and everyone is focused on continually improving and striving together toward the global goal of delivering value.

This book is important to read even if you already have a fair understanding of DevOps processes. The journey of these fictional characters will remind you of the importance of the team and why DevOps is not just another option for teams but truly the only way to succeed long term in the exciting and ever- changing landscape of technology. One last thing for those knowledge seekers that now want to really rip the lid off of DevOps, we highly recommend following The Phoenix Project with The Dev Ops Handbook. Enjoy and be an agent of change wherever you are planted!