The Path to Production (Sept 2008 — April 2009)
The Kickstarter founders hired me in Sept 2008 to make things happen after a couple of false starts. Charles knew my previous co-founder, Rich, and discovered that I was between gigs and available for contract work. This was unrepeatable serendipity — at this point in a startup’s lifecycle you can’t find them, they find you.
Takeaway: Do right by your colleagues. Your reputation travels further than you expect.
When I started, I found that another contractor had a few days’ head start and had created the repository with a lot of generated scaffolding and authentication harness. Best practice in the 2008 Ruby on Rails community was to launch early and avoid premature optimization, so my first day was spent getting the code deployed to an EC2 server and my second day was spent taking inventory and deleting anything not in use.
Takeaway: Let your stakeholders watch from day one. Don’t make them ask what’s happening.
Takeaway: Keep the code clean. Don’t deploy code if you don’t know what it does or intend for it to be used. It’ll only get in your way later.
This was also the right time to make fundamental decisions about what would be best practice in the Kickstarter codebase. The most important early decision was a full commitment to automated testing with factory data. Our testing practices and skills and notions of appropriate test coverage evolved over the years, but we never regretted the investment. It paid off immeasurably: we still deployed bugs, but never the same one twice.
Takeaway: Force yourself to set up a testing harness early. Tests are not premature optimization, and missing tests are a debt no one wants to pay down.
Over the next seven months, we explored and implemented the Kickstarter MVP. The core feature set was surprisingly the most stable; we probably spent more time working on supporting pieces like user registration flows and private messaging.
Even then, the MVP was missing a significant component: our payments backend had no error handling! The system we were integrating was more complex than a typical payment processor and we were taking advantage of its unique three-party concepts to create an all-or-nothing delayed collection model. We didn’t have anything to reference, and of the dozens of error codes listed most seemed irrelevant or unclear.
When confronted with this blind spot, we decided to launch with a state machine and background jobs system that would allow us to identify and resolve issues as they cropped up. That turned out to be enough: we were able to identify and automate the core problems, and ended up taking advantage of the system to detect and fix edge cases for years to come.
Takeaway: MVPs can always be smaller.
Takeaway: If you can’t solve a problem now, be sure you’re collecting the data necessary to solve it later.
On April 28th, 2009, we opened up to the public. It was a quiet launch, but within a week we had our first successfully funded project and a handful of super-early adopters. If programming appears like magic to others, I hope they take comfort knowing that building adoption for the product looks like magic to me.
Keeping Up, Falling Behind (May 2009 — April 2010)
In the year that followed, we ran a lean operation while the site gathered momentum. Shortly after launch, my engineering colleague Carson decided to move on. Perry was focused on Product, Yancey was focused on community, Charles was focused on IA/UX, and Andy stepped into the CTO role to alleviate some pressure. Kickstarter made a couple of other key hires, but on the product side I was working mostly solo on the full tech stack.
Working solo was very efficient since the only person I needed to communicate closely with on technical issues was my future self. But it meant that we could only make progress on one thing at a time. Our MVP needed attention in a dozen places at once, and we couldn’t afford deep dives or robust solutions on any single issue. Changes needed to be precise and surgical, leveraged to full effect without creating unnecessary debt.
Takeaway: Efficiency is not the same as productivity. An individual can be surprisingly efficient, but is still a bottleneck.
The fact that this worked at all is a testament to Ruby on Rails. It optimized heavily for developer productivity — Ruby on Rails’ system of organization and implementation of MVC, however imperfect, meant there was nearly always an obvious place to make any given change.
Takeaway: Use a framework, and learn how it wants you to think. Work within the system even if it’s not perfect. Consistency is its own virtue.
It’s also a testament to the emerging services ecosystem. We made early-adopter bets on external vendors for key things like email delivery, video transcoding, managed hosting, and application monitoring. For example, the OSS video encoding platform we used to launch was eventually abandoned and I spent close to a month exploring a home-grown FFMPEG solution before admitting it was not a good use of time and settling on Zencoder.
Takeaway: If you can pay another company to be an expert on one of your problems, do it. It doesn’t matter if you could have done it yourself, because now you won’t have to.
The time had come to hire.
Teaming Up (May 2010 — September 2011)
The Kickstarter team was originally distributed across the continental US, but the new hires in late 2009 were all based in Brooklyn. When Perry approached me to check my interest on hiring up and leading an Engineering team, I said no for three reasons:
- I had little experience with it
- I planned to stay in the Pacific Northwest
- I didn’t believe in a single-track career ladder
So Kickstarter hired Brett. He focused on hiring, product, and company strategy which left me free to focus on the tech stack. This was a division of responsibility that foreshadowed our eventual formalization of dual-track management/technical leadership.
Takeaway: Organizational hierarchy is not always correlated with organizational impact, especially at small and medium companies.
This transition was tough. As the only remote employee, switching from a solo to team-centric mindset initially left me defensive and stressed. On the one front, the company was changing without me and I was hearing about product plans after they’d been mostly decided. On the other, I was confronted by changes to the system that I had not authored, and opinions that did not match my own.
I soon discovered that I was looking at it wrong. Every person that joined the team relieved me of ownership on some piece of the stack, and was able to focus on it with more depth and expertise than I had been able to allocate by myself. This was an opportunity! In this new environment, I could learn from my colleagues’ expertise while building my own on the topics still lacking dedicated attention.
Takeaway: Adapting to change requires recognizing it, admitting what’s hard, and deciding whether you can be happy with new expectations.
This turned out to be a much healthier mindset and the foundation of my technical leadership style in the years that followed. I still missed feeling connected to the key conversations though, and after consulting with Andy, decided to move to Brooklyn and re-commit.
Eight Years of Kickstarter is concluded in Part Two, with reflections on key milestones of organizational growth.
