I think with data science is funny, you kind of pay people for their time spent doing things which didn't work. With natural language processing, computer vision, you just need to learn what doesn't work. And there are just some very few things which work.
An interview with Fabian Blaicher, a Co-Founder and the CTO at Shipamax, an AI-powered data entry software for the shipping & logistics industry. Shipamax raised $9.5M from Mosaic Ventures, Crane Venture Partners, Y Combinator and others.
Peter Zhegin:
Welcome to datafounders, a series of interviews with founders of data science startups, experts, and investors. Today I'm talking to Fabian Blaicher who is a co-founder and the CTO of Shipamax, an AI powered data extraction software for logistics teams. Fabian, it is a pleasure to have you here.
Fabian Blaicher:
Thanks. It's a pleasure to be interviewed today.
Intro to Shipamax and its place in a broader RPA space
Peter Zhegin:
Amazing. So to start the conversation, can you please introduce yourself a bit and maybe tell us a bit more about what Shipamax does?
Fabian Blaicher:
Yes, I'd love to. So, my background is technical. And I started my first business when I was in school, it was a web development agency. And we weren't even like a contract from an [not clear] subsidiary when I was 18, which was way over our heads. And I then went on to study computer science.

And did like different stints at different universities like in Germany, also went to Carnegie Mellon University in the US to do some research there. And then at the end, I've worked very deep in research, actually, I've worked on speech recognition research, and I worked on Chinese-English switching speech recogniser at the university in Singapore. Which was very exciting was like very high tech machine learning. It was like over 10 years ago. So it's been quite a while now.

And after that, my first job was at Goldman Sachs working in derivatives. And then I quickly moved into commodity trading and work in oil trading. And then in chemical, fertiliser, trading financial and physical.

