Bar-Raising as a Principle

When I joined AWS just over a year ago, I was introduced to the concept of a “bar raiser.” In every interview process for a new employee, someone is designated as the bar-raiser—the person who will make sure that the new employee raises the bar for whatever function they will be performing. The bar raiser makes sure that the new employee is not being hired simply because there is no one better available. He or she makes sure that the hiring panel is paying attention to all the information it has gathered, and that it is considering whether the candidate will not just perform the work they are given, but actually cause the quality of the team’s work as a whole to improve.

In order to make sure that the hiring process does not become co-opted by the urgency to get someone into the role quickly, the bar-raiser is always someone outside of the team doing the hiring, and who therefore brings a certain objectivity to the process. The bar raiser is also specially trained as a bar raiser, and must have already been part of more than 100 interviews before acting as a bar raiser. They therefore have a very good baseline and a deep knowledge of what constitutes a good fit.

When I was hired, I was also asked to “raise the bar” on our Enterprise Strategy blog, the blog you are reading right now. There was nothing wrong with the blog—in fact, customers and other readers were quite pleased by it. Feedback was positive. That is the best reason for bringing in a bar raiser, someone who might know enough to make it even better, to ensure continuous improvement rather than settling for “good enough.” I already had experience writing books and blog posts; the expectation was not just that I would write good content but that I would cause the level of the content to go up across the blog. I truly hope that you have found it so and welcome your feedback. A bar-raiser drives continuous improvement.

I have come to think of the bar raiser concept as applicable to many areas in IT. When you are doing good work, there is often little driving you to do even better work. If you have spent time eliminating waste from your IT delivery process so that it is now quite lean and cycle times are short, what is going to make you continue to examine your process for additional sources of waste? After you have reduced the number of defects that escape to production, will you continue to reduce that number even more? What brings urgency to that task? And once you have reduced costs to be within your budget, what drives you to reduce costs even further?

At USCIS, I was very focused on speeding up our procurement process. It generally took between six months and three years to award and finalize a contract. I constantly asked my employees to find ways to reduce that time. Sometimes they would proudly show me that they were now able to do a procurement in, say, three months. After congratulating them, I would immediately ask how we could shorten it even further. This wasn’t an attempt to minimize their accomplishment—believe me, any progress in this area was something to be celebrated. But I wanted to know what the next impediment was that we could overcome to continue with the continuous improvement process. What made it take three months? What could our next step be to fix that?

Sometimes we create urgency through Big Hairy Audacious Goals (BHAGS). At one point I set a target of completing procurements within just one month. BHAGS can be an effective way to drive improvements—but if someone was able to drive the procurement time down to one month, my next question would still be: “How can we make it even shorter?” That is a bar-raiser way of thinking.

Continuous improvement requires continuous pressure to improve (pressure in the good sense, not stress-inducing), some force that makes improvement important and relevant. Arguably, this force needs to come from outside the execution team, because it is a matter of setting a context in which the team considers the continuous improvement to be important, or relevant to its success. While BHAGs might create a temporary sense of urgency, what we really want is a continuous drive to improve. The bar-raiser concept might be useful for this.

DevOps has given teams accountability for all aspects of their work, including quality and productivity. With DevOps, we no longer need people outside the team to test for quality and to take independent ownership of ensuring quality. Ditto for security, compliance, and virtually everything else. But 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?

An interesting train of thought for you. 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).

–Mark

PS – thanks to my employees at USCIS for putting up with me when my attempt to keep pushing the bar was inadvertently stressful! 🙂

@schwartz_cio
A Seat at the Table: IT Leadership in the Age of Agility
The Art of Business Value
War and Peace and IT: Business Leadership, Technology, and Success in the Digital Age (now available for pre-order!)