The "User Growth Team," while not an entirely new concept, has been recently popularized by some articles on Facebook. This team works somewhat out-of-band of traditional marketing, product, and business cycles to do whatever it takes to grow the member base. More details of this can be found in these threads on Quora.
I've always thought of DevOps as having a similar mandate, but being more of the "Internal User Growth Team," where users are employees and growth means performance, not volume. The team does what it takes to make the company and its employees work better, typically achieving these goals with code. The current DevOps focus of merging software development and operations places an emphasis on automation and transparency, two characteristics that certainly work towards these improvement goals. But unless your company is in a hyper-growth phase (where you are always behind), the DevOps team is going to hit diminishing returns in traditional operations work. Can we apply the lessons learned to the other areas of the organization? By following the data, we find many opportunities for DevOps to expand its mandate.
Many people throughout the organization would love to share data, but are blocked because they don't know how to start collecting and sharing metrics, or don't have the tools to do so. And it's likely no one is asking them—collecting data on progress is often not top priority, as long as it's apparent progress is being made. But once you start asking what sorts of data they'd like to capture, you'll find all sorts of requests. A great example of this at my last job was a request for some way to enter the amount of food consumption and waste for the bi-weekly company meal. Unfortunately, I left before implementing this. (Sorry Katie-Rose!)
While many tools such as graphite, statsd, ganglia, and gmetric make it very easy for software developers to instrument code and add data sources, they are still too complicated for non-engineers. The most common database in use outside of engineering is… the spreadsheet. Can you integrate a Google Docs spreadsheet to graphite (or another database that can be globally accessed)?
After the creation step, most people are going to want to be able to share that data. The stock tools provided by graphite and ganglia are designed for engineers. Can you make simplified tools where people can easily make and share public dashboards?
According to Zuckerberg's Law people are going to double the amount of data they share every year. This is true inside the organization as well. Your business is going to generate twice the amount of data, and likely have twice the number of data sources every year. A lot of people are going to want access to that data, and they are going to want to remix and share that data in ways you can't begin to imagine.
A prime directive for any DevOps team is making data accessible. This doesn't have to be complicated. It can be as simple as setting up a common machine, and dumping log files to it, and advertising that the data is there. However, you are going to find a lot barriers and silos along the way. Re-architecting for sharing takes work. Making open systems takes work. And because they take work, and everyone is overworked, a common reaction is, "Why would anyone want this data?". "Really, the web access logs to the intranet?" Yes, we want this data, because if we can't see it, we can't make it faster. Which brings us to the next goal of any good DevOps program:
One common focus in DevOps is accelerating the process of deployment, from development to code in production. However, there are many other data pipelines that can be accelerated. It's been known for a while that website performance has a direct impact on consumers on eCommerce sites. I assure you, internal tool performance has a direct impact on tool usage and employee performance.
Just like the relentless focus on performance for customer-facing applications, there should be a matching effort for internal tools and data flows. Most employees will tolerate very low quality and poor performance in tools they have to use—no doubt due to lack of any competition, and because they have no choice or voice in getting it fixed. The company chooses a tool, often by committee, and generations of employees get stuck with it.
For example, every bug tracking and wiki system I know is painfully slow, usually because no one cares about them and most are bloated old monsters. It's so bad that at every company I have worked at, there were renegades who just abandon the existing tools, and sign up for something new on the web. "And now you have two problems…" Data sharing is harder, and you gain a security problem of corporate data and user accounts being "somewhere else."
The first step to fixing this is simply exposing the performance data (now made easier by the first two points). It's likely to be so bad that members of the engineering team will be offended and fix the problem at the source. If the engineering team doesn't immediately fix the problem (whether because they're swamped, or it's not the worst performance data they're seeing), the data can be used to appropriately prioritize the need in the company. This is just one example; you likely have many internal tools that could benefit from acceleration. Just look at Yahoo bragging about the performance of their new email service—how many minutes of "waiting for pages to load" can you save your organization?
By creating a culture of data collecting and sharing, you will be able to better examine the data flows inside your organization, and find the cause of many unexpected problems. The Internal User Growth Team (aka DevOps), with it's cross functional nature, is in a unique position to attack these newly problems throughout the organization, and find and implement time-saving solutions that increase the effectiveness of every team.
- Last chance to take the DevOps Survey
- Nick's personal website
- Previous posts from DevOps December
About the Author: Nick Galbreath is VP of Engineering at IPONWEB, overseeing billions of online advertising impressions per day. Previously Nick has held leadership positions at Etsy, RightMedia, and other hypergrowth startups. He has spoken at a wide range of conferences, from DevOpsDays to DefCon, and has published a book on cryptography. Nick holds a BS in Mathematics from Boston University and is based out of Tokyo, Japan. His personal website may be found at http://www.client9.com/