Biotech Automation Meets AI: The Future of Cell Culture with Salavat Magazov

Hey, Salomon.

Hi. Hiya.

So it's been quite some time I was trying to get you into the show, right? And your no was basically, you know, we have things, we have some commercial partnerships and, you know, and all of these. So finally I got you in. So thank you for doing this. So give us a little bit of background of who is this all about.

I'm an engineer. I'm a product development engineer. I, I worked in academia initially, working on scientific projects, things like radio telescopes and tomographic systems, brain scanners, and And then I met a girl and we started a family, so we moved out, out of London into Letchworth where we live now. And I moved into the industry where I think probably the majority of my professional growth happened because I integrated into an amazing team, probably the best team I ever worked with. Extremely professional, knowledgeable people. And that— I'll touch on that team, why it was so good, maybe later on if we, if we get onto that topic. I've changed several roles in the past 15 years, and yeah, various things, mostly biotech automation. I've I worked a little bit in consumer electronics. I built a coffee machine and I, right now, I am designing electronics for X-ray sensors and again, a little bit in biotech automation.

Okay. So that's like, that's your professional life, which I call it like, you know, Salavat by day, right?

In the day job.

Yeah, here you go. And then there's Salavat by night, which is, you know, your hobby project, which is was the most one interested for me because a lot of people when they approach entrepreneurship and venture building, they imagine that they're going to have maybe 3 to 6 months. They will have a couple of people as a team and they're going to launch something and it's going to be another unicorn for internet to use. So your industry is biotech, which is effectively hardware heavy. And then there's a software which applies to our show. And then I know you're building this for 4 years with pretty much like no financial rewards along the way, and you have, you know, almost like 10 people team, which, you know, with various degrees. So can you just give us like the concept, like what, how this came to be and, you know, what the product is you guys trying to build now?

This project came about when COVID kicked in and we were all in lock lockdown, and I was talking to a couple of my friends and they said, well, why don't we do something challenging? That was the primary goal, essentially push our skills to the point where we really choke. And I spoke to some of my friends who are in biotech, who are actual biologists, And they said, well, adherent cell culture is extremely difficult to automate. There are solutions that exist on the market, but they are all either very difficult to use or difficult to program, or they don't do exactly what we want. And we thought, well, that's— that sounds like a worthy opponent in, in terms of the goals, what was required. Requirement list was massive. And, and also the products on which the machine works are live cells and they are very capricious. There are some cell lines that are easier to grow, but then there are cell lines that are so capricious that you can tell who was the person who was handling the plate. And if it was the wrong person and they banged the plate or they pipetted the liquid wrong, the cells just either die or they start misbehaving, they change their properties. And it's a very, very complex thing to achieve. So we started messing around with prototypes. The first one was built in the garage, literally in the garage. We put it together, sort of trying to see what comes out of it. It was essentially a complete mistake. Well, it was a mistake from what it did point of view. But we learned a lot. Primarily, I learned a lot about how to work with people because I was managing the team and I am not a manager, at least not in the conventional sense. I, up until I started managing people, I had pathological dislike of managers because I thought, you know, they're they're just a waste of space, pretty much, which I sort of changed my mind now because I have worked with some managers who are really, really good. And then the project sort of started snowballing. It started getting better, and then more people got interested. The team started growing. Some people joined not because they wanted to build the machine, but just because they wanted to be part of the team. Because we were high performance despite the fact that we were completely unpaid, you know, we worked evenings and weekends. One of the guys who joined us was originally mechanical engineer. He joined us and I started training him to become a software engineer, specifically robotics and embedded systems engineer. Within 6 months he caught up with, um, very close to where I was in terms of systems engineering level, became a very good object-oriented software engineer, learned C and C++ very well, and then he just started overtaking me in terms of that particular field. And that was just a pleasure to watch because in, in 9 months I met him in October. In July, he called me and he got a job as a software engineer in a company. I can't remember what the company does. And so that was very exciting. At that point, we were building our, say, sort of second prototype, and he contributed massively to a particular bit of automation that we built. And we are now, I would say, probably what, third generation prototype? We started, I mean, the scope creep is crazy. We have machine vision now integrated. We have artificial intelligence integrated. It's, and it's working. The whole point of building something that we're going to choke on We completely failed to choke on it. Yeah. And it just works. Our teams got bigger.

Let me take you back to literally the beginning. So imagine I'm a listener and I have no idea what the biotech is, or at least, you know, not like from the field. In layman's terms, what does the machine do or what its purpose is?

Okay. Yeah. The biologists grow cells for various purposes in the lab, and growing cells is a routine process that has to be done, and it involves replacing the— what's called the growth media. It's essentially the liquid in which cells are immersed. You have to do that fairly regularly because cells produce— well, they consume nutrients from the liquid and they produce waste into the liquid. So it has to be replenished all the time. Otherwise cells run out of nutrients and they die. Cells also divide. So eventually cells that are stuck onto the surface, they will cover the entire surface and they cannot grow anymore. And some cells dislike to be in close proximity to each other. So again, they start dying. You have to do this process called passaging where you lift the cells off the surface, you divide them across multiple wells, and you seed them again. And seeding is a process where you take the cells and you put them into a fresh plate and they continue growing. All of that is done manually right now, largely manually. There are, as I said, there is some automation around this process. The cells are grown for various purposes. Some of those is to test, for example, drugs, how the cells, mammalian cells primarily, will respond to drugs. It's part of the drug discovery process, so big biopharma would run this. Emerging technologies around this area is where people try to grow replicates of actual tissue. So it's not just disparate cells, but they are aggregated into a mimic of a tissue, and, and then that tissue is subjected to some sort of influence either drugs or maybe pathogen. There is, there is lots of research in cancer, how, for example, healthy cells will try to combat cancerous cells. It's a huge area, huge field, and biologists require supply of cells all the time. But because it's a manual process, it's very difficult to scale. And it becomes even more difficult to scale once the cells that you're working with are particularly sensitive. So it's not a trivial problem to solve from that point of view. So to go back to your question, the— what our machine does is it automates a very large portion of the manual labor that biologists have to do. Right now it's sort of in its very infancy, and we can do media exchange, and we can probably do passaging. We also integrated analytics into the machine. We have a microscope which we actually only just finished prototyping and it works but requires a lot more software. And so we're trying to remove routine labor that biologists very often, highly qualified biologists, have to do manually in the lab and replace it with an automated, automatic solution. Okay. So that's—

