Monday, which was the 16th anniversary of the end of one adventure and the beginning of another, was also my last full day at Danger, and not coincidentally also the last day of Danger. Yesterday it was officially part of Microsoft, but I was not, so I showed up early to drop off my security badge and free SIM, collect some checks, and leave for good.
To my great surprise, I was the only Danger employee to decline an offer from Microsoft to remain with the company.
Why was I? Certainly a big part of it was my well-documented distaste for Microsoft, but I was by no means the only one at Danger to feel that way. The fact is that I was already growing disillusioned with Danger even before the Microsoft announcement.
In January of 2003, when I had been at Danger for barely two months, I was moved to send the following message to my new engineering colleagues:
From: bobg
Subject: A different perspective
At today’s engineering meeting, and afterward in various individual discussions, I heard a lot of griping about the ambitiousness of [an engineering] schedule. I’m here to tell you: it’s a lot better than the alternative.
Before I came to work here, I was at a different company that for purposes of this message I’ll call Caution, Inc., because in a lot of ways it was the opposite of Danger. The managers were in thrall to a dysfunctional version of the software engineering lifecycle. The simplest feature had to have a requirements document, needing several iterations of meetings until all “stakeholders” could sign off on it; followed by a specification document, likewise requiring meeting after meeting to polish it to a high gloss; to be followed only when the spec was finished by an architecture document and still more weeks of meetings and sign-offs; and then implementation, testing, and release plans, each of which sometimes spun off recursive instances of the entire lifecycle. Only much later did you actually begin writing code; and for scheduling purposes even simple projects were scoped in terms not of weeks or months but entire quarters.
I think the whole idea behind getting everyone to buy in at each stage of the project was to have your asses covered when you finally wrote something to spec and a stakeholder had an objection. But what value in being able to say “You should have thought of that sooner” if the company goes out of business long before anyone gets a chance to object?
Needless to say, nothing got done. Not one damn thing. When I started at Caution, the team I was on was nearing its first anniversary of working on a project that involved nothing more than writing a Unix command-line interface to a web-based bug-tracking tool. The interface comprised four commands, each of which parsed its arguments, invoked two or three API calls, and printed some output. But they hadn’t completely nailed down the exact right behavior, so they had barely begun to write any code at all. After a year.
By the time I left eight long months later, that project was still not complete. There were other projects that came up, naturally, and from time to time I would surreptitiously whip out a complete, working implementation of something in an afternoon just to show how it could be done, only to be chided for trying to do an end-run around the process.
Once in a while something really urgent would come up and then we’d kick into gear, throwing the process out the window and invariably producing a satisfactory solution in short order, but overall, Caution was the very embodiment of the saying, “perfect is the enemy of good enough.”
How to describe how badly that sucked? Visions of immensity come to mind — Mt. Everest, the Grand Canyon, the Great Plains, the night sky, the federal budget — but nothing seems quite adequate. I’m a crackerjack programmer; I need to be building software all the time, not refining the illustrations in a months-old design document. At Caution, everything was slow, soporific, comatose. That company was in Santa Clara, and as many of you know, I live in Mill Valley. Doing that commute every day and having only that stultifying grind to look forward to was a major drag.
It came as no surprise to me when Caution suddenly announced it was laying off half the company (including me, mercifully) — nor that after the layoff, the company was pretty much able to continue doing what it had been, simply by revving up the speed of the people it had left.
What I’m trying to get at is this: you’ll always succeed at only a fraction of what you try to do. It’s better to dangerously try a hundred things and succeed at 25% than it is to cautiously try ten things and succeed at 80%.
As a newcomer at Danger, obviously I missed all the angst surrounding the delays leading up to 1.0. But let me tell you what I see: a successful, energetic company with an awesome product, abundant talent, great press, and many opportunities. If overambitious targets and always-imminent ship dates are what’s needed to achieve those things, then bring ’em on.
Before Caution, I worked at other exciting startups, including two that I co-founded — one of which was the Internet Movie Database, which a lot of you will recognize as a cool company — and I can tell you without hesitation that this is the gig I’ve been most enthusiastic about. The energy level, the rate at which things happen, even the sense of impending crisis — they all mean high stakes, something worth spending my time on. The daily commute to Palo Alto, which is almost as long as my terrible old commute, now strangely seems to go by in a flash.
I like having too much to do and too little time to do it in; it’s far more interesting than the reverse. Obviously there’s a balance to strike between danger and caution in the schedule, and maybe we’ve erred on the side of danger in the past, but that’s the right direction in which to err. Danger’s got a good thing going on here. When we do get enough slack in the schedule for the engineers to go off and figure out how we’d like to redesign everything, that’s when I’ll start to worry about the future of the company.
At that time, my message was cheered by many. Over the years, though, despite my best efforts to prevent it, Danger did eventually, inexorably transform itself into “Caution, Inc.,” bit by imperceptible bit. For the past few months my work there has consisted of almost nothing else besides preparing, revising, and reviewing engineering-process documents — and futile back-channel attempts to get things turned around so we could do some real work.
Some of my colleagues will be surprised to hear this, but it was mid-January of this year when I finally decided to throw in the towel, fully a month before we found out about the merger. As the author of the “Danger/Caution” missive I could hardly stay much longer without betraying my integrity. I only stuck around as long as I did to see Danger through to the very end (and also to reap some monetary benefits relating to the merger).
The same week that I decided Danger’s transformation into Caution was irreversible, this confirmatory omen greeted my eyes as I showed up for work one morning:
The very day that I learned 