So I went basic, like from super cutting-edge high tech research to super low tech, but loads of money (people buying like chemical fertiliser, like for $10 million on a farm in Kansas, if it's starting to rain). It's like two very different experiences, but very good preparation for my experience as a founder.

And after the work in commodity trading, I started my startup, together with my co-founder. Right now I'm the CTO of Shipamax. We raised our series A last year and grew, the team last year from like, 13 people to 26 people.

Right now I have three teams. I have the web engineering team, which is quite cool. It's like people like from Google, from Facebook. They built like APIs, ERP integrations. And then, of course, like a product management team. The head of product, he's very, very great, also like a product manager. And of course, the data science and machine learning team, which is also it's like super talented, people with PhDs in computer vision, machine learning, and 5-10-15 years of experience post PhD. We also have a junior from Cambridge, but overall quite a mature team.

What we do right now is we automate data entry for logistics companies. Logistics companies, they get a lot of like documents for shipments. Think of a container with electronics getting loaded in China on a truck, on a train, in a warehouse, on a container ship, on an airplane, and you get documents, bills of lading, this has been loaded or this has arrived, can you take this container from the warehouse, can you pay for the truck, can you use this documentation to fill out the Brexit customs declarations. Right now we're like super busy because of Brexit, actually.

And we automatically read this documents, we get the emails from the customers, we extract the emails and the attachments. And then we automatically extract the data and make the results available by API integration.

I guess like one thing, which is interesting about us, is we really focus on offering an end-to-end solution for the customers. For example, companies like UiPath they do one bit, but we offer the whole platform. Getting the data, training the model, and automating, extracting everything, specialising on logistics, language and context. I mean, also integrating into the ERP systems, but also having some kind of exception manager with UI. It's very comprehensive for logistics. And then also, we raised a good amount of money, which also quite cool.

Scaling tech and data science teams

Peter Zhegin:
You opened a gateway towards a very interesting topic actually, probably the one that we didn't discuss a lot with our previous guests. I guess you are the first CTO on the programme. So that topic is the technical team and how to grow it, you mentioned that you have actually three teams. Maybe you can tell us a story of scaling, actually, and point towards the most important things that you learned from scaling your team from probably just yourself.
Fabian Blaicher:
Yes, no, no, absolutely. I love to talk about that. I think it's actually really interesting and I think it was a good learning experience, definitely no one prepared me for.

In the beginning, it was just my co-founder and me and I was doing all the technical parts.Then, after Y Combinator, we hired like one machine learning engineer, he had worked in industry-university joint research lab, and then he joined us. And then we had two people work on it.

Then a year later, we had four people working on it, and a year later, we had eight people working on it.

And what we saw is, you have all these academic very smart people, really strong specialists in machine learning, computer vision, natural language processing. But maybe they're thinking not so much about processes. When we had, maybe two people working on a code base, their processes were easy, right? You know, what the other person is doing without talking about it. You know everyone else's change, really.

But then when we grew from two to four people, we really felt there was a problem. Someone edits some code, but because we have a data extraction pipeline it had like an impact on someone else. Maybe it broke something, we had some evaluation, we caught it. But the problems were coming back, like one person impacted the other one.

And what we did was - we just did like a brainstorming session, we just drew the whole product on our whiteboard. And also did a bit of brainstorming session about the processes. And, and I'm gonna come to a few examples in a second.

And then we looked at the product, we looked at the codebase. And we said, well, we need to refactor the code, so it's more modular, so people can work in parallel and on different things, being confident that you don't break things up.

What we did after this brainstorming, after looking how the code looks, how the processes look - we set aside some time to refactor the code, to split it up in modules, so that people can work very well, separately on it.

What I'm sure, a lot of data scientists or academic people are whales, if you're in academia, you try to get out code for a paper, for your thesis, for your PhD. And maybe the code quality is not really high. And we also saw that has some impact. So for one month (by then we were team of four people) we dedicated someone - one person had to review every pull request and instil like higher quality for the code.

Of course, we also split up and made sure that we had like enough automated testing. So scaling from one academic to more people while making it commercially successful product, I think was very interesting. Analysing and taking a step back, really helped us.

Now we have eight people and things work much smoother.
How to decide when to automate/change processes in a technical team
Peter Zhegin:
And you mentioned interesting thing about testing automation. Correct me if I'm wrong, because I'm here, not on my territory, I'm not a technical person. What I also hear that people start quite early to build some shared tools, maybe abstractions, etc, to reuse them. When do you think is the right time to invest in these kinds of things, beyond automation. Maybe something industry specific, something company specific, like Google 'created' MapReduce.

When a technical team, when a data science startup should think about automating more than code review.

Fabian Blaicher:
This really depends on every company, depends on a team. I think there's unfortunately, no golden rule. I think if you manage a data science team, it is good to sometimes set aside some time, and look at what do people spend time on. And look on how long does it take.

For example, at some point, when we were a team of eight data scientists, we noticed that wen data is labelled externally, correcting the data that comes back takes sometimes days of work of very expensive, very smart people. So we hired a dedicated person, just to check the data quality within the company.

But it's also important not just listen to what someone advises you to automate based on learning about your company for five minutes.

Someone told us that we should automate this. Yeah. And now, five years later, we still have not automated it. And it's fine. You as a leader, you need to figure out what's the problem. You take the ideas, and then you think, what's sensible.
Peter Zhegin:
Are there any heuristics maybe, or frameworks that a founder may use, to prioritise that? To look at the things that are happening, and to select a few to automate?

Maybe there are some frameworks, I don't know. Or it's more like continuous research, just analysing and reflecting on what you're doing.

Fabian Blaicher:
I think, it's two things. Obviously, dedicating time to improving processes. Everything takes time you see. You need to dedicate time in your calendar, block time in your calendar, maybe an hour every two weeks, and then say - Okay, I'm going to look at what is the team be doing. But also speak with everyone in one-to-one [sessions]. Introspective analysis, speak with a team. But what I also found, especially in the beginning (now I spend less time on it) - read blogs, or even better, speak with other people, about how they run their teams, and then you just pick the ideas that would work.

Also, you can do that while you're interviewing people. If you interview a data scientists, let the candidates explain you how they work. And then you can see, what are you doing better, what are you doing worse, and then you can benchmark.
Sources to hire data scientists and what to look at
Peter Zhegin:
Let's speak a bit more about hiring, especially these first hires when you quadrupled yourself basically, from one to four. There is a bunch of associated questions there. So how you can find these people how you can solve them? Is it your personal network, or maybe use some agencies or some other sources? And then what things did you pay attention to when were you hiring these people?
Fabian Blaicher:
Good question. Unfortunately, things have changed. I'm going to explain you why I think it's unfortunate. I think I've interviewed like, 1,500 people since I've started Shipamax.

When we started off, it was easy to find people on like AngelList. We hired quite a few data scientists, machine learning people from angellist. Because when they are there, they're interested in working for a startup. Right. So that's already like the first step.

But I think in the last two or three years, hiring for data science, machine learning has become super competitive. Millions startups, there are big companies hiring. And you just as a small company don't have a big footprint.

What I found is reaching out to people works, maybe if you want to hire at one time for one or two people. Just like looking on AngelList, looking at hiring platforms.

But when we needed to really grow the team, for example, after our series A, it was clear, that's not gonna scale, right? If I want to double the data science team, and the engineering team, and the product team, I can't... and we don't have an HR team. So we use external recruiters.

It's very important that when you hiring you align expectations about what do people want to do, how much do they want to earn.

I think, getting someone with a really good attitude is very important. But I don't have a hack for it.

I think, especially with data science, you definitely want people with experience. Like as a startup you don't have a lot of time to train them, people need to get the ground running fast.

I think with data science is funny, you kind of pay people for their time spent doing things which didn't work. With natural language processing, computer vision, you just need to learn what doesn't work. And there are just some very few things which work.

And even if you let's say do a data science bootcamp, you learn maybe the things which work, but you don't understand why they work.

So I think that getting experience getting good attitude, you can test for experience. attitude has been more difficult.
How to integrate newcomers into your tech team
Peter Zhegin:
And it's very important to highlight the startup world, there is not much time to learn. And I'm curious, what's your view on, maybe on the induction? Because, I guess regardless the experience, a person needs to study the code base, style that you guys use, when coding. Do you think there are some options to optimise that?
Fabian Blaicher:
There are many aspects to what you said. In our case, we do machine learning for logistics. And we expect people to know about machine learning, about software development. We do not expect people to know about logistics. There are probably some people in the world who know that.

But I guess also for sales, we never looked for logistics skills, never. Because that's easier and quicker to teach.

With learning, what we do is we have two week intro plans. We're small company. We don't have HR teams, that can do brainstorming for half a year for something. A two week introduction plans - where you have an intro session about the company, an introduction about values, an intro session with a product manager who really guides you through.

What we also have, apart from this two week plan, which gets you started with the different teams in the products, it's like a 30-60-90 day plans with things that you should learn. For example, about the industry, but also about the code base, and also what you should deliver.

Every engineer or data scientist who starts, will have a very small task lined up for the first week. Because it's impossible to deliver something great for like a new codebase in the first week. It's not possible. But the best way I think is learning by doing. Doing something small, working together with the team the first week. I think it's like three tasks for the first two weeks or something. Like one really, really small one, it's probably like a line change, or something.

Having something institutionalised is important, like you know - okay, you have a new start, you're gonna do this, you're gonna do that.
How and why a tech co-founder may be involved into the commercial part of the business
Peter Zhegin:
Nice, nice. Things become messy when there is no clear separation. I want to touch on the topic, associated with the way how a technical team, or more precisely, a technical co-founder interacts with non-technical one.

Sometimes I see that there is a kind of a wall between the commercial world and the data science world. How do you see the interaction? How do you see your personal involvement into other aspects of business?

Fabian Blaicher:
That's, that's a good question. And I think, especially when we're at the beginning of their startup journey, this is actually a very important question. I would say, I'm a tech person, I take that, I work very deep tech, even though I did some commercials, things.

But it's, it's good to talk to customers, especially in the beginning, like reading the support tickets, what comes in, what does the customer want? Join, or maybe even do some sales calls yourself - some very early sales calls, be able to explain what are you actually doing? What is your company doing?

What it gives you is an insight about the individuals using your product. And then sometimes, you'll be able to find a technical solution to one of their problems, that for a very businessy person who doesn't have a technical understanding, would look very difficult, [undoable]. But you as a technical person [understand] - [it's just] one line of code. I think you understand the customers, you understand what they want, what their mindset is, do they like their work, do they just want to go home to their family?

But also understand that the companies you're selling to or like the individuals, right, the groups, right? Maybe [you learn that] users of your product are different [from] the people who signed that, check who and pay the invoice. Like maybe the economic buyer, the user, and then the finance team. And in understanding the dynamics of the customers, I think is quite cool. And it helps you as a technical person.

In the beginning, you can talk to people. Now, if you grow as a company, you're probably not going to be on sales calls a lot, and not gonna be doing like a lot of support stuff, you're probably going to read notes of some of the customer success team, or their product management teams whose job is to speak to the customer.

I personally think if you have someone who's goodat technology, and someone who's good at business it's a good founding team. It's kind of a no brainer. So I'm technical, my co-founder and she's since the beginning the CEO, she's been doing with the sales and the business side from beginning. I would say the lack of understanding of technical by non-technical people is not a massive problem in our case, because in the beginning of my-co founders career, Jenna's, she also worked in a quant tema. At some point she built some models, some statistical models as a developer, so she didn't do it for a long time, but she understands like some intricacies.

But [regardless the team compposition] if it's like a technical and a non-technical [founder], even two technical [founderds] it's good if you can trust. To give you an example, what I mean by that is I'm looking at the technical side and my co-founder at the business side. Sometimes I see things, which I think doesn't look right. But I take a step back and say - 'This is not my remit, right?' I trust her. It's her job. She thinks about it 24 hours a day, I trust you will do the best thing for the company.

And also - communicate, especially with deep tech [founders]. Sometimes things either take really long, or are really difficult or both. As a technical person, you need to be able to communicate what can be done or can't be done. But also salespeople, like what do you need? How can we work together and improve it? If you technical, or non-technical, have a good foundation of trust, and also communicate and explain your thoughts, why you see things in a way.
How to fundraise: angels Vs funds, US vs Europe
Peter Zhegin:
That's nice. It's very interesting to learn your perspective on non-technical things. And I also have more questions on that. Maybe I would like to look a bit more on your experience with the fundraising. I know that when you I graduated from YC, you talked quite a lot with non-European investors. What were your learnings?
Fabian Blaicher:
I think overall, we were successful with fundraising over time. But there was a lot of work and a lot of failure behind it. Before we started off, my co-founder had worked at like two startups in London, Adzuna and GoCardless. That GoCardless has, like 500 employees now, and she worked at, like 30 employees. And because of her background, we got meetings with nearly all good London VCs in the first two months of starting Shipamax. And there was a very humbling experience because we got meetings because of generous background and generous connections, and introductions from like the founder of GoCardless. We met these investors, and they all said no.

We were super excited of meeting them. But we learned very quickly the hard way that maybe there's a bit more to it. And then we went to a startup accelerator in the US, it was not Y Combinator, we went to a different one, in logistics. We got some money. And even better, we could get some angel investors. Because we said we're going to the US, like if we're going to come back, like the price is going to triple like in two months. So creating a fear of missing out FOMO was very good by doing that.

And then someone else said - Hey, guys, you should go to Y Combinator. [We were] not sure. And Jenna [my co-founder] she just ended up going to some Y Combinator event, a startup school event in Mountain View. After the presentation, like a YC partner says, - Hey, you need to apply to YC. And she came back and asked me - we just had this [previous] not so great accelerator experience, not sure we should do this.

We spoke with a lot of people. And every YC founder said - YC is the best thing you can do. And then we went there. And it was wonderful. It was super good. They have a lot of experience. And then we were in Silicon Valley, we like Sequoia Capital, every company which was worth anything. And I think what we saw, compaterd to European scene - there is a lot more funds. And the result of that is generally it's much more competitive. US funds have a much higher risk appetite,

UK funds, but especially like continental funds, we had spoken with some German investors, and they turned out very conservative. Probably [with these funds] it's easy to get funding for a last mile delivery thing, because you see cash flows from the beginning. But if you want to do machine learning enterprise software, where just like building the software is gonna take a while, the European investors struggle a lot.

US investors they have more experience with investing so that was much better, but long story short, I recommend everyone to raise money into the Valley. But I would also say, do not start with funds. Start with angels, right? It's like the sales process, you have one guy who invest his own money. And he says - Okay, I like you guys, I'm gonna give him $100,000. In one case, we had one investor, who after 20 minutes phone call, he wired us $100,000 in the next day.Then getting some angels, and then you can start building your product. And then you can go speak with investors [funds].
Peter Zhegin:
Dealing with angels did they come through the accelerator, YC, or you have done your own job finding these guys, talking to them?
Fabian Blaicher:
We had like two angel rounds. So really early angel round, it was riends, and former managers. I have some former managers of my company invest. Jenna had some former managers of her former employee invest, and some friends who happen to have money. And that's how we first started. But then when we did the bigger angel round, it was through introductions .It was like, some other founders introduced you. And I think that's really how it started - introductions from other founders. And then if you have some angels, they usually have [wider networks of contacts].
How does Y Combinator help
Peter Zhegin:
You mentioned YC, that it's a great experience, what you can get from Y Combinator if you are a data science startup?
Fabian Blaicher:
I think what they do is they make you pick a metric in the beginning, and then you optimise the growth over three months for this metric. So you can show it to investors. It also forces you as a business to really focus on what you're doing.
Peter Zhegin:
Yeah, I guess the level of introspection, and kind of the level of reflection that we see from startups that went through leading acclerators, YC is among them, is really quite high.
Fabian Blaicher:
There's also a lot of peer pressure, because you meet every couple of weeks in small groups with founders, maybe like four or five founders or 10. And like two YC partners, and you present what your progress was during the last one or two weeks. And you don't want to be the sucker.
Closing remarks – finding time for reflection
Peter Zhegin:
This pressure might be good at some point. Just not to keep you here for too long, last question. We talked about scaling of the technical team, about fundraising, and some other things. But if there is anything that we missed, anything that you believe, should be discussed, but we just didn't talk about that. Let's cover it right now.
Fabian Blaicher:
There's always so much to talk about really. I think what I mentioned earlier is really important is that sometimes you need to take a step back. And really look at what the problem is. And maybe if you can rephrase the problem, the solution is really easy. The problem you have in mind and the solution is not there. Sometimes just take a step back and think - what is the core? What is the customer one? What is the technical problem? It's so easy to get stuck up in the day to day, in small issues. But just regularly take a step back, during small tasks, but also on a yearly basis.
Peter Zhegin:
How does it work for you, you collect feedback, you meditate, what do you do?
Fabian Blaicher:
I just have a to do list of things which come in from someone else. But also like some things that I notice. Sometimes I see like - okay, maybe building X took a long time, and I just make a note. And then like every one or two weeks, I just sit down and go through the list and say - why is that? What can I do about it? Should I speak more with the team? Can I do some research? It's just having a list and like just revisiting the stuff. Sometimes the solutions in the team, sometimes you ask your investors, we speak a lot with our investors and ask them for advice. It really depends on the task.
Peter Zhegin:
Someone should be flexible about that, about how to provoke this reflection.
Fabian Blaicher:
Just like, set some time for you, on a daily basis, keep track, have a notepad and a to-do list.
Peter Zhegin:
Amazing. Thank you Fabian, I guess we covered a lot of interesting things. And I'm sure we will hear a lot of good news from you and from Shipamax. Thank you.
Fabian Blaicher:
Thank you very much, Peter.