I mean, it's very, very easy to understand why you chose this as a challenge, which will, will choke when the COVID hit. I mean, that seems an unsolvable problem, probably why the market doesn't really have a solution for it. So you guys, you're very healthy trending towards actually having a working solution for that. So it started as a challenge, but years passed and now it's becoming a lot more closer to being a commercial solution. So did you have any way of sort of talking with the market and going like, you know, is there a need or are we solving something which is just, you know, like we think there's a need? Like, was there a market validation to understand that, you know, yes, there's people, you know, in lines waiting for this to be created?

Yeah, that's a very good question. We don't know if there is actual commercial need. We think there is, But we have very little actual validation because, well, primarily because we're not seeking validation right now. It's for us, it's a fun project to do and it stretches our skills to, quite often, to the limit. One thing I can say is casual conversation with friends, you know, over beer when they ask, like, oh, somebody said you're building something like a robot, tell me about it. And you start describing the robots and they say, okay, so that means I basically don't have to do any media exchange, I don't have to do any passaging. So what do I go to the lab for? So you go to the lab and you have a look at the machine and it's all healthy and it's fine. And then you go back to your office and you do some creative work. You think about the next set of experiments you're going to do. You think about how this particular experiment is going to produce new data, do some data analysis maybe. Yeah, essentially you get back 80% of your time to do 5 times as much creative work. You know, what you're— what you've been trained to do during your PhD or master's or whatever. Degree you did, that's your purpose, right? To do creative work, to advance science. Your job is not to prepare liquids for 80% of your time.

And that's the main promise of AI, isn't it? Like, currently when you look at the automated solutions and how AI being positioned in the market is that it will give some time back to people and it will allow these automations to happen so people can go back and just do more innovative aka creative work.

Yeah, that's what we found with, at least with our— so we have several approaches to AI. On one hand, AI is part of our machine, which allows the machine to behave a little bit like a human. Because when, so when Ryan gave me a glass of water, He didn't need to explain to me where the glass was on the desk and that this is drinkable, right? It's implied by the very action that Ryan did when he brought me the glass. The interaction between the users and the modern biotech automation is very regimented. So when, when the user gives the machine some sort of consumable, There is no implied contract, there is no identification, there is nothing. You have to explicitly specify that that's the consumable and that's what it does and that's its purpose. That's not how our machine works. Because we wanted to be ambitious, we integrated machine vision and object recognition AI into the machine. So when the user places a particular object on the working deck of our machine, that's, that's all you have to do. If it's a plate, the machine will recognize that it's a plate, and the implied contract between the user and the machine is that that plate has to go inside the incubator, and the machine will just do it. You don't have to specify that because it's, it's obvious. Same goes for pipette tips, media or reagents is slightly different because it's not very easy to determine whether it's, you know, in this case, is this water or is this gin? I mean, it's afternoon, so maybe it's a gin, but judging by the quantity, it's more likely to be water because nobody drinks gin in these quantities. So we're trying to train AI to be a bit more predictive in how it handles the objects that are handed to it. And this, for example, received very positive response from potential users because it's one of the major source of errors. If you go in the lab, you place all the consumables on the deck of a liquid handling robot, and then you have to go somewhere else and program that robot. And then you have to remember where you put everything, and there is no sort of logical location. It's all sort of numbers and letters like a chessboard: A1, A2, B3, B4, and so on. It's not something that humans are natively good at remembering. So that's— so this is the challenge that we go beyond just the regular answering the need. So commercial necessity is probably there. We are not particularly actively chasing that. It's— if the machine turns out to be particularly useful, it'd be great. I think right now Given the state of automation in biotech, we are— we sort of skipped a couple of evolutionary steps and went straight from, you know, Bronze Age into space travel.

Okay, so let me ask about prototyping, because you guys gonna be— and you are iterating on that solution, and particularly this, you know, AI vision and recognizing objects. You put on So there will be a margin of error, like it's not going to be 100%, right? Yeah. How problematic that margin of error is? Because when I think about the process, I imagine like even one small mistake could just render all your tests invalid, say.

Yeah, that's a very good question. I, I don't know the answer to that. The, the engine we're using right now is Yellow, Yellow V8. It's an open source engine.

It's open source, isn't it? Yeah. I know that one.

And it's, to be honest with you, I was blown away by how good it is. We collected something on the order of 600 images.

Just yourself, like, to train the recognition, basically?

To train the recognition, yeah.

Took a picture, just put it in.

Out of those 600 images, I think we used 500 for training. And 100 for testing. And the result is just amazing without any particular effort from, from us. Well, maybe I'm downplaying the amount of effort the software team put in, but judging by how fast they achieved the result, it's incredibly promising technology. We— the lowest certainty level from YOLO based on the 600, 500 training images was something like 0.94 certainty level. 8? 0.94. So it's 94% certain. Yeah.

Did you try to mess it up? Like, did you try to, you know?

We didn't push it too hard. We had some instances where some objects were partially obstructing other objects. Yeah, it doesn't faze it. It just works. Okay.

So it's not just like a happy path testing where you just lay it out perfectly and you go like, oh, it's 94. It's actually like a little bit of—

There is a little bit of that. We wanted to establish the baseline that, you know, when everything's perfect, it works. So, but also keep in mind that our environment is very, very controlled. So there are not many things that will appear on the deck. Like you don't have to anticipate a shoe being on the deck, right? So you don't have to train against that. Because if there is a shoe on the deck, that's something gone wrong completely, and our AI is not meant to deal with this sort of thing. Out of the failure modes that we're anticipating will be things like a bottle, instead of standing upright with a lid on top, it might be toppled over and the liquid spilled everywhere. So that kind of edge case we haven't tested against. and then there will be things like, for example, the lid of a tip box was not placed correctly back on the box after the box was used. So that's another failure mode that we need to test against. But given the low amount of training data and the end result, it seems like this is very promising, and I have every confidence it will work. Again, it'll require probably an order of magnitude more training data to become more robust to errors, but this is the fun bit of the whole process. You venture into the unknown, try it, and then if it works, you get massive amount of satisfaction. If you don't get the positive result, you'll learn something.

