LiftIgniter experience

On Monday, August 18, 2014, I started my first full-time job at LiftIgniter, a Y Combinator-backed startup that at the time had three other employees. In February 2020, LiftIgniter was acquired by the Maven Coalition, and so, starting Sunday, February 16, 2020, I became an employee of the Maven Coalition (the acquisition was formally completed and announced in March 2020). After the acquisition, I continue to work on the product and technology coming from LiftIgniter.

How I got the job

I had known Indraneel Mukherjee, the CEO of LiftIgniter, for a long time. We first met at the International Mathematical Olympiad Training Camp in India in the summer of 2003. Later, we met while pursuing undergraduate studies in mathematics and computer science at Chennai Mathematical Institute (Indraneel was a year senior to me).

Indraneel and I fell out of touch for several years after that. Indraneel pursued a Ph. D. in machine learning from Princeton, and then went on to do internships in finance and work at Google, where he was a founding member of the team for Sibyl, Google’s internal machine learning tool used by YouTube and a number of other Google services to select recommendations and advertisements. In 2013, Indraneel left Google and started working on Petametrics, that would later become LiftIgniter.

In April 2014, Indraneel contacted me to do contract work for LiftIgniter on some machine learning mathematical problems. As I was hoping to transition to machine learning and data science work, I enthusiastically took this up. In August, as the project was wrapping up, Indraneel told me that a spot had opened up in the company for a machine learning/data science role. After some thought I took it up. At the time the company had three other people, and was still figuring out how to obtain steady, actual, paying customers and build a product that was actually useful.

Progress

The months before and after my arrival were rocky: some of the very talented people who contributed most to the early shape and infrastructure of the company left after realizing that the day-to-day work wasn’t a good fit for them. At the same time, we were working hard to get our product and our business in shape and have actual customers who paid on time and generated recurring revenue. Over the next few years, we made significant improvements to the product, hiring process, and customer acquisition and sales process. One other person who joined around the same time I did, and played a key role in shaping the business and sales strategy, was Adam Spector, who joined as head of sales and business development.

Here’s how the key metrics played out between my joining and our Series A round in 2017. Numbers are approximate and based on loose judgments of roles. Some people may be double-counted across roles.

Metric 2014 2015 2016 2017
Team size 4–5 4–6 5–8 6–25
Engineering team size (exclude only-customer-functions people) 3–4 3–5 4–6 5–10
Engineering + customer support (technical/product side) 3–4 3–5 4–6 5–12
Sales and business 2 2 2–3 2–12(?)
Revenue Nonzero Nonzero–Exceeding infrastructure costs Exceeding infrastructure costs–Slightly profitable Slightly profitable–Unprofitable as focused on expansion
Tech progress Something basic Move to realtime system; documented SDK and API Cloud best practices (autoscaling etc.), cost optimization, expand documentation Move to Google Cloud; robustify infrastructure, notifications and alerting
Customer support Not enough customers Launch basic support system managed by engineering team Support is focus of data-focused (as opposed to infrastructure) engineers Separate hires for customer support/success, as product matures enough
Funding Raise seed funding Burn part of money Burn a bit more but reach bare profitability to stop burning Raise Series A
Office space Subleased desks from another company Subleased–Own office (subleased out unused parts) Own office (subleased out unused parts) Own office (subleased out unused parts)–Two own offices, 75%+ utilized

Effects on me: transition to first full-time employment

Prior to starting work at LiftIgniter, I was doing contract work, where my work schedule was completely determined by me. Before that (until December 2013) I was a Ph.D. student, juggling research and teaching activities; you can read more about my graduate school experience here.

I had harbored some uncertainty about my ability to adjust to a full-time job and its daily rhythm, but I did not find it hard for the most part. In some ways, it was easier than contract work, because it was always clear what work to do and there were external motivators and factors driving the work.

I was quite fatigued with work by the time of the first Christmas break. Because we had very few customers at the time, it was a very relaxed Christmas break, with none of us in the office for about ten days, and only a little bit of work being done at home.

Qualitative changes in my work

