CI for Leaders

Continuous Improvement sounds a lot like the over used business term "Raising the Bar." One of those coined business terms that can put some people off due to the ambiguity of what it actually means, what makes a "bar-raiser" successful and how do you measure it. In my experience a "bar-raiser" is someone who challenges conventional practices and might even be knowledgeable enough to make things better. One driven to ensure continuous improvement rather than settling for “good enough" and complacency. 

When I first started working with my last employer two or so years ago, I was fully immersed into a literature focused environment. One that not only facilitated the production of literature but relied on literature for blueprinting a leadership strategy. There was a clear desire to re-create the Google SRE model and a "No-Ops" culture. The modern IT utopian goal. All the cool people were doing it already. The top down decision had to be made. Investments were committed. Agile methodologies and training had been delivered. DevOps titles were assigned. But something was missing...

DevOps practices give teams accountability for their work, including quality of the product or service they deliver. With DevOps, we no longer need people outside the team to test for quality and to take independent ownership of ensuring quality and performance. The same can be said for security and compliance. However, if quality and security (and accessibility, resilience, and user-friendliness) are not binary, yes-or-no metrics, what drives the team to continuously improve on these fronts? A bar-raiser. 

Consider this tidbit extracted from a tech leader resource on a similar topic:

Do we not want continuous improvement in security, rather than “secure enough?” Do we not want continuous improvement in availability and quality, rather than choosing a level which we say is adequate (as in Google’s concept of an error budget)? Yes-or-no metrics made sense when we had gatekeepers or we specified requirements in advance (“the system must achieve an SLA of four nines of availability”). But in our agile, DevOps, continuous improvement approaches, is this what we want? Shouldn’t we constantly be striving to improve—if not the availability of our systems—then at least the availability we are able to get from a given level of spending?

On the other hand, we want to maximize the amount of work not done. We want to build the simplest architecture that is acceptable and the minimum number of features that are acceptable. We encourage developers to stop work when their automated tests pass (although they do refactor to simplify their code after that point). Google’s error budget should be seen in this light. How can we reconcile the idea of continuous improvement with the idea of maximizing work not done?

Perhaps the bar-raiser concept is the answer. What if we replace the independent QA function with quality bar-raisers, who are not gatekeepers (“your quality is not good enough”) but rather drivers of continuous improvement (“here is where you have an opportunity to raise the bar on quality and some ideas on how you might do it”)? Similarly for security: yes, you meet the security bar, but let’s look at how you can do even better, maybe without adding any significant amount of work?

Raising the bar sometimes has a cost, but often it does not. I wonder if the idea of bar raising isn’t just the next step in a digital world where moving forward is both discrete (creating new features) and continuous (improving resilience and security).