3 Takeaways from my Journey as 1st Employee of an AI Startup

ARTIFICIAL INTELLIGENCE | STARTUPS

Working at an AI company is different. Being the first employee is magical.

Since I can remember, I’ve loved math and physics. I got the best grades in high school and always felt in my element. As everyone around me expected, I ended up getting a degree in engineering in 2017. Sadly, after five long years on a bumpy road of doubts and failures, I fell out of love. I wanted a change and that summer I had an epiphany: Why not combine what I did best, with what I wanted to do next? Artificial intelligence was my answer.

I had a newfound goal and renewed will to achieve it. I started studying AI online. I took courses, read papers, and learned to code. I spent four months in a race against time. One day like any other, I found the position I was looking for. An AI startup focused on innovation wanted a recent engineering graduate with some AI knowledge. That was me. I got the job. However, it wasn’t just any job: I was the first employee of the company and the only one with some notions of AI. It promised to be a challenging journey.

I’ll share with you 3 lessons I’ve learned during this 3-year journey as the first employee of an AI startup. This article is intended for those of you who are getting started in the AI field and don’t know what to expect from the fast-paced, rapidly-changing startup environment. Enjoy!

The first employee – Epitome of an exciting job

I made up half the entire tech department. The CTO and I together against all odds. The core project of the company involved the design and development of a real-time bidirectional sign language translator. Given that not even Google has built one, it was nothing short of ambitious. My official position was "junior developer." My actual position was a mix of AI researcher, ML engineer, data engineer, data scientist, and even the documentation guy.

Frank Rotman, the co-founder of QED Investors, wrote this Tweet a few days ago. It resonated deeply with my experience:

One day I was writing the code for data processing and the next day I was reading papers to find which model fitted best our necessities. The day after I was recording videos with our sign language expert, and then at the end of the week, I had to do a demo explaining to potential customers how the product worked. Each day was different. It was a constant adventure; the definition of a non-routine job. And I loved the sensation. Every morning I woke up bathed by that feeling of uncertainty, mixed with a desire to be creative, all tinged with an unstoppable will to face any challenge.

But not everyone is the same. Some people prefer to do specific, well-defined tasks that do not fall outside the boundaries marked by their position. They may love to be creative, but choose to direct that part to their hobbies. Routine jobs aren’t as exciting, but they’re safer. It’s fair to prefer the feeling of dominance at what we do instead of feeling like a foolish novice each day.

Frank Rotman referred in his Tweet to the first ten employees. I lived through the most extreme case. I had no colleagues, no one to look up to for Advice because I was the "expert." Yet, I wouldn’t change the experience for anything else. I didn’t feel secure, but I felt alive. It’s up to you to find out which side of the spectrum you fit into.

The importance of a strong theoretical background

There was a recent debate in Towards Data Science about the role of having deep mathematical knowledge in machine learning. GreekDataGuy – formerly known as Chris The Data Guy – wrote a piece titled "You Don’t Need Math For Machine Learning." Soon afterward, Sarem Seitz replied defending the opposite view: "You DO need math for Machine Learning."

GDG claimed math is overrated in machine learning. Coding and knowing how to handle data is more important because libraries can do the "heavy lifting for you." He’s a proponent of a top-down approach: Learn by getting your hands dirty first. Sarem Seitz, in contrast, argued that a strong mathematical and theoretical background can give you a broader toolbox to face unexpected issues. You understand your models. And you can debug faster or easily "spot violations of the theory."

I fall on the side of Sarem here. Because I was heavily trained in math and physics, I managed to find engineering solutions to problems that had nothing to do with data or AI – problems that I had to solve regardless. Still, if you asked me if I think math is equally important for all tech positions at all companies in AI, my answer is "no." As I showed in the previous section, working at a Startup isn’t the same as working at a large, traditional company. The degree to which math – or other types of theoretical knowledge— is useful varies with the degree of specificity of your job. I found it extremely helpful to know math – and engineering – because I was facing a broader set of challenges and issues than most people do.

Here’s a true story. When I joined the company, they were trying to use a set of bracelets to translate signs to words. The idea was to map a set of hand/arm movements to a "sign class" using variables such as angular velocity, trajectory, and muscle pressure. After a few weeks of working on it, I realized there was a fundamental mistake in the way we were doing the measurements. The bracelets weren’t recording a crucial variable. Had I been a pure programmer – or even a data scientist – I would have never even looked for that problem. I was told to use data from the bracelets, why would I doubt if they were working correctly? How could I have solved, or even understood, such a problem without some engineering competence?