So that, that's where my next question comes in very nicely. So let's say you are in this situation and you go like, okay, I did my test and it just doesn't seem like it's a feasible solution. How, how you make the pivot? And you know, you, you guys created a couple of prototypes and I'm sure, you know, like you said, first one was in the garage, was, you know, you learned a lot but it was just fully binned, right?

Yeah.

The second one came out, how different that was from the first vision? And the third one, how different that was from a second? So effectively when you make these pivots, if you're not talking commercially with the market, is it solely based on chasing unachievable, or is there some different mindset around those pivots?

We pivoted based on fundamentally just engineering performance of the machine. Um, so the first pivot was major re-architecting of the way how automation worked. We had a gantry robot. A gantry robot is basically what you see in construction sites, you know, the overhead cranes. We had the same architecture of the robotics that was living inside the incubator and on top, on the liquid handling part of the machine. And inside the incubator, that solution just didn't work. It was, without going into too much detail, it was too big, it was not particularly flexible. The reason we went for it in the first place, because it was very easy to program because it's a linear robot, but the fact that it was mechanically substandard forced us to go and use what's in the industry called SCARA robot. It's a robot that essentially emulates a human arm. It's an articulated arm robot, and it literally has a shoulder, an elbow, and a wrist. And we use that. We change the design of how the robot delivers plates onto the working deck. We significantly re-engineered the top-level robot. The pipettes went through multiple iterations before we landed on the solution that works. And as far as customer feedback goes, I think at that point we sort of broadly knew what we were chasing. We needed to have a reliable machine that would handle plates carefully without shaking them too much, and the pipetting has to be accurate, so we started stuffing lots of sensors into it. And because we were not averse to complicating the design, because essentially complicating the design was the whole point of this endeavor in the first place, We started putting machine vision because the overhead gantry robot wasn't particularly accurate because the working area of that robot is huge. So it's by very mechanical nature of it cannot be particularly accurate unless you spend lots and lots of money. Which is another sort of aspect is when you're money constrained, you have to go in and do ingenious solutions. 'Cause we could have solved it with money by using more expensive components, but we don't have access to expensive components, so we have to go with a clever solution rather than expensive ones. So initially, I think we had very good understanding what the machine had to do. So the need for rapid and detailed feedback from, from the market wasn't really necessary. And, and plus I have lots of friends who are biologists. So when we had a problem with like what is the volume of the pipetting that would normally be done, I could always just ping a message over, you know, email, say, so which volume pipettes should we target? And say, yeah, 1 mL is fine.

So it's an outcome-driven pivot then, isn't it? Like you guys know like what you want the machine to do.

Yeah.

And you're just chasing that, that outcome and whatever— yeah, compromises you need to do along the way, you're basically making that done instead of actually, you know, looking at the commercial side of the endeavor and going like, you know, what the market—

there is no commercial side of the endeavor, so we, we're just having fun. So we're trying to build the best machine possible rather than something that is— that we're trying to make commercially viable.

So when you make these pivots, I imagine there's no like, you know, data tracking or any success metrics you put on, on this, or like what's the planning? Like how do you know if it's gonna work? Like, you know, let's say, you know, take this example with the, with the robotic arm, we didn't work, right? So, so, so you were like, okay, the next iteration's gonna be this. Like how do you know that that's gonna be better than the first one?

You don't.

You don't. So you just, you have to fail fast, as they say.

So robotic arm iteration was very scary because we were abandoning something that essentially works, which just wasn't elegant and was completely suboptimal, and pivoting onto a solution that we had no idea whether we can make it work. One of the biggest problems with a SCARA robot is that— and we're sort of going into really deep engineering side of things— but the SCARA robot maps a linear Cartesian 3D space, you know, the, the coordinates we're all familiar with, you know, front, back, left, right, up, down into nonlinear spherical coordinates. And that's a very weird transition to make because it's— the math is complicated, and then it's very hard to imagine it in your head when you're writing software. And another complication is you can be in the same geometric position but actually have 2 or 3 different mathematical solutions how you arrive at that point, which, you know, it— that doesn't compute in, in your normal experience, because if you, if you're in this room on this chair there is only— there's a unique coordinate about your body, how you end up here. In a nonlinear space, you can have 2 or 3 different solutions, which is where, like, all sorts of cans of worms start opening up, where you have to be very, very careful with the maths. And so it took a long time to get that right. And even then, to this point, we have a bit of a hack in the software where it doesn't really do a proper job, because the proper job would take a while. I'd need to sit down and actually translate the mathematics that currently works in a spreadsheet into Python code. We know how to do it, so we de-risked it to the point where I know the solution is possible, that the other— the next step is to actually implement it in software the same way it's implemented on a piece of paper. Okay, the calculations. So some of the pivots were driven by the fact that solutions just don't work, and some of the pivots were done because we just— the solution does work, but we just don't like it. It's, it's not elegant. It's, it's clunky and just, ugh. You want it elegant. When we got the arm working, and it works under its own steam, and it does the calculations on the fly, even though it's sort of using a bit of a hack workaround, the whole non-linearity, it looks so elegant. It's unbelievable. So, and you know, that satisfaction from getting something to work. In, um, you, you knew 6 months ago that this was a gamble, and then suddenly, bang, it pays off. Okay, fantastic.

Let's talk about that passion, because you guys been in on this journey for almost 4 years, right? So yeah, because there's no financial reward along the way on— in those 4 years, the only experience I have where people stay for so long on the same project is basically passion and personal growth. And the passion is, you know, much stronger. Eventually, you know, you might get through the challenges and you can utilize these challenges to get a job, like you mentioned one of the team, you know, people getting. And then you suddenly, you know, on a different path. So how, how did you even like find these guys? Like, how, how do you guys came together How many of the guys you look— all the girls, by the way— you lost along the way? And where, you know, how many of you are right now? And it's like, like, you know, what's the general take on, on, on the team?

