To buy time for a failing startup, recreate the engineering process

In non-aerobatic fixed-wing aviation, spins are an emergency. If you don’t have spin recovery training, you can easily make things worse, dramatically increasing your chances of crashing. Despite the life-and-death consequences, licensed amateur pilots in the United States are not required to train for this. Uncontrolled spins don’t happen often enough to warrant the training.

Startups can enter the equivalent of a spin as well. My startup, Kolide, entered a dangerous spin in early 2018, only a year after our Series A fundraise. We had little traction and we were quickly burning through our sizable cash reserves. We were spinning out of control, certain to hit the ground in no time.

Kolide had a lot going for it that enabled me to recover the company, but by far the most important was that we recognized we were in a spin very early, and we had enough cash remaining (and therefore sufficient time) to execute a recovery plan.

All spins start with a stall — a reduction in lift when either the aircraft is flying too slowly or the nose is pointed too high. In Kolide’s case, we were doing both.

First, we raised too much money too fast. In order to justify the post-money valuation that came with the raise, we set unattainable goals. To make matters worse, we lacked the confidence in our product and strategy, so we developed our solution with hesitancy, underspending in critical areas. As a result, we were flying too steep and too slow. We stalled.

If a stall isn’t corrected promptly, a spin can develop. Flat spins are one of the worst. Once the flat spin starts, there are a number of techniques experienced pilots should perform to recover the aircraft. Nearly all of these techniques require a critical resource, altitude — or, put another way, time.

Just like amateur pilots, startup CEOs don’t receive spin recovery training. When Kolide was spinning out of control, the vast majority of the advice I received was to cut our losses and sell the company or return the money to the investors.

At the time, I didn’t find any promising examples of companies with these same problems successfully recovering; I found only smoldering wreckage. By February 2019, my co-founders departed.

Despite this tell-tale sign of imminent demise, I was ultimately able to recover and put us on track for a great fundraise. Here’s how I recreated the engineering process.

Buying time

Kolide had a lot going for it that enabled me to recover the company, but by far the most important was that we recognized we were in a spin very early, and we had enough cash remaining (and therefore sufficient time) to execute a recovery plan. Even waiting just a few more months would have likely changed the outcome.

While we had a good amount of cash, I knew we had to maximize how much time that cash could buy us. This meant cutting costs to the bone, and then sawing the bone open and cutting costs some more. Like most SaaS startups, our two biggest drivers of monthly net burn were personnel (and related expenses) and cost of goods sold (in our case, Google Cloud Platform). As part of our reset, we quickly cut more than half of our staff through layoffs and spun down any infrastructure powering canceled R&D work.

Unexpectedly, reducing staff had another benefit: We were much more agile. The sudden sobriety gained through the loss of our former co-workers made us laser-focused. At the start of our recovery, I set a goal for us to build a brand new product from scratch in 10 weeks and get our first sale in 14 weeks. The insanely aggressive timelines and the real restrictions it imposed allowed us to optimize our team decision-making and directed all of our energy toward the essentials. As an example, we didn’t build our Stripe billing integration until after we launched; we didn’t need it until our first users’ 30-day trials expired.

To my amazement, despite never hitting our engineering dates before in Kolide history, we easily hit these new ones and produced something far better than we had released previously.

Finding a market

With the time problem solved, an equally massive one remained: lack of vision. While we were moving quickly in engineering, we were essentially building a better and more refined version of a product that we had made before. A product that ultimately did not sell well the first time we built it. Therefore, the second part of our recovery was to diagnose why our original product vision wasn’t working and come up with something substantially better.

Given our compressed 10-week timeline, I had about four weeks before all of the “table stakes” features essential to all SaaS products (authentication, team access, search) were completed by engineering. After that, the team would be champing at the bit for mocks, stories and other collateral needed to complete the engineering of the primary features.

I did the only thing you can do in that time frame. I picked up the phone and just started calling anyone I could. I talked to our former customers, I spoke to independent consultants who were deploying the open-source tech our solution relied on, and I spoke to organizations that rejected existing commercial solutions and built homegrown tools.

There were three events that occurred around the same time that allowed me to home in on what would be our differentiator.

The first event was a phone call with a 60-person startup that had built its own IT/security solution to solve compliance problems in a way that didn’t violate the privacy of end users. The startup’s IT team lead spent a generous 90 minutes on the phone with me walking through the unique problems they faced that were not being addressed by existing commercial solutions. Interesting.

The second event was reading a Netflix blog post about its own homegrown security tools. Unlike commercial solutions, which normally lock down devices to prevent problems proactively, Netflix’s tool instead recruited end users to help solve security and IT issues themselves. It was an extremely novel approach that I had not seen before.

The third and final event was when a Kolide engineer — who had been directed to work on what I thought was going to be a generic Slack notification interface — excitedly pulled me aside to show me how far Slack’s platform had evolved and encouraged us to consider a much richer Slack notification experience.

These seemingly unrelated events attached themselves into a cogent idea, one that would eventually lead to us defining a new product category called Honest Security.

We came up with an MVP experience, and, while building it, began validating against the contacts we already had. By the time we launched, we had iterated the experience multiple times, swiftly changing it in response to feedback from our earliest prospects.

Resuming flight

The drastic approach that I took to recovering our company is often referred to as a “full reset.” In a reset, the old company is essentially annihilated and a new company is formed from the remaining pieces. The biggest thing a reset does, though, is not just reset the company symbolically; it also signals to investors a reset of expectations. The sins of the past are mostly forgiven and the company is judged on its performance as if it’s a completely new team.

This reset of expectations allowed me (and our stripped-down team) the latitude to change our angle of attack to one that had realistic and achievable goals. As we amassed the earlier token victories (meeting our launch date, our first sale), our confidence grew — and so did our ability to achieve more meaningful goals that were consistent with a Series-A-funded SaaS company.

Before we knew it, we had nearly two years of growth and progress as the “new” Kolide. Most importantly, we had the evidence for outsiders to draw accurate and meaningful conclusions about our future and make a prudent decision to support us. We are officially out of the spin and fully aloft.

That brings us to today, on the brink of starting the process for our next fundraise. Not because we need to, but because we want to — and we have the traction to prove it.