On 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. As of November 2017, I still work at LiftIgniter. I’ve been part of the company’s journey through a somewhat shaky post-seed-round future all the way to a Series A round and a growth of team size from about 7 to 25 in nine months.
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.
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.
|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.
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, 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).
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 tens of thousands of 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.