Modern technology companies are obsessed with metrics. They use metrics to measure sales, marketing and business development efforts. Modern tech firms also use metrics to decide how its employees should be compensated.
This laser-like focus on metrics is reasonable because it’s very hard to fix a problem you don’t understand, and one way to better understand a problem is to measure it quantitatively. For example, Uber regularly measures the amount of supply hours (i.e., number of total hours worked by drivers) the company has deployed in a particular week, month or quarter. The reason Uber does this is that it’s critical for the company’s overall health to know how many aggregate hours drivers are working. If supply hours took a dive in a particular quarter, Uber’s executive team would immediately know that the company had a problem.
Where does DevOps fit into this? Well, DevOps is a development philosophy that asks everyone to think critically about everything. This includes thinking critically about how metrics fit into a company’s long term strategy. Do you have the right metrics? Are you too reactive when your key metrics dip into negative territory? Not reactive enough? These are the kinds of questions a good DevOps shop will ask.
From a DevOps perspective, the overall mission is more important than movement in any specific metric. Take the Uber example once again. If supply hours dip sharply in a given week or month, the first instinct of the Head of Growth (or similar function) at Uber will be to identify the cause of the dip. Once the cause is identified, the Head of Growth will do what he or she can to raise supply hours to where they were prior to the change.
Is this a bad thing? Well, from a DevOps perspective it might be. Imagine that the reason you had a drop in supply hours was that your driver-intake required new driers to submit important personal information to confirm their real identity. If this change in the driver on-boarding process was made to shield Uber from legal challenges and regulatory inquiries, rolling it back would be inconsistent with Uber’s long term strategic goals.
Under these circumstances, what would a leader in a DevOps shop do to address the dip in supply hours? The first thing a genuine leader would do is remove the possibility of rolling back the new on-boarding requirements. The second thing such a leader would do is diagnose where new drivers were dropping off in the process. If the new questions were causing the drop off, one solution would be to stage the on-boarding process so that new drivers were served questions in stages. Another potential solution would be to tweak Uber’s marketing strategy so that more new driver candidates with stellar backgrounds applied to be drivers. This solution addresses the problem by leaving the new on-boarding process intact but changing the democratic groups being fed into that process. The most important thing about both solutions is this: DevOps principles require a creative approach to the problem, one that prioritizes long-term goals (i.e., steady growth with fewer regulatory and legal challenges) and ignores the superficial appeal of enhancing key metrics on short-term basis (i.e., short-lived upticks in supply hours).
The real challenge is to empower the right people to put these DevOps principles into practice. These principles are easy to articulate in words, but Particle 41 has seen too many instances where otherwise amazing companies have failed to empower key executives to follow these principles. In cases like these, the basic problem is that one or more executives have done really well professionally by growing metric X, and so anything that interferes with the growth of that metric represents a professional threat to those folks. Of course, there is light at the end of the tunnel: If your organization is willing to follow these principles, it will be much easier to achieve your long-term growth and revenue goals.