Differences between working in university research and a tech startup

In August this year, my academic postdoc contract ended and I moved on to working at a data science tech startup for a two month internship.

In fact, I was offered a short-term contract to extend my stay until late autumn, and I was pleased to have that opportunity. By the time that I actually leave at the end of this month, I'll have been there for over four months. I figured now would be a good time to reflect a little on what I've found, to structure my own thoughts and share them with anyone interested in making a similar career change.

It's been an enjoyable and interesting move. It's been unusual to spend the entire working day doing things which I'd previously worked on only in my free time. The weeks have gone by really quickly, but it's been a useful experience: I've learnt a lot and, importantly, I've more of an idea of what I should continue to learn more about after I leave.

So, here are some remarks on my current working environment with some comparisons to my previous academic work.

1. Common to many startups, the company I'm based at is relatively small. That in itself is not that different from my past academic experience¹. On the other hand, a huge distinction is that most of the people involved with the company are usually in the same office. Even if not physically present, they are usually on IRC/Hangouts. What this means is that things seem to get resolved and decisions get made far more quickly.

   This is a real plus for me, since both working in this company and in a tech job are completely new. If there's something I need help with or if I want to ask about some technical details of the company's platform, OBit's likely there's someone in the room who can give me good advice.

   It was rarely the case that everyone I'd interact with in university (supervisors, collaborators) would be in direct earshot, and I might only see these people occasionally, maybe once a week or month. If some problem came up, I'd probably end up sending an email and the time to get a reply might be a few minutes, but might take a lot longer.

   Having near-instant feedback is helpful in keeping you focused on the main problem at hand, rather than getting too distracted by the yak shaving that might be necessary along the way to solving it.

2. Because the company's small, you get a feel of what's going on throughout the entire company, from product development to customer demands. It's also an informal, open environment where discussion doesn't seem to be stifled and which helps communicate this information.

   We have daily stand-up meetings. Everyone stands up and, in turn, describes what they achieved in the last working day, what they have planned for the day ahead and mention anything that's currently hindering them from making progress.

   This is something I really like. It lets you keep up with what everyone else is working on. It means you have to spend a minute or two deciding what you need to achieve in the day ahead (and sets this as a public commitment to yourself). And, importantly, it allows people find others who may be able to help them.

   We also hold retrospectives where the previous fortnight's work is reviewed and we look at what needs to be focused on in the next fortnight. There's then a vote on which issue particularly needs to be dealt with. Everyone's opinion — yes, even that of temporary employees and interns — is counted equally here.

   Working in university, I'd have a vague idea of the goals my colleagues were attempting to head towards, but, in my experience, group meetings and discussions were relatively rare. I would have a rough idea of the goals people were working towards, but not particularly aware of what they were working on day-to-day. Someone might be struggling with some problem or some experiment, but might not be aware that someone else may already have independently resolved that issue.

3. As the company produces a lot of code, another way in which you can see what others are doing is looking at the company's software repositories. We work using GitHub and Bitbucket². If you discover a problem or bug with software that someone else has developed, you can either create a fix yourself and submit a pull request, or raise an issue.

   Having data on shared drives is not uncommon for academics, but that can often just be in the form of individual backups, and may not be well organised for others to find that information. I certainly wouldn't have been likely to notice issues with someone's else work unless they came to me directly asking for help with some problem.

4. Working with people remotely via Google Hangouts was a little odd the first couple of times, but soon felt quite natural. This works well when coding. You can share screens with one person driving and one navigating, or you can use tmux or similar to allow both working partners to use the same terminal at once. I've only worked like this a few times, but it felt little different from working side-by-side in the same room.

   This also works well to remove the sense of isolation that remote workers can experience. It feels more like you're in an extension of the office. The few times when I'd been writing papers or my PhD thesis up at home, apart from getting the occasional email, I felt considerably more cut off.

5. Finally, projects are often smaller and deadlines can be tighter than in the academic world. Justifiably, customers want a product or service they are paying for delivered as quickly as possible. A startup's funding may also be quite limited; there's pressure to move quickly to generate income and/or gain further investment.

   From my experience in academic circles, deadlines can be more relaxed³. Sometimes you may encounter deadlines for publications or conference abstract submissions, but these may not exactly be strict. Projects also last for a much longer time; PhD students in the UK usually take three or four years tackling a research problem, largely individually.

---

For another opinion on moving from scientific research to working in tech, I definitely recommend this post from Jessica Kirkpatrick, who switched from astrophysics research to working in data science. Jessica nicely summarises the wider issues regarding careers, rather than the day-to-day working differences I've focused on here.