We lost, um, one, two, two people who are not involved in any capacity anymore. Um, one person just got a very demanding day job. And I think the motivation that initially drove him to work with us got fulfilled at the day job. And anecdotal evidence also suggests that he also met a girl he likes and this is turning into a serious relationship. So You know, his free time got occupied otherwise. And another person sort of fell by the wayside, probably not permanently, but they got accepted into master's program. And so again, a lot of demand on their free time. And again, the purpose and passion got fulfilled. In the mainstream. We have people who you could say are involved a lot less than others, but that is purely because their expertise is more of a consultant, as a sounding board, right? And so one of them is a friend of mine who has actually pushed me to do this in the first place. One day I was whining to him that I'm bored, and he said, "Well, why don't you do something that is gonna stop you being bored?" Because he's very on point and no-nonsense kind of person. And he said, "Just pick a challenge and try and do it." So, and I still to this day use him as a sounding board. We discuss challenges. There are people who are involved in this sort of casually. When we have a big engineering problem, they come in, they ask for a challenge because they have a couple of weekends free, and I just give them a piece of work and they will go away. And sometimes they come back with a solution, sometimes not, because they say, well, that, that kind of doesn't work, and because the hardware is lacking, or they just couldn't find an optimal solution. And that's also very useful because we essentially remove one of the dead-end paths that we initially considered as a potential way. You know, chopping off dead branches is very, very useful. It's sometimes even more useful than finding the branch that does work. Actively, Working on them, on the projects, I would say there are probably 3-4 people, majority of them software. Hardware, I do most of the hardware myself, automation and very, very low-level software. The bits that actually control the motors, the heaters, the you know, the pipettes. The software is slowly becoming a much bigger part of this project and becoming more and more sophisticated. So recently we completely from scratch re-architected how the software works, and that was again, I would say, probably a scary jump for the software team because they had something that worked but wasn't going to survive for much longer. It was an intermediate solution. It worked very well for when we needed it, but it had to be abandoned. And they jumped onto a solution that was much bigger, much more sophisticated. And again, I think they did it because they wanted to learn how to architect complex systems. And once they did, It took probably 3 months to refactor everything and put the new solution in place. But now that we did, and that was about a year ago, now that we did, various things are becoming so much easier. For example, expanding software to accommodate new functionality is now just a piece of cake. Because you just expand the API sideways and the software has— the vertical stack of the software has been architected so well that horizontal expansion of sub-modules becomes very, very easy. It's very modular software.

That's the team now, and historically that was the team. So do you need to play a motivator in it? Like, if you, if you think about these couple of years and those big pivots, you know, I imagine like you have to communicate that to everybody and go, hey guys, you know, we're gonna close this and we're gonna make this new jump into that scary territory, you know, here's what I'm thinking. And do you ever feel like, you know, you need to like be the guy and going like, I know we're not getting paid, guys, but it's gonna be awesome. It's just all passion.

Not really, no. This is the interesting bit. This is the bit that actually interests me the most, I think. Um, over these 4 years, my, my personal interest in the project started moving away from, or rather not moving away from engineering, but it's expanding and starting to cover this other area of product development where, well, how do you manage this disparate bunch of people who, um, not even— I mean, we have people in different time zones. So how do they work? Half the people never met each other, and yet there is really cohesive collaboration. And when we decide, well, let's do something crazy risky and see if it pays off, there is more often than not, I have to say, whoa, calm down, let's not throw the baby out with the bathwater. 'Are you sure you want to do this?' And then we have a bit of a discussion about— they will make the case saying, well, this— like it happened a year ago, they said, 'Look, this is a dead end. It works now, but essentially this is a dead-end solution. We can push it for another 6 months, but we're gonna have to do it anyway, so might as well bite the bullet and do it now, because in 6 months' time we're gonna be pressed against the the wall and you're going to be forced to do it anyway. And they sort of made a good point. So no, I don't have to motivate people, and I don't understand why.

So what passion is it? Just that people really enjoy working on this project and they see it actually compounding towards something which is just ridiculously good if it actually happens, right? Well, so it's already happening, but I mean, like, uh, you know, I think ultimate validation is that you have you know, biotech industry, big pharma coming and going like, we won't buy this machine.

I don't think that's a major validation.

No, that's not—

I mean, partly, partly it is validation in, in that respect, but I don't think that's a major driver. I think if there was— I think if there was no future for this machine as a product, it would probably be harder to motivate some people. But that's not because of the commercial potential, commercial success. It's because it removes the purpose.

Yeah.

The purpose being that somebody else will get to use the product of your labor and enjoy the process. It's probably the same thing when it comes to You know, cooking for someone, you know, when I'm home alone, right, my family goes on holiday somewhere and I stay behind because I, you know, I don't have any holidays left or something along those lines. I don't cook because I'll make a sandwich. Yeah, I'll make a sandwich, I'll fry some eggs in the morning, that's it. When my family is home, I can spend 2 hours in the kitchen cooking, not because I want to do it, but— or rather because I want to do it because my family will enjoy the end result. And they're not paying me, right? So this is— money doesn't come into it. So a broader question sort of that touches on your previous question about motivation and the purpose. I've been looking into this topic quite, quite a lot recently, and I came across several papers on the subject. And it turns out that this phenomenon about people not being motivated by money has been known to mainstream science for about 40 years. About 20 years ago, I had a friend who was doing a PhD, and the topic of the PhD was non-financial incentives to workers. I can't remember the exact topic, but the point was that money, as far as incentive, has a very hard limit. And the hard limit is actually quite low, it turns out. Once you don't have to worry about your mortgage, car payments, and food and utilities.

Yep.

Beyond that, money is no longer a motivator.

Yeah.

