Eight Years of Kickstarter (2 of 2)

A reflection on organizational growth inside a bootstrapped startup, as told by the first technical hire. Continued from Part One.

Growth in the Big City (October 2011 — June 2014)

Building Culture

Pull Requests

Pull requests allowed our team to remain aligned on what we considered good code. The open forum nature of the conversation meant that we could consider ideas, find agreement, and assume most everyone had been following along. In situations where the pull requests happened too late in the development cycle to permit incorporating all of the feedback, the discussions were still worthwhile for team alignment on future work.

It wasn’t until somewhere around 10–15 active contributors that the number of pull requests created enough volume that people began to unsubscribe from the firehose and we could not rely on the discussions reaching a general audience. We eventually adopted an internal RFC approach similar to Swift and Rust, but were years late realizing the necessity.

Takeaway: The methods that a team relies on to remain aligned will change over time. Informal communication needs to formalize, and at some point the outcomes need to be actively taught and socialized. Somewhere around a dozen active participants may be a good first inflection point.

Daytime Deploys

This was not an overnight success. We had gaps in the test suite that needed to be shored up. We were missing visibility into important processes, and had to develop a hierarchy of business and system metrics. We learned through trial-and-error how to make database schema changes with confidence. We invested in shortening the time between pushing a commit, getting a green build, and deploying all the way through to production. We built up expertise and tools that allowed us to react to all the variability of AWS cloud computing. And we learned how to use feature flags for gradual rollouts and confidence testing when all of the rest was not enough.

It was worth every bit of effort. Smaller changes are less risky, and every minute that we invested in the tooling and expertise paid dividends in increased productivity by allowing our small team to retain momentum during work hours and actually go home at night.

Takeaway: Work during work hours. Figure out how to make that happen.

All-Hands Incidents

It also meant that colleagues were more available to help each other respond when things didn’t go according to plan, which could have been a recipe for blame and risk aversion but instead helped to bond the team together. We already had an “in it together” mindset, but what really made this work was adopting blameless postmortems from our friends at Etsy. This style of postmortem gave anyone who messed up a chance to come clean, feel the support and acceptance of their peers, and share what they learned from the experience.

Takeaway: The only thing more cathartic than learning from your own mistakes is teaching others how to avoid them in the first place.

Support Dev

This role grew over time. The most recent iteration as of this writing calls for two people with mixed levels of expertise to work together on Support requests and bug reports as a full-time commitment for one week.

Takeaway: Find some way to cultivate a healthy and sustainable relationship between Engineering and Support. It’s possible.

Growing Pains

But it also meant that we didn’t have to invest in more repeatable processes and documentation. New hires were far enough apart that onboarding was unrepeatable and could be hit-and-miss, with the lessons learned from each faded by time before the next hire.

It also meant that we lingered in organizational transition zones for longer periods of time. During this particular growth phase, we faced challenges with the desire (or explicit lack thereof) for management. We all agreed that management would become necessary at some size, but we disagreed about how long we could postpone the inevitable. The decision was more difficult than a typical fast-growth startup because the inflection point was prolonged.

We initially hired for autonomous mid- and senior-level experience. This demographic can skew anti-authoritarian and see non-contributor roles as organizational overhead. Individual contributors in a flattened hierarchy can also enjoy benefit from greater participation in the conversations that affect them most. Regardless, we eventually made a small step towards management for a number of reasons:

  • Our flattened management hierarchy was not scalable.
  • Our environment was not friendly to junior engineers: existing management resources were already stretched thin by the fairly autonomous team we’d hired.
  • We had people genuinely interested in experimenting with management, but no opportunities for them to learn and grow.
  • We were at risk of not having in-house talent to promote when the role became more obviously critical.

Our solution was a lateral promotion for senior engineers that placed them in a hybrid management/contributor role. This gave the team an outlet for management interests, created some basic scalability, and allowed us to begin offering a higher level of support to engineers. We also intentionally set up the management relationships to avoid de facto functional units, so contributors would see managers as peers rather than authorities. This seemed like a stable solution for our current size that could naturally grow into specialized roles as the team expanded.

Takeaway: Organizational change is hard, especially when it feels like you’re off the beaten path. Communicate reasons, listen authentically to concerns, and design some experiment or compromise that can be rolled back or scaled up.

Interlude

The time was right. Kickstarter needed interim leadership and I found myself surprisingly interested, especially given the escape hatch of moving back West. So I made a clean break from individual contributions, joined the executive team, and dedicated my time to the team and the company for half a year.

The experience was invaluable. Rejoining product and strategy conversations renewed my passion and ambition, and focusing exclusively on the team’s evolving needs and challenges allowed me to explore new strengths and weaknesses. I made a few solid contributions while not mucking things up terribly, and was then able to step back and observe how James, our next VPE, resolved the challenges that had eluded me.

Takeaway: Your idea of a career may change after even a few years. Don’t mentally lock yourself (or others) into a single role for all time.

Bringing it Home (July 2014 — October 2016)

Organizational Changes

Cross-Functional Teams

That’s when we hit on the notion of organizing teams around user types. Kickstarter is a three-party platform, so we created three matching teams (Backer, Creator, and Admin) plus a couple specific feature teams (Payments, Ops). This structure allowed us to more easily reason about staffing decisions and commit ourselves to continuous parallel development in key areas. Each team was also fully staffed with representatives from departments like Data and Support, to improve transparency and collaboration across the whole company.

Takeaway: Even small and medium companies can find creative ways to organize into groups. The trick is in deciding how many teams you can staff and then grouping features together to match.

Specialists

Cross-functional teams allowed that to change. We now had a mechanism for matching people together for the duration of a task, and soon realized that it was time to hire frontend specialists. We’d always had one or two, but they were forced to act more like evangelists and educators who could enable the primarily backend team to participate across the full stack.

Hiring more frontend engineers and allowing them to specialize immediately elevated our expectations for what we could accomplish. We gained the capacity to consider and invest in solutions that may have a learning curve, thereby improving the maturity of our tech stack.

Takeaway: Specialization may not seem compatible with a lean team, but even a small company should consider hiring key specialists for areas that are at risk of being neglected due to high minimum levels of expertise.

Platform and Architecture

Once we got ahead of the reactive fire-fighting and made solid progress on proactive fire prevention, we finally had the stability and space to reflect on where our monolithic code base had succeeded and failed and where we wanted to go next. At the top of the list was a long-delayed discussion of Service Oriented Architecture and a corresponding investigation into alternative tech stacks. These architectural discussions, combined with a couple of investments into updates on the core models and associations, defined the rest of my tenure at Kickstarter and lead directly into the chapters that I now leave others to write.

On Longer Tenures

There were multiple moments where I worried that I’d overstayed my welcome, or nearly let a transition point get the best of me. Instead, thanks to the support of my family and colleagues, I was able to discover new and unique opportunities around each corner.

I’d encourage anyone to search for a startup that offers a career, not an equity-driven shell game. If you believe in the product and the mission, your contributions and satisfaction will only increase with time. There is no perfect job, and everyone has different opportunities. But when you find something that works, where you can grow and reinvent yourself, don’t question it — stick around and see what happens.

Startup engineer. Currently building @EmpaticoOrg. https://cainlevy.net

Startup engineer. Currently building @EmpaticoOrg. https://cainlevy.net