Here’s how I’d describe my own work over the years:

  • 2014: This year was mostly spent ramping up on the product, and on my own workflow and understanding of both programming and data science. This was also the year I started getting a sense of what a work rhythm is, and how startups and businesses work.
  • 2015: This was a year of intense work on coding and building out the product, as well as beginning to talk to and support customers.
  • 2016: This year was mostly focused on supporting a growing customer load while also juggling minor product improvements. While I became more efficient at writing code, my role moved more to supporting customers and doing data analyses to help us win more business, while helping coordinate and support the coding work done by my other team members.
  • 2017: This was the year we raised Series A and expanded the team significantly. Customer support and success were now the responsibility of a new team of individuals located in a second office in Roseville; for the second half of 2017 I transitioned a lot of responsibilities to that team and engaged in knowledge transfer. At the same time, as the engineering team (both infrastructure and machine learning) grew, my role shifted to coordinating and planning the work of the machine learning team, as well as offloading some of my existing infrastructure responsibilities to the new infrastructure team members.
  • 2018: This was an interesting and turmoil-driven year. It included the departure of Indraneel from LiftIgniter and the transition to a new CEO and executive team. The entire sales team changed, and there was also some churn on other fronts.
  • 2019: This was mostly a continuation of 2018, but a relatively quieter year. Business growth was slower, but that also meant more time to strengthen the infrastructure and customer processes. There was a fair amount of churn on the customer support side, but enough continuity that we could function well.
  • 2020: In mid-February, LiftIgniter was acquired by the Maven Coalition (technically, this was an “asset purchase” rather than an acquisition). The deal was completed in March, but the employees had started working for Maven from February 16 onward. In some ways, this ends the LiftIgniter saga, though in others, the saga continues, because Maven would continue to let the LiftIgniter technology and product keep running.

In terms of the amount and stressfulness of work, I’d say:

  • 2014: The amount of work was least at this time, though still stressful because it was completely unpredictable, like groping in the dark.
  • 2015: There was a huge amount of work at this time, and it was quite stressful, with a lot of the stress coming from the uncertainty around how that work would translate to success.
  • 2016: The work was fatiguing but less stressful. We were in a good position for a seed-funded startup. The fatiguing part of the work came from the fact that with our small team, handling the existing load was not sustainable in the long run.
  • 2017: I’d say that in some respects, this was the year I worked hardest compared to previous years, but the uncertainty around the work was the least. This was the year where there was a clear path forward for the work: the work I was doing was centered around improving things in a way that would make the entire system more efficient. It was also the year when I took my first major vacation from work, since the team was big enough to function smoothly without me. With that said, some new sources of stress in 2017 were the larger team size creating much more team-driven interruptions to my work. Partly to deal with this, I switched my schedule to start the day earlier than the rest of the team. I also worked to improve my discipline around being responsive on Slack (on the plus side, less need to monitor support load because the new team took that over).
  • 2018: I probably worked harder this year than previous years, and was also more stressed out in some ways by the enormity of things. On the plus side, I made a lot of progress in seeing patterns around setting up better processes, and many of my colleagues (hired in 2017 and 2018) ramped up quite a bit, making my life that much easier. While most of the process innovation is private and can’t be shared here, I did blog on LessWrong about daily updates, about one of the work-tracking innovations.
  • 2019: I worked a little less hard than in 2018, but probably with comparable or higher output, because I was more calm on the inside. One major improvement was that hiring a remote person who worked during our nights meant that I was very rarely interrupted by night-time alerts.
  • 2020: The first 1.5 months were quite stressful as we dealt with even more departures as well as due diligence for an ultimately failed acquisition effort (luckily, we were able to quickly pivot to getting acquired by Maven).

One way of summarizing these transitions over the years is that the problem shifted from things being uncertain and worrying because nobody else was around, to things being occasionally overwhelming because others were around and could benefit from my help. This loose summary, applied respectively to customers and team members, explains the transitions over the years.

Effects on non-work life

The earnings from the job allowed me to improve my improve my financial situation, and in particular ramp up my savings. Although not the most lucrative job possible, it was a reasonably well-paying job and put my finances in a better state than they had previously been. This allowed me to fund contract work to the tune of over a hundred thousand dollars, to help push forward projects I was interested in but didn’t have the time or resources to engage in myself.

Some of the things I learned and thought about as part of my job influenced wikiHow articles I wrote related to Amazon Web Services and web traffic patterns, though none of these articles used any information unique or proprietary to my work.

My experience at work has given me some general skills at getting things done, coordinating with people, and dealing with uncertainty. I have applied these lessons in other contexts, like managing contract work. The knowledge transfer likely flows in the other direction as well.

Seeing the challenges of making a large, complex system with millions of dollars invested into it actually work efficiently, has given me better context for evaluating claims by others about how their organization or business operates.

Dealing with the business and work world in my day job has made me less interested in epistemic nitpicking in other contexts (think nitpicking in the style of LessWrong comments). I wasn’t too much into nitpicking even before that, but my day job has pushed me away from that to focusing on the important points in discussions. Relatedly, my experience in the work world has made me less inclined than I was before to believe in the claim that the most persuasive writing neutrally surveys both sides of an argument.

The busy nature of work life reduced my non-work socializing from a fairly low level to almost zero. This was not a necessary consequence of work life; it is just that I didn’t have a strong attachment to non-work socializing, so the somewhat reduced time for it was enough to tip the balance.

Basic information