It is my current theory that admitting weakness is a sign of great strength. In our industry, we’ve seen this a number of times.
It is my current theory that admitting weakness is a sign of great strength. In our industry, we’ve seen this a number of times. Most notably; when Martin Fowler admitted to the “rough and tumble” of enterprise, he came up with the wonderful Microservices architecture; and when Google started doing SRE around the concept of accepting failures - improving MTTR instead of chasing a meaningless 99.99 numbers, they established their incredible reliability model. In fact, the model is so reliable that users around the world test their internet connection by looking up www.google.com! These admission of weakness go to show that the more we’ve opened ourselves up to admitting failure or weakness, the more reliable software we build has become.
Still, admitting weakness is not a tempting prospect. Lately, we have been coming up against some new frontiers in the DevOps space. Think of it as DevOps “squared” problems - centred mostly on DevOps on our own DevOps platforms, how to develop “DevOps” and then move it to operations. Examples of these kind of challenges include questions like, “How do I Source-Control my Kibana dashboards and Metrics, so I can properly develop them, roll back changes, test them, and move them to QA/PROD from our DEV environment?” or “Shall we prepare a Docker’ized version of our DevOps stack per project or roll out a central environment for all projects to join?”. These questions are really getting at DevOps granularity.
What has become clear is that DevOps is not the silver bullet that we imagine it to be. In reality, it is just a cultural shift that raises as many questions as it provides answers.
In trying to find some of the answers to some of the questions DevOps brings up, and as I endeavoured to lead my team to the right solutions, there were days when I felt as empowered as the legendary (made glamourous for TV) Ragnar Ladbroke (Vikings), while other days I feared I might succumb to the tragic fate of Sir Henry Hudson (shopping at the Bay will never be the same once you know the story!).
This rollercoaster continued until our wonderful Talent & Culture team at Architech pointed me to two books, 1) Work Rules by Laszlo Bock and 2) Lead a Quest by Jason Fox, both of which I am currently reading on my subway ride to work. (Note: I read 3 books at a time in order to help my short attention span problem, another admission of weakness!).
What I’ve determined (with the help of my recent reading list), is that my mistake is rooted in pretending that DevOps has all the answers. Now, I’ve come to understand that the real solution is acknowledging the weakness of some of the modern DevOps platforms. Furthermore, it is crucial to empower the dev team to find solutions together instead of me trying to find solutions for them. Above all, the right approach has been to use my experience to serve my team’s efforts and advocate for their ideas.
So, what’s the moral of this story is? While weaknesses may be hard to admit, it is by acknowledging shortcomings that we fortify our capabilities and empower ourselves to find the right solution to our challenges. Now that’s logic that can last.