Which is quite weird. But if you think about it, sort of makes sense. The— what else then are the motivators? And it seems like there are essentially 3 fundamental motivators. One is purpose, and in a sense that you are doing something that will benefit somebody, and the broader the impact on a wider society, the stronger the purpose as a motivator. The next one is mastery. So if you're interested, the The guy who did a very, very good presentation on this topic is called Dan Pink.

Daniel Pink.

Yeah, you know about him. Yeah. So he has lots of presentations on that point. And the third one is autonomy. And without quite understanding the fundamental principles that he was— I only understood them recently. I actually, probably by accident, implemented all three in our project. We have complete autonomy. You can work whenever you want on whatever you want, as long as you coordinate with the wider team. You know, you look at the tickets or you talk to somebody who you work with before and you say, well, do you need any help? And hardware and software coordinate with each other saying, well, what needs to be done? Are you blocked? We implement quite a lot of agile, but I'm talking about agile as an Agile Manifesto, not Scrum and all of this Kanban thing. We actually trying to be actually agile within the project. And mastery is we actually push ourselves to learn new things like machine vision and this Cartesian to Riemann nonlinear space transformation. I learned a lot about quite advanced mathematics from that. And the chap who went from mechanical engineer to— well, he's not even— he wasn't mechanical, he's civil engineer specializing in concrete, became a really, really exceptional software engineer. AI. So without trying, we kind of implemented all three, and only now I'm starting to realize what we did right. We did this, you know, I'd love to—

good environment and good culture within the team to get things done. But let me give you a challenge then. So because you're not commercially driven, you don't make, uh, sacrifices in that sense, because, you know, autonomy or, or doing what you want and working on what you want is, is basically given because you can just go and choose. But sprinkle some, some dependencies on roadmaps which are commercially driven, and suddenly, like, you lose that ability, right? Because, you know, the, the commercial team comes in and they go like, we just sold this $2 million contract which basically expects us that, you know, your robotic arm or vision to work somehow differently. Yeah. And then you have to work on that.

That's a very good question. That, that is another sort of the whole different dimension to the problem. How do you maintain the three main motivators and at the same time not lose sight of the the commercial incentive. In a nutshell, I have no idea.

It's always a trade-off. It's a trilemma, basically.

Yeah, I can speculate on this.

There you go.

I think probably the best thing to do is to fold the commercial team into engineering team. Because hardware and software work together quite cohesively and we understand each other. There really shouldn't be any reason why you can't do the same between engineering and product management. And so that to some degree takes me back to the first industrial company that I worked for. Tab Biosystems, where the interaction between engineering and product management was really, really well done. And it was done really well on the process level as well as interpersonal level. So I could go to a product manager and say, look, this particular requirement is very hard to achieve. How flexible are we on this point? So you introduce a little bit of— you could call this you throwing a wrench into the works by challenging them on their requirements, but at the same time, it helps polish the requirements to the point where we deliver exactly what the customers want without spending so much time developing the perfect solution that by the time you hit the market, customer already moved on and you are too late. Because there must be a balance between how good your solution is, what it costs, and how long you take to deliver it.

Okay. So it goes back to that Agile Manifesto. Like, let's not, let's not try to solve all the problems at once. Let's maybe solve one and go to the market.

Yeah.

And just iterate on the solutions. Okay, I like that.

But I'm not a commercial side person, so this is my take from sort of this side of the barricade, so to speak. How commercial would approach this, I don't know. It'd be— this is the next bit of my personal growth is to cross on to the other side.

It's a very healthy relationship which you described. So that was a good culture. And I can, I can, I can tell you other cultures or other businesses I've been in where especially in the startup scenes, you know, where, where the, where cash flow is, is, you know, it's basically the blood of the business. And, you know, in startups you probably have maybe a runway of 6 to 12 months, you know, until the money runs out and it just lights off. Right. So, so you have to always renew that. And the pressure at some point becomes that it just doesn't become about these opinions. It's become about making the sale. And then the commercial teams getting under that pressure, they basically overpromise and they pretty much always underdeliver because they, they just want to get the money in and they go like, oh yes, we do everything you ask. And then they make a sale, which business is happy, you know, and then goes back to the team and team goes like, Like, no, like, reality is that it's just not gonna happen.

I've been in the environment where commercial over-promised and then engineering said no, and, um, it's not a particularly pleasant place to be from a point of view of managing this. If I had this problem I would say if commercial comes out of a sales meeting and then goes straight to the engineering and say, "Look guys, we basically had to do this. We had to promise because otherwise it'd be no sale." And if you cannot deliver it, then the end result is going to be the same anyway. So 'Let's see how we can compromise and try and deliver.' That would probably be ideal scenario where they don't hide and then just send an email to engineering and say, 'Right, you have to do it now.' Some humility in the process, effectively, like, 'We know we caused you pain.' Yeah, be straight up with engineering. Come over and say, 'Right, we had to promise, and if you deliver, we're going to keep the lights on.' And if you don't deliver, then, you know, the result is going to be the same anyway. So might as well try. The problems I've seen mostly start emerging when commercial don't really communicate. And it's fairly obvious, isn't it, where people don't communicate with each other. You start second-guessing what is happening. And then the, the, the sense of purpose starts disappearing. Like, why are we doing this? Because we've been working 18 hours a day for the last 6 months and we start losing the focus, start losing the sight of a purpose. And once you lose purpose, then the whole trifecta of, you know, mastery and autonomy, autonomy goes away. Because if you, if you really, really tightly supervise, the autonomy goes away. And if you have to deliver something very, very specific, you don't get the opportunity to become better at something. That goes away and suddenly the 10% shares that you have in the company, they don't mean nothing.

Yes, exactly.

Yeah. This is— this makes no difference to me because I can go and work for $100K as a just, you know, as a software engineer and I'll be home on time to tuck my kids in. In bed. What's the point? Why am I here?

