I was fired from HubSpot in 2016

Originally posted 2022-12-30

Tagged: personal, software_engineering

Obligatory disclaimer: all opinions are mine and not of my employer


There, I said it.

When it happened, I was embarassed. I felt like it’d been my fault and that I was deficient somehow. I didn’t tell anyone why I’d actually left HubSpot for a year, and it took a few more years for me to speak candidly about it with coworkers.

Today, I look back at that experience and think it was honestly the best thing that could have possibly happened to me. But it certainly didn’t feel that way at the time.

Getting fired or laid off is pretty trendy these days, so I hope that my story inspires at least some of my readers to help process and to look forward.

Starting at HubSpot

I joined HubSpot in 2014, not long after I dropped out of graduate school. At the time, my coding experience consisted of building a website to coordinate college Go tournaments, using Django. My job interview for HubSpot consisted of one interview in the morning (the second interviewer didn’t show up), and a chat with the engineering director who offered me 80k on the spot. I told him that I’d had another offer at 95k, he bumped my offer to 90k, and we shook hands. I don’t even think it was noon by the time I walked out of the building. It still blows my mind how quickly HubSpot moved at the time, compared to what I’ve seen at Google.

HubSpot’s CMS backend was in a state of transition when I joined. They had a legacy C#/MSSQL system and an actively developed Python system, with all new customers being started on the Python system. My manager had written some SQL to dump the database contents and was prototyping a data migration tool. My job was to continue picking through the carcass and make the right API calls to reincarnate customers’ websites in the Python system. Another team would manually fix the tool’s output and Q/A the customer’s new website before activating it. After spending a month onboarding me, my manager handed development of the tool over to me and moved onto onboarding the next new hire. I was very lightly managed and made steady progress on the tool, expanding its capabilities.

9 months into my first job, I decided I would kill the legacy Forms system.

The Migration

At this point, I should mention that HubSpot’s business at the time was selling Inbound Marketing. In short, Inbound Marketing meant: write useful content, get Google search result clicks, collect email addresses via a form, and then court customers by email, all without having to pay for ads. HubSpot sold the website builder, blogging platform, contact database, and email platform to execute this strategy.

That Forms system I was going to migrate? It collected email addresses on behalf of our customers, and was the linchpin of HubSpot’s business value proposition.

I talked to several eng teams to figure out how both the old and new Forms/Contacts APIs worked, and reverse-engineered quite a bit of JavaScript. The migration strategy, at the time, was to copy-paste the raw HTML <form> element and a minified JS blob (for which the source had been lost) into the migrated page, allowing the form to continue submitting to the legacy Forms API. This strategy had a number of drawbacks. Customers couldn’t edit their forms; the CSS was unmaintained, so all of the fields and buttons looked out of date; the old Forms API had to be maintained and the discrepancies resolved on the backend. On the other hand, the newest Forms API had no such drawbacks and offered integrations with HubSpot’s latest features.

Eventually, I crafted a new migration plan involving BeautifulSoup, lots of experimentation with a test account on the old/new systems, and a close partner on the Q/A team. After several very carefully monitored migrations and iterations with our Q/A team, I’d found and implemented migration rules for all of the obscure form field types (file upload fields were particularly annoying!). Another twenty clean manual runs later, I flipped a switch to route all customer migrations through this codepath.

After the migration tool ran bug-free for a month, I turned my attention to all the customers that we’d previously migrated with the HTML copy-paste solution. Conveniently, the HTML blob was migrated as-is, meaning that I could just point my parser/migrator at the HTML blob. This time, I worked directly on the live customer websites, without a Q/A team safety net, and within a week, my script had worked through all of the post-migration customers. The stage was set for the old Forms API to be killed alongside the C# servers as soon as all customers were migrated. Success!

Migration Aftermath

For a month or two, nothing happened.

One day, a PM frantically came over to me, asking me what I’d done to everybody’s forms. My stomach dropped and I thought, “ah, fuck, what did I miss?”. I explained how I’d executed the migration. The PM, fully appreciative of the risks, spent the meeting white-faced, instead of congratulating me as I’d been hoping.

It turned out that there was no major problem with the migration. The only reason that the PM had even noticed was that customers were wondering why the form submission rate analytics had stopped and reappeared under a different form with identical naming. Messaging then went out to migrated customers telling them that this was an expected side effect of migrating data to the new systems. Had it not been for the PM panicking, my migration would have gone entirely unnoticed.

A week later, I got a shoutout at the product team monthly congratulating me for migrating the old forms to the new system.

Looking back, if I had to do it again, I’d have more precautions in place, and seriously consider leaving the situation alone.

Getting Fired

With diminishing returns to working on the migration tool, I was moved onto a new team and a new manager. At the same time, management acknowledged the unsustainability of managing (or not managing, in my case) so many junior engineers, and decreed that for junior engineers, it was up or out.

My new manager assumed I was incompetent because I hadn’t actually learned how to communicate technically. He decided the solution was to micromanage me, which resulted in my productivity dropping to zero. After several months of this mutual frustration, he PIP’d and fired me. Despite the ambitious and flawless migration I’d pulled off, nobody knew enough about it to vouch for me.

To be honest, I’m not sure what I would do with myself if I were in my ex-manager’s shoes. Firing me was probably not the ideal solution, but something had to be done as the existing situation was untenable.

Afterwards, I ambiguously explained that I’d “left” HubSpot. Even to my closest friends, it took me a year to open up about it. With the benefit of six more years of job experience, I see now that there was really nothing to be ashamed about. Bad manager-report dynamics happen and the ability to successfully navigate them really only manifests at the senior level.

Moving on

In retrospect, getting fired was probably the best thing that could have happened to my career. When I visited HubSpot five years later, my old coworkers were, by and large, working on exactly the same systems they’d been working on five years prior. It seems like employment at HubSpot is weirdly sticky, although their great stock performance from 2016 onwards probably has something to do with it. If I hadn’t been fired, I might still be at HubSpot to this day, working on content scrapers and migration tooling!

My work situation at HubSpot was tremendously morale and energy draining, and I’m grateful that somebody told me, “It’s over. Stop fighting.” I’m not sure I would have been able to extricate myself from that situation otherwise.Afterwards, I had the mental space to sincerely consider what I wanted to do next. That’s how I got started on machine learning and (spoiler alert) ended up as a tech lead at Google Brain.

Like some cheesy movie epilogue, I ended up running into someone from HubSpot’s ML division at NeurIPS 2019, and heard that my old manager was now working in ML. Seeing what could have been, I’m doubly glad I was fired!

The year I spent teaching myself ML and building a Go AI remains one of the most fulfilling years of my life. If you find yourself in a similar situation, I highly recommend the Recurse Center as a place to pursue that project you’ve always wanted to work on.