Growth in the Big City (October 2011 — June 2014)
We spent the first couple of years as a team focusing on building a healthy, self-sustaining, long-term culture.
Building Culture
Some hallmarks of the culture that evolved were pull requests, daytime deployments, support dev rotations, all-hands incident response. The merits of all of these have been explored in far more depth elsewhere, so I’ll focus on why and how they worked for us at Kickstarter.
Pull Requests
When the team was small, pull requests were uncommon and always drew interest and attention. We embraced pull requests early because they allowed engineers to keep up to date on changes as they happened, learn from each other, apply style guide and testing standards, and yes, catch the occasional oversight or bug.
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
We were originally relying on fortnightly releases, scheduling them for windows of time when no projects were ending, and decided that enough was enough. Deploys were going to start happening during the day, in smaller pieces, and we’d simply have to figure out how. This is where our commitment to automated testing began to really shine through, because deploying during peak traffic hours requires frequent confidence checks that aren’t realistic through heavyweight QA processes.
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
When we began deploying during the daytime, personal accountability increased. Requiring each individual to deploy their own code all the way through to production meant that we avoided the trap of throwing code over the wall to a production or deployment team.
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
Like any other website with traffic and customer support, we had bugs and questions and unanticipated urgent requests. We found that our Support team had learned who was most likely to be helpful and would contact them directly for assistance. We loved the idea of supporting our Support team, but needed some way to ensure that the responsibility was shared appropriately. Our solution was a weekly Support Dev rotation. This person would shield the rest of the Engineering team from interruptions while also committing resources to the genuine needs surfaced by Support.
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
Kickstarter’s Engineering team remained small for quite some time, and to this day is smaller than people expect. This meant that we could avoid rapid culture shock and welcome each new hire into our team with something like an oral tradition.
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
At the beginning of 2014, I was ready to return to the Pacific Northwest when an opportunity arose to explore a dedicated leadership role. Our VP of Engineering was moving on, and we needed to search for a new candidate without losing all progress or fracturing the team. I’d turned the opportunity down years earlier, but had since then been able to work with an excellent VPE who’d offered me opportunities to engage in team and cultural discussions and even build a taste of management responsibilities.
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)
With a new VP of Engineering taking care of leadership needs back at New York HQ, I turned my attention towards proving that working remotely was viable. James refined and formalized our dual-track career ladder, and I found myself with a new title and more explicit technical leadership expectations.
Organizational Changes
Two noteworthy organizational milestones during this era were the adoption of cross-functional teams and a corresponding rise of specialists.
Cross-Functional Teams
Cross-functional teams were another organizational change that had been delayed by a prolonged inflection point. As with management, we knew that at some size we would need to make a switch to a feature teams model. We simply weren’t large enough yet to staff a full complement of teams in that manner.
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
During the first phase of our Engineering team we hired full-stack developers. Everyone had primary interests and emphasis, but knew that they’d be expected to work in secondary areas as needed. We prized self-sufficiency.
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
When settling on the initial cross-functional teams, we discussed concerns over who would own the Engineering Backlog, a slow-moving list of technical debt that tended to only get prioritized into gaps between feature development cycles. A few months later it was clear that the backlog needed dedicated attention, so I created a charter for a Platform Team and began working through the priorities. The early tasks were largely reactive, driven by periodic issues we were experiencing as a result of increasing spikes of demand on the platform. We also had a few critical system upgrades to perform that had been completely inappropriate for any kind of in-the-gaps development process.
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
When I began this journey, I thought that 2–3 years was a healthy tenure in startups territory. Every time someone else left Kickstarter, I wondered why I hadn’t. In recent months I’ve talked to others who expressed similar feelings about staying at a company longer than their peers or the perceived industry average. So far no one has regretted it.
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.
