“Never mistake activity for achievement.” ~ John Wooden

The software project that haunts me the most was a single-sign on implementation that I did for O’Reilly. The project was handed to me, partially done, with the instructions, “These three things need to be finished, do you think you can do them so that we can launch in two weeks?”

The three things didn’t seem hard, so I said yes. I think it takes some experience to recognize that there’s a huge red flag in that question. I was answering, that, yes, I could complete those three things in short order. How would I know, having never looked at the project, whether those three things were sufficient for launch. In the course of the next two weeks, three more unfinished things popped up and the launch date was pushed back two more weeks. Then more missing features and bugs were found. And again. After three months of this I was racked with guilt over the missed launch dates.

I went home that weekend determined to figure out how to get the project on track. I was basically a junior programmer then and had no idea how to run a project. So I bought a book on project management, Rapid Development by Steve McConnell, and cracked it open. The book opens with 36 Classic Mistakes Enumerated. I checked off 17 mistakes for the project and was hooked on the book for the rest of the weekend. When I went to work on Monday, I hid out in an empty office on a different floor and spec’d the project for myself. According to my rough spec, the project had at least 180 function points and I had completed 90 over the last three months, leaving 90 more to do. Would we be launching in two weeks? Definitely not.

For a long time, this was the project I was most proud of. I used my spec to pull the project out of the weeds and onto a realistic schedule. A lot of good things came out of that weekend of reading. For one, the project got on track, a realistic launch date removed my late-project guilt, and the launch was a technical success. It also gave me a lot more work options: I got more respect at that job, I got opportunities to make bigger decisions, and that led to opportunities to work for some pretty cool startups. Then one day I asked myself: why were we building a single sign-on system?

Mixing some metaphors about nature and total ignorance, I had gotten out of the weeds only to see trees. Years later when I could see the forest, I realized that my proud moment hadn’t accomplished anything (minor convenience for a small population of users, inconvenience/confusion for a big population of users). The goal of the project was actually to allow for a second phase around business intelligence or some such thing. That never happened and I’m told now that the system is now being phased out.

“Being the richest man in the cemetery doesn’t matter to me. Going to bed at night saying we’ve done something wonderful, that’s what matters to me.” ~ Steve Jobs

Ever since that realization, I’ve been working to figure out for myself how to maximize the impact of the work I do.

There’s a good discussion of what constitutes startup success over on Gabriel Weinberg’s blog (and the discussion is basically what prompted me to write). It goes over various scenarios for startups and tries to judge if they would be considered successful. Obviously a long running company that made millions of dollars for the founders and investors is a success. What about one that made a lot of users happy but didn’t make the investors any money? What about one that made everyone money in an acquisition but then was immediately shut down?

I just don’t think I could ever call my work successful unless people used it. I don’t want to be merely well paid. I don’t want to write great code that doesn’t get used.

There’s a logical argument to be made that taking part in a system that produces one google and nine failures is a way to maximize your impact. But I couldn’t handle that unless I was working on Google. I don’t want to look back on 30 years of work and realize that only three of those years mattered. That means I care about consistency of impact as much as I do about the magnitude of impact.

I think there’s a lot of other personal preferences in working out a way to optimize your work. Here’s where my preferences led me:
1. It’s better to be in control, at least of your domain, but better the company. It’s rare that anyone else has tasked me with a project that mattered.
2. Sustainability matters. The main reason I stopped working for venture backed companies is because investors introduce so many more ways for your project to get die an early death (small/medium successes get dropped and small/medium acquisitions often get killed).
3. Compounding interest works. The first two years of CrowdVine were very limited. Now, with some revenue and a few more people, there’s a lot more that we can do.

That’s basically why I bootstrapped CrowdVine. Not all the trade offs are good, but it’s the first job I’ve had where every day of work mattered. And I think that’s pretty fun!