Death by a Thousand Chickens

Almost every candidate that I have interviewed at Riot Games asks something along the lines of, “Everything about Riot sounds awesome, but it can’t all be roses – what’s the most challenging thing about working here?” I generally start by assuring them that Riot is, in fact, a particularly amazing place to work for a million different reasons. A few examples from my personal experience here: we invest deeply in growing people, we all care a ton about the products that we’re building and the focus on the people who play our games is palpable, and we provide unlimited opportunity to get plugged in and drive real change on everything from product decisions to the way that teams and organizations operate. But the people asking the question are correct – it’s not all roses, and we also want to be transparent about our areas for improvement. That’s why I always describe an area where I think we currently have a lot of room for improvement: we’re often the victim of “Death by a Thousand Chickens.”

Before I define Death by a Thousand Chickens (which I will hereafter abbreviate as DB1kC, because if there’s one thing engineers enjoy, it’s creating acronyms!) I want to emphasize that it isn’t specific to Riot. It’s a phenomenon that can occur in any organization but is more likely to occur within flat organizations where individuals at all levels are empowered and appeals to hierarchy don’t carry weight. I’m using a specific example from my experience at Riot to help explain the concept, but I think the ideas here are broadly applicable, and I would be thrilled if this post can ignite a discussion on how to prevent DB1kC without reverting to a top-down chain of command.

DB1kC occurs when someone is trying to make a decision at an organization and a large number of well-intentioned people want to be consulted and provide input on the decision, but very few want to be responsible for helping to execute on the decision. To steal a couple of terms from the scrum world, it’s trying to operate with a multitude of chickens and precious few pigs, when the chickens keep running in and tripping up the pigs.

To ground this in a real-world example, let’s travel back in time a couple years to when I first joined Riot. My experience interviewing for a position at the company was decent, but having seen the way that we were interviewing engineers from both the inside and out I was convinced that we could do better. The process took a long time, the content and structure of interviews differed (sometimes drastically) between different organizations and interviewers, and it was difficult to mine the data necessary to make data-informed improvements to the process. I took up the mantle and issued a “call to arms” email to all engineering managers and recruiters and asked people to join a virtual team that would meet on a relatively infrequent basis and serve as a central coordination point for work to improve our interview process. I got a lot of responses to the email from managers who wanted to give input into the work that the group was doing, but most people said that they didn’t have the bandwidth to join in the work themselves.

About 10 people did opt into the group and commit to doing work, and over the course of the next 6–12 months we were able to make a bunch of targeted improvements to the interview process. We rolled out a fresh set of interview “kits” to push us towards more standardized and structured situational and behavioral interview questions, we partnered with central recruiting to help launch a survey to collect metrics on the candidate experience, and we made other changes to the process that reduced candidate turnaround time significantly.

The problem is that as we attempted to deploy each of those improvements, we had to do battle with DB1kC. Some folks who didn’t want to commit their time to work with our v-team told us that we had moved the needle forward, but not in the exact way that they wanted things to go. Others spun up parallel efforts to implement targeted improvements in a particular way for their specific team without engaging with us and attempting to generalize what they were doing so that it could be applied to other teams at Riot. All of these chickens were trying to help, but they weren’t on the sidelines *or* on the playing field. They were essentially standing with one foot on either side of the boundary line, and in the process, they were slowing forward progress (and in some cases bringing it to a screeching halt).

Contrast this with the way that I could have attempted to push changes to the hiring process through for my organization at either Microsoft or Amazon. Once I had documented the proposed changes to the interview process, I could have pitched them up my management chain and gotten buy-in from my VP, who would have turned around and told his entire organization “this is how we’re interviewing from now on.” Note that I’m not saying that escalation is the only tool at those companies, but I am saying that it’s a viable tool that exists and gets used to preempt the possibility of DB1kC. The advantage of driving change socially at a flat organization is that at the end of the day, the idea is more refined (by virtue of more input/iterations) and everyone is aligned; you get 100 percent buy-in. The advantage of leveraging hierarchy, on the other hand, is speed. DB1kC is the extreme example where trying to roll out a change socially results in deadlock and speed essentially goes to zero.

Now despite the risk of DB1kC, I firmly believe that the pros of flat organizations that don’t allow for appeals to hierarchy far outweigh the cons. I am, however, passionately interested in mechanisms that can preserve the benefits of a flat organization without sacrificing the ability to move quickly. I suspect that any successful strategy probably hinges on being crystal clear on who is in the game and who is on the sidelines: if you’re a chicken, assume that the pigs are doing good work and don’t get in the game unless you’re asked to do so. From the outside, companies like Apple and Asana appear to be making the pig/chicken distinction explicit by nominating a single Designated Responsible Individual (DRI) to be accountable for a decision, letting the DRI choose who should be looped in, and then trusting that they probably got it “right enough.” I’m waiting for a good opportunity to pilot the DRI concept at Riot, but I haven’t done so yet.

What say you? Are there other ways to solve the dreaded Death by a Thousand Chickens problem? If so, I would love to hear suggestions in the comments! And before I go, a quick shout out to my colleague Michael Chang who first coined the phrase “Death by a Thousand Chickens” – had he copyrighted it, I would owe him at least a dollar by now…