Moving from academia to industry #

I left academia in 2015. Having completed a PhD and a postdoc, academia was all I’ve ever known, making the transition to industry bumpy: I knew that academics’ productivity is measured by how many research papers they produce. But what does success look like for roles outside of academia? The following discusses the three areas that I struggled with the most. I’m documenting my experience in the hopes that it will be useful for others.

Finding problems #

Academics love novelty and expect all research papers to be novel, meaning that they must have a surprising outcome.

In an industrial setting, your company may still pat you on the back if you work on “novel” problems but that’s not enough. Your problem must be useful. All the novelty in the world does not matter if the problem you are working on does not benefit the company’s products. I struggled with this. Not only do you need a comprehensive understanding of open problems in academic research, you also need to know what problems your company is facing, and find the intersection between these two sets of problems. It’s tough to hit this sweet spot.

That said, finding problems in an industrial research setting also has its upsides: You have access to data or insights that nobody else has, which eradicates all competition. For example, you are among the first to learn about new trends before word spreads among the academics. After all, many PhD students work on problems that they are told about by industry folks.

Engineering priorities #

In an academic setting, the role of code typically is to build proof-of-concept software. Once this software is built and published, it is forgotten. Other researchers may build upon it but nobody has the time to maintain the prototype. This type of software is sometimes referred to as conferenceware. Regardless, academic code is an asset. You built something that others haven’t, and that gives you an edge.

Working in an industrial setting, I quickly realized that code can also be a liability. What I understood intellectually soon became palpable as I took on ownership of both old and new code. Code has a habit of rotting; dependencies become outdated, language features are deprecated, and infrastructure changes. It takes a considerable effort to fight off the rot. The more code there is, the more effort is required to fight off the rot.

Academic software is a one-off effort, so we typically don’t have to revisit the code. The opposite is the case for the industrial code I’m working on. I have to revisit all of my projects periodically, be it because we need a new feature, or because we encountered an edge case that is not handled correctly, or a dependency needs an upgrade to a new major version number. Revisiting poorly documented and dirty code is taxing and slows you down. This is why I now spend much more time to “get it right”, to make subsequent revisits easier to deal with.

Finally, I had to familiarize myself with technology that I never had to bother with back in academia, namely Docker, Kubernetes, Prometheus, AWS, and continuous integration. It can be tiring when 50% of my time goes into writing the code and the other 50% goes into automation, testing, and infrastructure.

Promoting your work #

As an academic, your job is to impress other academics. One does so by thinking really hard about a problem, writing a research paper about your thinking, and submitting this paper to journals (or conferences). If your peers are impressed by your hard thinking, they will accept your paper. It’s easy-ish to predict what your peers will think about your work because they are your peers and you therefore know how they think.

In an industrial research lab, you may still be required to write research papers, but your job is also to do useful things for your company. Most other employees at your company aren’t going to be academics. They are unimpressed by your hard thinking and you will soon realize that you have to impress these folks in other ways.

Let’s imagine you did a smart thing at your company. Maybe you invented an algorithm that makes the company’s flagship product 15% faster. You are proud of how smart it all is, any academic peer would be delighted! Your co-workers from product development however don’t seem impressed by your Big O notations and the thousands of lines of code that went into building the algorithm. They only ever ask “how much faster is it?” and “how much does it cost to deploy?” Academia likes to highlight the advantages of systems while brushing over its disadvantages. These disadvantages start to matter when one has to maintain software. Code is a liability. So is infrastructure. Many research papers contain clever ideas but these ideas quickly fall apart when someone has to maintain these systems.

In addition to how to advertise your work, consider who you should advertise it to. On your quest to impress your co-workers, don’t spend all your time explaining your algorithm to the front desk person. Likewise, your company’s CEO may not appreciate your hourly emails. Your efforts may bear more fruit if you talk to the product manager who’s in charge of the product that would benefit from your work. One needs to understanding the decision-making hierarchy, which helps with figuring out who should be lobbied. Understand who makes the decisions that affect your work and how you can persuade this person.

Further reading #

If you found the above useful, take a look at my book Research Power Tools, which discusses more topics like this.