I don’t think a situation like this is common in a bigger company, though. Hardware engineers would handle questions like this one. However, nowadays many tech companies follow the startup model. You don’t know what you will find tomorrow. You don’t know what tools you’ll need to find a solution. Actually, you may not even know if the question you’re being asked is the right question. In these cases, a strong theoretical, mathematical, and engineering background could save the day.

Industry or Academia? A one-man band

With just 4 months worth of knowledge in AI, I almost didn’t qualify to be called an initiated. I had some concepts more or less on point and knew the main paradigms and frameworks by name. I was for sure not prepared to undertake a near-unsolvable project. I was happy I got the job but was well aware I’d had to study very hard if I wanted to rise to the challenge.

However, and to my surprise, I soon realized I had to justify every minute of study to my bosses. Even if it was obvious to me that it was a requirement for the project to succeed, the relationship effort-results was simply too indirect for them to see the usefulness. I had to find the balance between studying to know how to solve the problems and actually solving them to satisfy my bosses. I had to study the science, build the Technology, and design the product. Instead of giving different points of view of the company to different groups, I had to solve the conflicts and incoherences myself

In large companies, different departments hold distinct points of view of the company – and have varying criteria to decide what’s more important – so they can each defend their interests. Product designers think that the user interface should be the top priority. Data scientists argue that "a machine learning model is only as good as the data it is fed." AI researchers insist on using state-of-the-art algorithms. If their views clash, each team pulls to get the most resources – hopefully finding a stable equilibrium.

Scientists answer questions such as:

Machine learning or deep learning?
Convolutional networks or recurrent networks?
A model for each task, or one single model for everything?

The techies decide:

Python or R?
Keras or TensorFlow?
Cloud computing or on-premise?

Data-centered people ask:

Homogeneous or real-world dataset?
Pre-existing database or build our own?
How many classes? How many samples per class?

And product management will always complain:

The system should be faster.
We should make it operative on phones.
We should translate sentences, not just words.

I had to think about it all. I had to fold all those clashing perspectives within myself and then solve the trade-offs. That’s why I couldn’t afford to keep a university-centered mindset. I had to find a balance between Academia and industry. Between science and technology. Between accuracy and operability. At first, I conflicted a lot with my bosses. But with time, I started to see the bigger picture. We should always aim at creating the best tech possible based on the rigorous underlying science. However, every project lives within a larger framework in which other variables – resources, customers, investors, and deadlines – play a fundamental role.

Takeaways

The tech startup landscape is crowded with interesting projects. You don’t need to work at Google or Microsoft to fulfill your ambitions. However, a startup isn’t a smaller-size replica of a bigger company. It’s inherently different, and the way it functions deeply influences the work you have to do.

I worked for three years at an AI startup, and I learned things I’m sure I wouldn’t have learned in big tech companies. And more importantly, I was the first employee, which provided me a unique perspective and professional background that will highly benefit me throughout my career.

Here are the main takeaways:

Early startup employees don’t work in a constant position. Each day can be different, an adventure. It’s the definition of a non-routine job. If you hate doing the same thing every day, the fast-paced, rapidly-changing environment of a startup is your place. The job isn’t safe and you won’t feel secure, but you’ll be excited each day as if it were your first day.
Many techies working in AI consider theoretical/mathematical background as an additional tool. It helps sometimes but doesn’t hurt that much if you don’t have it. Others argue that it can help face unexpected issues down the road so it’s good to have it just in case. In the tech startup sector, it’s a must. Your resume shouldn’t say: "I’m a full-stack programmer." It should say: "I have notions of engineering, programming, AI, and data science. And I understand how they work together."
Groups aren’t that well-defined at small startups. You’ll have to solve challenges transversely across many areas of the company. Specialization is often secondary to generalization. In a startup, it’s fundamental to broadly understand the company and the projects you’re involved in. You’ll have to find a balance between the most scientific side of the project and the resources and requisites you have. In bigger companies, each group defends its interests. In a small startup, you may have to acknowledge both sides and solve the conflicts yourself.