Exactly. That piece of motivation which you touched, that, you know, you have that external motivation and internal, or extrinsic and intrinsic. And, you know, you're absolutely right. As long as you're getting your bills covered and you feel comfortable, like you can go to holiday, you know, you can buy things if you need them, like that's it. That's where it pretty much caps out for many people. Because when you talk about you know, I want to be wealthy, people don't mean they want millions or trillions and they want to ride Ferraris. They just don't want to feel the pressure of financial burden, like, at all. It's not paycheck to paycheck, or I'm always in, uh, you know, in loans and I'm in overdraft with my bank. It's just comfortable. Like, that's being wealthy. And that, that, that, then money doesn't become a motivator. Then it all becomes like, what I'm doing with my time. How am I spending my time? And like, you want that purpose and, you know, you want that destination to, to go towards.

So psychologically speaking, the biggest killer of creative thought is anxiety. And the two examples are if you are anxious about how you're going to pay the bills, then that will kill your productivity, creative productivity. And the same goes for biologists. The— an average biologist wakes up in the morning and the first thing they have, first thought they have is, am I gonna get to the lab and gonna have to scrape the dead cells off a petri dish and start the experiment again? Because they have no confidence in the process for a variety of reasons, and majority of which are the fact that the process is very, very difficult to reliably replicate. So they can't even debug it properly. And so it's— we're trying to solve the anxiety for the biologists so that when they wake up in the morning, they have 100% confidence that when they get to the office, the cells will be fine. And the engineers on a global scale, when you wake up in the morning, you don't need to— you shouldn't be worried whether your heating is going to be on or whether you have to climb into your overdraft to pay I don't know, for a tank of petrol. Once that worry disappears, then all you're going to be focused on is becoming better at something and trying to be useful to other people, because that's what makes people happy.

Yep, 100%. It's a good topic.

Yes, it's a whole topic for another podcast.

And it seems you did that very, very well. you know, without targeting towards it, you know. And that's what, you know, kept you guys going for like 4 years. And now we have something which, to my knowledge, is so, so close to, you know, being potentially commercial— commercially usable. So let me ask this question, which was around my head for quite some time while you were talking. Are you utilizing out— like, outside of— let me rephrase that. So you're utilizing AI, you got the vision, you know, you got some open source solutions, but when it comes to writing code, when it comes into that deeper level, do you guys go like, hey, you know, Copilot, hey ChatGPT, can you give us some math solutions on this one?

Yeah. So both Copilot and ChatGPT we're using extensively. I would say probably 80% of the code base was written by AI. 20% was written by a human. That 20% is where we are breaking new ground.

So AI completely falls on its face when it doesn't know what it doesn't know, isn't it?

Exactly. So it seems like AI is very, very good at rehashing old problems in a new framework. So if you want to implement even a very, very complex algorithm in a new setting, and you give it constraints, and it has to be in Python, and it has to create these many classes, and it has to fit into this API, it'll do it. And it will do it really, really well. And 99% of the time, it works first time. You basically, you get a code spat by Copilot, you press run, and it works. It's amazing. Where it falls on its face is when you try and say, well, I want you to do a conversion from a linear into Riemann space, and it says, nah, what are you talking about? I have no idea. I've never seen the code like this, because nobody wrote code like that. Another problem with AI is it cannot think globally. So the architecture had to be designed by a human who saw potential pitfalls and strategic goals that we might have in 2 years' time. It seems like AI is very, very good in a— within a constrained space. It can go very, very deep. But if you ask it to broaden the search or broaden the solution space, it struggles. Another example where we use AI is when This was quite, quite funny because we tried to understand complex biological processes because none of us are biologists. We had to try and understand complex biological processes in the context of automation, and we struggled. And then one of the software engineers just opened ChatGPT and said, well, explain to me this. And it produced very, very coherent, usable text, which they found quite useful to understand things like, well, what is passaging? It's quite difficult to explain, like trying to explain refactoring to I don't know, someone who does management for a living, right? It's a complicated thing. It's a simple thing, right? You and I understand what refactoring is like this. Very simple concept. But someone who is alien to the whole software engineering, it's very difficult to explain. Same with a biologist. You ask them, "What's passaging?" and they're like, "Well, that's obvious," and they struggle to explain what passaging is. So we used AI to help us comprehend sort of cross-border subjects, stuff that came from the biology and biotechnology into our space. So AI was sort of a translator of ideas, which was quite useful.

Okay.

And some, some of it was used in the mechanical engineering space, but In the mechanical engineering space, AI is like completely useless. AI seems to have real problem with spatial reasoning. When I was trying to get AI to design the arm, it got completely confused and started telling me stuff that's demonstrably not true, trying to convince me that, you know, like the robot has to be constrained within its own footprint. And it's hard to explain exactly what was wrong with it, but I think fundamentally AI has— because it's disembodied, AI has a problem figuring out spatial stuff. Like hand-eye coordination, which was— now you think about it, it's sort of obvious, of course. It's, it's a machine. It doesn't have understanding what a table is.

It—

the table is just an abstract concept to, to an AI. To you and me, it's, it's like, how would you take this table through that door, right? That's very simple thing, but to AI, it will gonna get completely lost.

Okay, so that was where you effectively even, you know, pushed the current solutions of Copiloting or co-coding with AI to basically its limits with your project, and when like it cannot help us in that particular area, but in other areas which are maybe more generic areas, you still got some productivity boost by just—

Oh, massive. Yeah, I think AI made our current level of software progress possible. Okay, if we had to just typing all of that extra 80% of code would be a lot of work, a lot of manual work, and then debugging all of that and, you know, creating test cases. Um, I think this is another quite broad area where AI is quite useful, is once you have a code base, you can, you can get AI to write you very, very good test cases.

Yeah, that's true.

So you can have automated pipelines and you basically have regression testing sorted. You, you know that if AI wrote your test cases and your regression test in a pipeline has passed, it's very, very good sign that that code will work. Yeah, just as intended.

Yeah. It's like you're becoming less of a coder but more of a builder where you just— that's, uh, yeah, that's probably good because you're getting these blocks back now, so you need to put them together for, uh, you know, you— before you would just write code, right? You were a developer or, uh, you know, a programmer. Now it's like you don't really need to go— in majority of the cases, you don't need to write this. You can just get the block of it and then you just need to connect these blocks into a much bigger solution. Yeah.

