The Devil in the Details

When I was at AMZN, an App Analytics company called me requesting a phone screen. I wasn’t really looking to leave my team at the time, but I usually take any opportunity to learn what another company might have to offer, and to understand a bit about their culture.  They were based out of the Bay Area, with a local Seattle office, and I guessed (correctly) that the regional Director was looking for someone to take over the day-to-day management of the local dev team so that he could focus on more strategic issues. That Director and I had a nice conversation, and I stated that I wanted to do a little more research before getting back to him about possible next steps.

I opted not to leave AMZN at that time, but in my research, I discovered that the CEO of this company took pride in the fact that he still wrote code on a regular basis. I found it curious that someone with high level responsibility for an entire company, the P&L, and the broad vision, could actually still contribute to product. Perhaps he was only writing prototype code, or working on side projects, but still, he was coding, and that was impressive.

One of the earliest job postings for a role at AMZN, back when it was called Cadabra, stated that the company was looking for developers who “should be able to do in about one-third the time [what] most people think possible.” Jeff Bezos himself stated even while I was there that he wished the company could just move faster. It’s something I struggle with every day. On the surface, most features seem simple and straightforward. “We just need to be able to make a person run around the screen,” or “we just need to load a level and display it.” To someone who hadn’t done this, but had seen it done a hundred times before, it seems incredibly easy. It’s been done in countless games, why shouldn’t it take less than a day to get working?

But the devil is in the details, in covering all the edge cases. How do we ensure that the player doesn’t fall through the floor when they move? How do we keep them from running off the screen? Are they playing the right animation when they move? Are they sized correctly? What if they fall off a ledge? How do we load the levels? What if the level data is corrupt? What do we do then? Then, actually coding this up, testing the code to ensure that it works in every possible case and combination of cases, the complexity and amount of code quickly spirals and expands, and what seems like a 3 day task actually takes 9 days. No wonder Jeff wants people to do things in one-third the time.

This isn’t a problem unique to software. I have several friends who are actors, and if I use the Way-Back Machine, I can see a time when I acted in several High School theater productions. To an outsider, acting seems easy. Speak a few lines, look pretty, and then make tons of money and bask in fame. However, that’s not the reality at all. Actors have to focus on the meaning and purpose of every line, for there are at least a dozen ways to read “Hand me the keys, you -!” (That’s one of my favorite scenes from The Usual Suspects.) Which word gets the emphasis? Me? Keys? Hand? What’s the tone? Who is being spoken to? What’s their reaction? Actors also need to present a continuity of emotional state across a scene, which may take several days to film. Alternately, they may need to present a range of emotions across a 90-minute live theater production. They have to be realistic, believable, react appropriately without giving away anticipation (they know what the response to their line is, after-all), and usually with a potentially distracting live audience or film crew watching. As I learned filming and directing a music video for the Seattle band SMP, 3 minutes of on-screen footage might take two days of filming work. And the devil is in the details, in every frame, every motion, every mood, every line.

As the CEO, one of my advisors told me I only had two jobs: Keep the money flowing, and set a broad vision. Personally, I think I have a third job: Unblock my team, and enable them to create the best work possible. Understanding the complexity of their roles and tasks, finding ways to remove bottlenecks in ways that are not hand-wavy management speak, means diving into the details and keeping one hand in the code. Right now, I’m both Leader and Developer, but I can see my role shifting more towards the former and less towards the latter. Still, I don’t think I can ever step entirely away from the code, even as I hire up a development staff. Keeping an eye on the details means ensuring the right experience for our customers, and that’s the path to building great products and a great company, no matter how many devils have to be stepped on.

(This post has been edited to correct the quote from The Usual Suspects.)