On Papercuts And DevOps
Last Saturday, I was talking with one of our Attune customers about their needs and that led to a very useful conversation on the improvements we can make to our Attune package. The customer expressed some features that would be useful for them and I decided that we need to implement those features in Fluxboard (™), our visual dashboard that helps organizations to own their IT. But it got me thinking about papercuts, and how DevOps can be thought of as the business practice of paying attention to the papercuts.
When I first came to college being any good Asian son that rebelled against doing medicine I joined the program for computer engineering at UT, although at the time I had the secret agenda to switch to Physics after my first semester. But that did not happen because I fell in love with programming. I saw it as a medium to fuel my creativity, solve problems, feel that spark of getting it. At that time there was no such thing as a papercut, because everything was new, everything was learning, and the systems were not extremely complex.
As my career progressed, I worked on many projects, and I felt that my learnings were stagnating. I needed that high, but I found it harder and harder to find. I was feeling less like an artist, and more like an artisan. I spent too much time dealing with trivialities, the same trivialities again and again. And each of those like a papercut took its toll on me. And programming, something that I love, something that I’m good at, became painful. And my productivity suffered as a result. Each of those papercuts was expensive, for myself and my employers but at the time I didn’t understand just how expensive it was.
The problem with these papercuts is they hurt the organization, but not like cancer or any acute illness, more like heart disease. They hurt your organization, bit by bit, almost never in a way that feels urgent. So like how we neglect to follow a regular exercise regimen the process improvements for DevOps never happen. Because usually they’re not urgent enough, except for those catastrophic times when there is a security incident, or a disaster when it is too late to do anything.
This is why DevOps is important, it keeps your organization full of life, energetic and sustainable.
Continuing an analogy that I have already pushed too far, where do Flux7 and other companies providing consulting in the various aspects of DevOps fall in this relationship?
Well, this relationship is similar to that with a coach or trainer, they enable you, guide you, provide you with information, and help you succeed. One thing I would say in how Flux7 differs from other consulting companies is that we are more invested in your long-term growth than a recurring revenue stream.
Our products and services are geared towards enabling our customers to progress independent of us. For example, we don’t provide managed services on AWS. The reason we don’t is because we believe if you need someone else to manage your infrastructure, then we have a failed in our duty to enable you to manage your own infrastructure.