So in the future, it's possible that, for example, right now when you hire a junior software engineer, what do you do? You ask them to write a linked list class, right? Or you ask them to write a bubble sort algorithm. In 10 years' time, do you even need those skills? That's like, do you— are you even going to need junior engineers? Yeah, junior software engineers, for sure. So how are you supposed to go from your software engineering degree into the workspace? Because you now have to jump over these 5 years of training that now occupied by AI, because that's producing all of that stuff that's used to be produced by junior engineers. But writing algorithm is not the only thing that junior engineers are training. They, they're learning to work with their colleagues, they're learning to learn, they're learning the process, how to organize, what motivators work for them, how they like to be managed, how they like to receive feedback. There's a whole bunch of stuff that you learn that is sort of happening in the background, and now you suddenly that whole slice of your professional life disappearing and, uh, how it's going to look like, what's it going to look like. That's, that's a fun thing to think about.

Yeah, it's a good, good question to ask. I mean, I love how your solution at every level has some type of AI solution. So you got, you know, Copilot helping you with the code, then you come to your hardware, you know, you got the You've got the vision, you're training to recognize objects, and then your end result as well is like that. You're trying to automate the biotech. So it's just like at every level there's AI help, which already helps you to automate your own processes, leads towards your solution helping to further automate, you know, these processes. Just like a stack of stack of AI solutions, you know, towards automation. So this is, you know, great innovation to see happening. So let's switch the gears, you know, let's just forget about AI. While you were giving me the whole picture in the beginning, one thing which came up to me was, I'm sure it was quite hard, you know, in how you guys did, like, you know, your research and development, how you talked, how you developed. How do you, like, in your professional life and, and in that hobby project, how do you strike this balance of how you tame the house and you get it into sort of like more ordered way of working?

Uh, yeah, this is something you and I talked about before. Um, sort of goes back to the fundamental concepts behind how product development works, and, and it's, um, and it's meant to be a very tight balance between chaos of a creative process and order of— so the order part is alien to me. I am a very, very chaotic person, which is partly why I'm pretty good at coming up with novel solutions. But for example, organizing the team, even though it didn't really need much organizing because people are everyone involved is highly professional, but we still need to sort of create schedules and see who is blocking who and what's going to be the next sequence of work packages that we need to deliver. That one is a struggle to me. And again, this takes me back to my time with Tab Biosystems, where prior to working in, in the industry, I was in academia, and academia is by its very nature is extremely chaotic. Like, we had no version control, there was no versioning of prototypes, there's nothing, it was pure chaos. For when I was working for UCL, it was 4 and a half years of just mad process which I dare not repeat again. The end result was quite, quite nice, but I don't want to work like this anymore. It should have taken less time, for example, is one of the things I learned. When I joined TAP, one thing I realize now is that I went into the environment where people were as chaotic as me, but they also realized the value of order. So we had proper version control, and we had part numbers for mechanical parts, and it was all traced. So if you consider extremes, if you're only chaotic, then you will be extremely successful in creating something new, But you will struggle to finish it and struggle to turn it into something tangible. And it's trivial stuff, like, you know that you've come up with some sort of really cool new device, right? You start ordering parts for it from eBay. Those parts arrive, and if your entire workspace is chaos, in 2 weeks' time when you need that part, you're not gonna find it because you have— you're completely disorganized, right? That part is gonna just sink into the sea of chaos surrounding you. Similarly, if you are too orderly, go to the other extreme, and everything is so regimented that you are stifled of any creative endeavor, you have a path and you just walk down that path regardless of whether it's the right path or not, because that's the, that's the rule, right? You can't come up with new things because new things fundamentally require that you venture away from the trodden path and you go into the woods because there's treasure in the woods. You need to strike balance. So the way when I rebuilt my office at home, I set a boundary. So, and it's an actual physical boundary between the chaos and order. So I have shelves everywhere and they're all marked where the screws are, all the electronic components, all the build components, and they are very, very regimented, and I try and keep the, the order. Everything on my desk is chaos, like total chaos. There will be wires, there will be parts that I just printed, there'll be bits of the machine that I'm building. There is like a prototype for the next thing I've made, and the things that go from order into chaos sort of become part of the chaos, like wires and screws and printed parts. The stuff that— and that's easy, you know, taking stuff from the order and into chaos, that's very easy, and it's meant to be easy because you know exactly where everything is. Stuff going back is quite painful, for me at least, because now I've made a microscope, for example. We recently finished the microscope prototype. Now it's unfinished in a sense that, well, it works, but there is more work to be done. But now this work needs to be done by somebody else, and I hooked that microscope to my network, and the software engineers put a tunnel into the Raspberry Pi that runs that microscope, and they're going to do some work. There is no space for that thing because it's It's on the boundary between chaos and order. Where does it go? I don't know. So right now it sits at the bottom of the machine of our incubator. It's—

so if you— I mean, I want to feel like your natural self will, will take one of the sides over because like if you have this physical boundary and you go like, here's an order, here's a house, like I think that's temporarily like the end result will be that the house will just eat the order. Away if you are chaotic by nature or it's going to be opposite? You think you can sustain both of them?

I don't know. That's, that's a very, very good question. I don't know. I'm struggling against chaos. Yeah, chaos is my nature.

I—

it's how I work. But I'm, I'm also trying to be orderly because it's necessity.

Yeah, I do love chaos as well, but like, I feel like that's my actual strength and I tend to work for companies who goes through through either venture capital-induced growth or through the merger and acquisition-induced growth because you go from, you know, here's we are right now, 100 people, and next day when the money comes in or the merger happens, you know, here's us now, you know, 6 times bigger. We have other people on, you know, other countries and we now need to merge into something as a cohesive business. It's very chaotic by nature. And I do well in these environments. And initially I didn't understand why I always end up in this, but it's just because I gravitate towards these. I just like these environments, and I call them challenging environments because you need to take that house and you need to put it in order. But the moment I get the order in it and things flow, I'm like, I'm like, I'm bored. Yeah, like I need another one, right?

Yeah, you totally understand.

So, so it's like, yeah, I think just, you know, who you are and you just play into that. Anyways, Uh, in the spirit of the show, we have this question. Uh, in your mind, or from your experience, or just your opinion, what is the most important one thing for, for Tech Growth and Ventures?

Oh, one, that's a difficult question. I mean, it depends on how you define growth. Are we talking about market share? Are we talking about breaking into new markets?

Okay, let me put the only thing which matters, which is your financial reports. It's always the revenue line. It's like, you know, at the end of the day, business is either winning or losing, and the win is defined by how much money you're making.

Market fit then.

Yeah.

You had to define market share.

Market fit is just as long as you're making more money.

If your product is a good market fit, fit, then— I mean, you can still screw up even if you have a good product. Like, your sales could be not particularly good, and marketing could be shit. Yeah, um, but in the long run, um, good marketing, good— although marketing could be good, sales could be good, if the product is bad, that's a non-sustainable model. Although there are plenty of examples where—

where it works.

Where it works.

Yeah, exactly.

There are industries where marketing is everything, like fashion, for example, is like— I don't understand those industries at all. Where I have expertise, a good product, although again, there are counterexamples. To where product is sort of mediocre but still works. But again, those are probably because there are no alternatives. It's not because that product just won.

That product won due to lack of serious competition, or competition is way too expensive and the pricing modules are a huge jump.

Yes. So, and, um, Yeah, okay, market fit.

I love it.

I think product-market fit is probably— if I had to pick one, it would be this. I would—

yeah, yeah.

Everything else can be solved by, you know, getting new people, trying new avenues of approaching the market, getting new CFO if something doesn't work. But if your product is a poor fit to the customer, customer needs Yeah, it's like, it's no-brainer, right?

Just build something people want. It's like, that's your market for business. Like, if you're building something people don't want, it's like, how are you gonna sell it? Well, you can, you know, sprinkle good marketing around this, have very aggressive salespeople, but like you said, it's not sustainable. At some point, the market will just go like, I tried it, it's shit, bye, right? But if you use YouTube and you don't have premium, there's some type of like Chinese business which is pushing these like very, very cheap products. I forgot the name. Temu. And it's just like ad over ad over ad. And I know like bunch of friends going like, yeah, yeah, I tried it once. It's just shit. Like the products come in, it's just so, so cheap. Like you never would go buy it again, but you still try it once, right?

Yeah.

So as long as you get that marketing running and you have these new customer acquisition modules going, you can run it.

Yeah, you essentially using the market space as a consumable.

Yeah.

So you're working through the population and that's part of the product essentially. The consumer is part of the product. You work off a customer, they dissatisfied, but it doesn't matter because you've already made a sale.

Yeah, exactly. You already, and it's driven by people wanting cheap stuff. Like people love bargains. Like anybody look at something and goes like, oh, this is cheap. Like just that is a huge drive for people just buy 'cause of that.

Yeah.

There's this intrinsic feeling of you getting a better end of the deal.

Yeah, and our first prototype, for example, fell apart after 6 months because the, because I bought very cheap 3D printer plastic and it literally crumbled after 6 months of sitting in the garage.

Yeah, there's no such thing as cheap good thing. It's just like, it's not possible. The price is— I mean, you can overpay it for sure, but at the end of the day, if you have a good, you know, sustainable brand who's been in the market quite, quite some time, they will have a price on the product and there will be a reason why they have that premium. Because the quality of the product will be just there, right?

To me, it's the peace of mind. That's what drives my purchasing approach.

Same.

So remember that thermometer for the meat?

Oh, Meter 2.

Yeah, yeah.

Put it in the meat, don't worry about it. Yeah. Cooks your meat.

And so recently after we had— we used one for Christmas, I bought one for myself and we did a couple of cooks and it was fine. And then we did another one and I decided to mess with the settings and it just came out horrible. And then I remembered my own frustration where I spent 6 months tuning the product. We deliver it to the customer and then a week later I get a phone call saying, "It doesn't work." And then you fly halfway across the world, you land and they say, "It doesn't work." So, "Well, show me." And they completely break your protocol that you designed for them. Spent 6 months polishing that protocol. They completely ignore your instructions and then say, "Well, it doesn't work." So, "Well, why aren't you following the protocol?" Well, we don't think it's necessary. And it gets so frustrating. And I thought, I am exactly the same. I decided to mess with something that I don't quite understand how it works because I'm an arrogant engineer and this is an engineering product and the meat was undercooked. And why did I mess with it? I don't know. So yesterday we did another cook or the day before. And I looked at my wife and I said, I'm not going to do anything but just go with the recommended settings. And it just came out perfect.

There you go.

And the company probably has a bunch of people just doing these experiments over and over. So, you know, the people don't have to worry. You press one button. Well, how many presses are there? Like you say, start to cook.

Put it in the meat, choose what meat.

Yeah.

Press go. Yeah.

It's like 30 seconds setup, right? And you know the end result is going to be perfect.

Yep.

That's it. All you have to do is just listen to the beeps and do what the thing tells you.

Yep.

Completely alleviates the anxiety. Oh, I need to weigh this. Is it half an hour per every half a kilo plus another half a kilo, but only with certain meats? And it's annoying.

Yep.

Right. This thing just solves a real problem and it solves it really well. And the software is excellent and they gave you all the recommendations.

Yep.

So I sort of realized that this is what it is. You, you need to get rid of the anxiety over the end result. If you do that, people will buy it. It almost doesn't matter how much it costs.

Okay, that's a very good shout. Okay. Anyone in your network, you know, friends, colleagues, which you would want to recommend and it would be a good addition to our show?

I have a couple of people who can probably come in and talk about struggles with tech growth. One is almost purely hardware and one is purely software. Okay. And they're both at C-suite level and both are, they both know a lot about the—

Do you want to give us names or not on live show?

No, we haven't discussed it. So.

Okay. You want to check with them first?

I'll check with them and if they say yes, I'll introduce you.

Okay. Thanks for doing this, by the way, Salavat. That was a lovely conversation. This was fun. I glad you enjoyed it. Thank you. Thanks for coming. All right, cheers.

Thanks.