#208 Arpit Mohan is running on builder's high

Transcript

⚠ The following transcript was automatically generated.
❤ Help us out, Submit a pull-request to correct potential mistakes

Arpit Mohan 0:00
We ended up building India's first humanoid robot. It was called a cube. It didn't do much it danced a little and it played football. So nothing really useful. But it was dancing playing football. What

Tim Bourguignon 0:12
else is there new world?

Arpit Mohan 0:14
That's true. That's the only two things worthwhile.

Tim Bourguignon 0:19
Hello, and welcome to developer's journey to podcast, bringing you the making of stories of successful software developers. To help you on your upcoming journey. I'm your host, Tim bourguignon. On this episode 208, I receive Arpit Mohan arbit has been always fascinated by technology from the unscrewing off his childhood, the mangochi all the way to helping create the first humanoid robots in India. I hope we're going to hear about both stories today. After creating a mobile game that went viral, he co created app Smith, and took over the CTO role. And what started as an off shot for him a bio game is now a full business used by over 1000 teams, employs people in eight countries, and it raised 10 million in capital. So it's a real business. Operator, welcome to dev journey.

Arpit Mohan 1:13
Thank you so much. I'm very excited to be here and talking to you today.

Tim Bourguignon 1:17
Oh, it's my pleasure. But before we come to your story, I want to thank the terrific listeners who support the show every month, you are keeping the dev journey lights up. If you would like to join this fine crew and helped me spend more time on finding phenomenal guests, then editing audio tracks, please go to our website, Dev journey dot info, and click on the Support me on Patreon button. Even the smallest contributions are giant steps toward a sustainable dev journey. journey. Thank you. And now back to today's guest. RB. As you know, the show exists to help the listeners understand what your story looked like and imagine how to shape their own future. So as usual on the show, let's go back to your beginnings. Where would you place to start of your journey.

Arpit Mohan 2:09
So I've had a few different of tars and things that I really wanted to do. As you said, you know, as a kid, I was always fascinated by tearing things apart. And thankfully, my parents were okay with that, because they knew they'd have to pay somebody to assemble it back, because I didn't have those skill sets to put things back again. But they were perfectly okay, you know, letting me disassemble the Tamagotchi. For listeners who are maybe not old enough, it was a little virtual pet that you could keep in your keychain and in your pocket and roam around with it. And that was the first time I actually took apart like a digital and electronic device. Because you know, like the eight year old me inside my head. I expected a live dinosaur inside it for some reason, who's going around playing I don't know what I expected. But I took it out and I came across this green chip this board. And it was so underwhelming to kind of see that my entire life for the past one year has been powered and revolved around something that this little green chip was powering. And that just opened up a whole new like sort of possibilities that oh, if this can do this little green chip can actually engaged me for a year, what else can I take apart and what else is out there? So it dismantled the computer, the VCR, the television, just started taking things apart to find that, you know, if there is a green chip everywhere, or if there is different things, and obviously encountered a lot of different, you know, devices, you know, different hardware elements across the board. And that's when I actually decided that I wanted to be a hardware engineer. So my dad was a mechanical engineer, as I call it, like the, you know, quote unquote, true engineer, or an engineers engineer. He roamed around with like, actual tools in his hand. And yeah, and so I always thought that Oh, to be an engineer, you have to be you know, you should have tools at least a soldiering gun, or you know, like screwdrivers and hammers otherwise in order to be an engineer, per se, so I always wanted to get into hardware and that's why in university got involved with robotics was very, very, it's a very fascinating sort of subject and it's, I think it's one of those disciplines which kind of combines a lot of different areas hardware, software, AI, data engineering, etc. Like kind of puts it all together so was very fascinated with robotics. And we ended up building India's first humanoid robot, it was called a cube. And it didn't do much it danced a little and it played football. So nothing really useful. But it was

Tim Bourguignon 4:37
dancing playing football What else is there new world

Arpit Mohan 4:40
that's true that's the only two things worthwhile Yes, yeah. So doing that building the humanoid robot was many hours of frustration of you know, of destroying batteries, blowing them up, blowing up chips, and motors left, right and center because I didn't read the manual, something that required a two volt system that required two holes I gave it 20 volts, it just fried. So a lot of frustrating nights, but I can I distinctly remember the first time that the humanoid stood up on its own, like for the first time, like everything powered up, and we managed to get it to stand. It was like dead in the night it was around 1am 2am Something in the lab. And I that's a feeling I will never forget. And it's that high of like, like I call a builder's high that you know, when you see something work for the first time ever, and after that point have always cheesed that Hi, oh, you know, when something is not working, all I'm trailing myself when I'm debugging something, or, you know, something's not going right is. If this is, if this is frustrating, and it's taking long, guess how good the high will be at the end. Because everything has a way of working out some way or the other, at some point it will click. So if it's more frustrating, that means you want to get a bigger high, you can. So I've just been chasing that builders high for a long time. And yeah, and Post University, we wanted to formalize this robotics project into a company but at that time I was I chickened out, and I went ahead, I got a job, I got a regular job. And those a little scared of starting up at that point. And so I just got a regular job. I was like, hey, you know, I'm out of university, I need to earn money, I need to, you know, prove that I'm an adult. And because all those jobs anyways are invariably soft, predominantly, for most engineering schools in India at least. So that was actually my first software development gig. Like I'd never I'd written software, but I'd always written software, to control the motor, or to do something. And you know, I'd never written, you know, software for the, you know, like, like a SAS software or telecom software, where it is just purely software. And, and because I'd always looked down upon software as being like, the, the lesser man's game of sorts that, oh, you couldn't do chip design and VLSI design and robotics, that's why you're coding sort of stepped down in life. By getting into my first real gig as a software working in a professional environment, this was at Verizon, it was my first job. And, and seeing the expansive software that that Verizon or a telecom company requires just to get, you know, you and me to talk to each other. And it's just incredible, like 10,000 engineers across the globe, working just so that when I dial your number, you know, Tim picks up and we can hear each other's voice. So the end result is a very simple thing. But it requires so much engineering just to make it happen. And yeah, and that was my first eye opening experience that this is something this is much more complicated than I initially thought it to be. It's not a simple for loop running somewhere. And since then, you know, started to go deeper into software started to read more about code, etc. And but I always wanted to start up. So So you know, I chickened out in my final year, and a couple of years of working at Verizon, and there was another low code company called Kony back then all the low code didn't exist as a term, it was just a rapid application development platform. So So worked there for a while. And that's when I've always wanted to start up. I always wanted to become an entrepreneur. So we ended up starting up with with a logistics business, it was called QRP. It was a cash on delivery business, very India specific cash centric economy. And we literally just had people go to houses, you ordered something online, somebody would come at your house, doorstep, pick up cash and deposit it in the bank. That's basically for people who didn't have credit cards, or use credit cards back in 2010. And that over there as well, I because I had no real deep love for software yet are you is in fact, the operation said I was, you know, going to lead operations at that point. And we had another engineer from Google, who was quitting his job. And he was starting up and with us as a co founder. And he was the CTO. He was like the de facto CTO, you're like, oh, you're a Google engineer. You do the tech within a month. He just got a better offer, I think, from Google, and Google incentivized him to stay stick around very smart man, he took that that opportunity and he left. And that's how I became the CTO. So serendipity made me the CTO. And this is not something that I designed or I thought I would be ever because I always thought of myself as maybe, you know, yes, I have an understanding of tech and understanding of software, but I'm really, you know, maybe an operations guy or You know, finance guy maybe. But once I became the CTO, and then I had to lead the tech for doing the logistics business since then there has been no looking back. That's when I actually started to love the craft, I started to appreciate what goes into building anything that's long term that's worthwhile and spent a lot of time learning about web development and coding and, etc, because that was the first web development project I'd ever done. I had no idea I'd never coded in Ruby and etc. So, yeah,

Tim Bourguignon 10:33
did you remember the moment when that flip? That switch flipped when you maybe left this mindset behind of saying, I'm not the technical guy? And when it became No, I can do that. And I take pleasure in this. And there's something to do to remember though,

Arpit Mohan 10:51
yeah, absolutely. We our first iteration of, of garbage was built in Ruby on Rails. And that was the first time I was actually doing web development. And when I started to kind of write Ruby, and I was learning Ruby, and I was writing for the startup as well, when I started to write Ruby, that's when, like, I will always be thankful to Ruby for introducing that, that love, where things just felt natural. Like I was writing what I was expressing, like, what I was thinking I was expressing in code. So and it was a very close, it was a very close match to English. So what you write in Ruby is a very English like, it's not, you know, C or C++. It's an abstract syntax that you have to learn. But Ruby was very English, like it was I was able to express myself. And that's when I started to really appreciate the craft and the poetry that goes into, like, it just seemed like writing poetry at one point, that oh, you know, this is what I'm thinking, this is what I'm writing. I think the next the only other language, I think, which for me has come as close to that is khaolak. Where, again, when I first saw Golang, I was like, this is exactly what I felt with like Ruby. And you know, this is just a refreshing air, you know, fresh air that goes on has about it. So that's why I really like GoDaddy as well, for that same reason.

Tim Bourguignon 12:12
Okay, I can really relate to that. It's really feels at some point as if you're fighting against the language, if it's not the right one. And then suddenly, one comes and seems to be thinking like you, and then it clicks. And it's so fascinating to discover this, I had the same thing with C plus. And when I was fighting with C plus for a while, and then at some point discovered peyten. And in Python, was it for me? Oh, now it's doing exactly what I wanted to do. But why? Why was like,

Arpit Mohan 12:41
yeah, exactly. It's one of these higher abstraction languages like Ruby or go Lang, or Python also is a beautiful language for that matter. Just does that too at times. That's why I very strongly believe that in when people are learning to code in university, or school or etc, people get introduced to Java or C plus. And they're fantastic languages, that absolute world courses. But maybe as a first introduction, maybe Python or Golang, would be so much more better suited. Because it just you stop fighting the language, you start, like just doing things because again, that builders, it's like that gateway drug to building. And so the moment you can give schoolchildren or like people early in their career that like that, that click, that happens, I think it will be much better for we'll see a lot more developers and a lot better developers, because now you start investing in the craft, trying to get better and trying to know more about stuff. So yeah, I really think Python or Ruby.

Tim Bourguignon 13:41
On a side note, I think this is what I've been seeing in many of the boot camps that we see around, people jumping in and learning quite often, either JavaScript or TypeScript, TypeScript, or Ruby on Rails, and getting ramped up in three months, and becoming productive, and really seeing the effects of what they do getting this build as high as you are describing it. And that's why I think these boot camps are in a way very successful, you get at it very fast. And you don't have this is learning curve of C plus, for instance, we can take months before you really start to understand what to do to be successful and get this billows high. So there might be something.

Arpit Mohan 14:25
Yeah, absolutely. I think bootcamps I think Ruby, Python, Node js, I think they've done a wonderful thing for boot camps also, for getting ramped up to being productive in a professional environment. And being able to at least build your first prototype your first MVP project or, you know, whatever you had in your mind, just being able to see that in action. It might be, you know, you might obviously, you know, five years hence, go look back at that project or that code and be and think, like, how could I write such crappy code? And if you don't, then you probably haven't learned enough because you haven't evolved? So you should always looking be looking back at your code five years ago and be like, that was really crap. So yeah, I think they've done wonders for boot camps and for a lot of people's careers as well, you know, people looking to switch from other, you know, other disciplines other, you know, expertise and trying to move to development. I think it's done a really good job for them as well.

Tim Bourguignon 15:23
Coming back to this first experience as a CTO, how many developers did you have with you to on this job

Arpit Mohan 15:30
at our peak? We had, I think, seven developers? Okay. It was a very small team.

Tim Bourguignon 15:38
So that means you were always a hands on CTO really developing?

Arpit Mohan 15:41
Oh, yeah, absolutely. I was very hands on I was coding, you know, day in and day out. Like, that's what I did you know, that that was my identity. And it took me 10 years after that, to actually disassociate myself from that identity of being a coder, or being a developer. But you know, being a CTO means that I think with AP Smith, it's the first time that you know, the team has grown a little bit more and and, you know, we have about 40 Odd engineers working with us today. So being able to disassociate myself from that identity that being the CTO means I have to code was a very hard thing. And it's the first time in like, 10 years of my career that I've actually managed to do that. Then I realized that there are other things that are more important that are things that will move the needle a lot more than me just coding all day long.

Tim Bourguignon 16:33
Okay, I have a question burning my tongue. I'm wondering if I should keep it for for later on other housekeeping Anyway, now that you are that you disassociated CTO, the CTO role and the coding role, as you say, how'd you get your builders Hi.

Arpit Mohan 17:33
Oh, okay. There are two. So the cheat answer to this is platform. And it's a local platform. So I, you know, I find every each and every excuse to build apps on App Smith and do a little bit of coding over there, or you know, find a bug. And then if it's a small bug somewhere, or just an error message, I don't like, etc, just go in very quickly do this little fix and just make a change. Because, to me, I still think that's where my comfort level lies, like, I'm comfortable in code, while you know, leading teams, etc. Like you said, there's a lot of unknowns, there's, you know, the outcomes are uncertain. With coding with compilers, there's a very set rule, like, if you do X, you're gonna get why JavaScript violates that rule a lot. But that's a whole other discussion. But by and large, you know, like most programming languages, stick to a predefined set of rules, there's a lot of comfort to be that I gained from this, if I do X, I'm gonna get y. But now, for example, with App Summit, like last weekend, my nephew, He's two years old. And so my brother wanted to chart his height and weight over a period of time, and try to predict where he will be in like, when he's 20. Like, is he going to be as short or tall as us is he going to be as fat or thin as us are, etcetera. So just building like a little application that that he can use to very quickly every you know, month, they go for a doctor's checkup, and you know, his height and weight, he just wants to weight quickly go on the phone and just punch this into the app. So that over a period of years, he can track his child's you know, height and weight. And so this just a little app is a little fun side thing to do. So I keep doing these little applications on the side. And that's the cheat on so that's the way I cheat. But on a day to day basis. I think now I've started to subconsciously unconsciously sort of try and tell myself that the builders high comes from building teams, like it's the people that matter a lot more the code, the language, etc. is all like transferable, it's all learnable. It does not matter whether you come from a Python background or a Java background. It just does not matter. What matters a lot more is the team that you're working with the people that you're interacting with, how you communicate with them. Are you polite enough for you empathetic enough, were you firm enough in your in the way you kind of spoken? You know, called out your decision, etc. So I think now the builders high, the RPL cycle has gone up. So it's not as quick as you know, type a line of code, execute and see your test pass or fail. But it's gone over to like a few months now. Because decisions that we take today, they start to show up, you know, their fruits, maybe three months down the line, or six months down the line, that's when we, when we will know whether we, we made the right call or the wrong call. And then we re orient ourselves again at that point. So the builders high is slightly elongated, the RPL cycle, but it's still there. Because when you see a team like really working out, or you see an engineer that maybe wasn't performing as well as you expected, and then you go, you have a chat with them, you work with them a little bit, and then six months on, they are by far the most, you know, high performing person in the team, that's when you start to feel that builders high that oh, you know, maybe we can get teams to work with together we can work get people to work in a certain way. So it's a whole different reason.

Tim Bourguignon 21:02
Not always the easiest, but also rewarding. So I understand which is okay, but I propelled us way further in the future, what happened with this first intrapreneur experience?

Arpit Mohan 21:14
So the first entrepreneur experience, I think, so we it was really good, we achieved product market fit right off the bat. I mean, we launched the service, and we had product market fit. It took us maybe two months to two or three months to actually build the infrastructure or like at least the basic infrastructure to actually service some of these customers that we were getting. But off the bat, we had like a clientele that was just like, you know, phoning, calling us up and saying, how do we pay you? Like, we want your service? How do I pay you just give me a way to pay you. And that's when I took it for granted a little bit. I was like, oh, you know, you do a startup, you think of a product, and it will work? Right? You know, that's how it's done. Right? And oh, my God, such a rude shock, because so we sold the company, so we got acquired, and because two years hence, you know, we ran it for two years, and we got acquired. Because one of the things that, you know, that ate us as founders was that we weren't growing fast enough, or we weren't, like, you know, there are all these peaks and troughs in any, you know, lifecycle a person's life cycle, the company's lifecycle, you're gonna see some highs, and you're gonna see some lows. And we've started to see some of our lows, where team morale was not as high as it used to be in the early days, we're starting to go through like a little bit of a plateau period. And we thought that, oh, you know, this company is not going to be successful, or this is not working out. And we kind of sold it to another larger logistics player. And back then there was this other entrepreneur also who talked to us and he said, you know, are you sure you guys want to give up, like two years into a company or a product that's working, you have 800 paying customers, you have some public limited companies paying you, or when you want to give this up? And we were like, No, this, we need to give this up, we have a better idea. And we want to do this Venmo thing. Again, this was back in 2012. So Venmo didn't exist in India and p2p payments didn't exist. So we are looking, you know, how cool would it be if I can message you money or so we just moved on in our minds to like a new idea, a new thing that we wanted to do. And oh my god, it took, again, like 10 years after that first, first sort of initial product market fit seen a little bit of success with the product. It took us again, 10 years. And I don't know how many, three companies 10 years, I think, maybe 18 or 19 products in the middle for us to find the next one that actually had a product market fit, like so. So that's when, you know, it was a very humbling experience. The next couple of years after that, where we had all these questions about what if had we just stuck it around? Had we just done this? Have we just done that. But when we sold the company we'd moved on. And so we did a little bit of multiple products. In the meantime, we did something in telecom within FinTech sector. And we did, we did an AI, we tried to get something in AI working went to YC, Y Combinator for an AI company, again, didn't really work out because we overestimated the technology, what AI or what NLP could do. So we kind of overestimated where the industry was at that point. And it didn't really work out. And while we were sort of tinkering around with what to do, this is in 2017 2018, we were tinkering around with what to do. And we randomly just built a mobile game on the side. We're like, oh, you know, while we figure out what we are really doing with the company, let's just you know, we have three or four engineers. Let's just build a mobile game for fun. It'll be good to kind of keep ourselves sharp. We'll keep learning something. We'll do something and

Tim Bourguignon 25:00
just a question in between you keep saying We Was it always the same group? Did you keep the same group running?

Arpit Mohan 25:08
Me and my co founder Abhishek. So we've been co founders since like, 1012 years now. So so when I say we I liked him in him and me, but yeah, but the team used to change a little bit. So between different companies or different startups, we would change the team a little bit based on what we were doing the AI company, which morphed into the mobile game company, so that the engineers were the same. So so we are the literally the same team that was doing AI. And we just started doing mobile gaming, just for the fun of it.

Tim Bourguignon 25:35
Okay, sorry. Go ahead. Yeah.

Arpit Mohan 25:39
And any other mobile game, like I don't know what we did, we were right place, right time, or something clicked in the market, we went viral, that mobile game went viral. And in three months or four months, we had a million downloads on the Play Store, we had 100,000 people playing the game at any point of time during the day. And it was just a roller coaster of a ride. Like those six, seven months that we ran the project, that we ran the product, no weekends, no sleeping, we just I gave up. Like the entire team sort of gave up on sleeping. Or even weekends, my wife came to visit me she was doing a master's, she came to visit me from Amsterdam, back to Bangalore, I completely forgot about, like, I have no recollection of my wife visiting me. Because once we shut down everything, and I was telling a colleague of mine, you know, I haven't seen my wife in six months, it's gonna be really, really good to kind of, you know, unwind, and you know, go meet her. And she reminded me Wait, there was a woman who used to come with you to Office for two weeks, three months ago, who was that? I assumed she was your wife. And she would just sit on the table, and she would work on the side? Who was that woman? And I was like, oh, cha. Yes, I did meet my wife. Oh, I completely like that memory had raised it. So my wife isn't too happy about it. Yeah, so it was an absolute crash course in trying to figure out what a high growth product or a high growth startup may might look like. And since then, you know, we look at Facebook, we look at you know, Instagram or WhatsApp, you know, on these incredible growth trajectories. And after this, seeing this for like, six, seven months that we ran this project, I have no envy for anybody who's working on Facebook in the early days, or Instagram in the early days, because it's just night after night of incredible sleeplessness. And because in a consumer product, weekends were when we used to see more traffic. So weekends are definitely working days. And you maybe got a Monday morning of like, not even the entire day of Monday morning, where you can come in a little late. That was our holiday schedule at that point. Yeah, so So 10%, daily growth is not fun. But it was an incredible learning experience. Because I learned a lot about you know, performance optimizations about how just to keep the lights on for with for engineers, we will for engineers doing 100,000 users per day. And that's when you know, that's where the idea of absolute sort of originally was an offshoot from there, because we were getting about 3000 support emails a day complaining about oh, this is not working, or the leaderboard is like this, oh, my points didn't get credited or whatever, right. So. And while this represents maybe 3% of our user base, just the sheer number was huge. So we had to support engineers, and they came to us and they said, you know, we need help, we need you to build us an admin panel, so that we can, you know, manage these this influx of emails that are coming in and support requests. So now we had to divert engineering bandwidth from actually trying to build the product and just keep things alive to building an admin panel for the support team. And this was in 2018. We were doing it from scratch. Again, we did used we use React Bootstrap. And so we had admin and Bootstrap. And that's when you know, the brain goes, you it's 2018. Why is this still so hard? There are a number of companies out there so many teams out there, everybody needs a way to manage the users. Everybody needs a way to manage their offers or their product lines or their inventory. Why are we doing this from scratch? How is there nothing that just connects to my Postgres dB, and immediately just shows stuff to me on a table that I can edit out? Like if excel at that point, could connect to Postgres, we would have literally used Google Sheets or Excel. So So yeah, so that was the birth of abdomen so that's why we shut down the mobile game and we said, You know what, this is very exciting, but I don't think this is going to make any money out of this. We were an eve that's when I I also realized about founder market fit. Like, as founders, we were very, we're very b2b sort of people, we understand businesses, we understand how to make a rational argument to users. But it's very hard. It's a very different ballgame with a b2c product, where users may love or hate your product for something that is very inane, or very tiny, very small, that you cannot, or you may not be able to predict beforehand. So like, Instagram had filters. So it just became really popular. And I don't know, if maybe Instagram, the founders, they had a lot of insight over there. Maybe they didn't, I don't know, it's just that I realized that I wasn't cut out to lead a b2c team. And so we shifted our focus, we shut down the product moved on, and did a, b to b product. And that's where estimate is today.

Tim Bourguignon 30:55
That is awesome. And that is a nice ramp up and story coming up. Now, one thing is different now than before, though, is if I understood correctly, you had seven engineers at the beginning of this very first startup that worked very well. And now we have 40, do you think these are fully? So how was this transition from a from a small team of really one pizza team or two pizza team where you know, everyone like friends almost to 40 is already too much to really know, everyone work with everyone every day, etc? How was your your feeling and your your journey into this transition, being the CTO of the small team, and now becoming the CTO of an organization?

Arpit Mohan 31:42
Right? It's actually been a little gradual, thankfully, where, if I was dropped into a 40 member team, you know, back in the day, I would have just lost myself. But you know, thankfully, it was gradual, where, you know, we started out with just two engineers, and then over a period of three years, we ramped up to, like, 40. I think the biggest differences, for me are definitely, like you said, I know everybody, but I don't know them at a personal level, we're not, you know, you know, coffee buddies, or beer buddies, which I used to be back in the day with like five or six people. That's definitely not the case. But I think that's the part that I actually don't like that much that I don't know, people that have a personal level, as much today, it's something that we're trying to get better at. But the other aspect of, you know, of learning to do this was a building a layer of management of, you know, leaders underneath me, because I cannot be doing one on ones with everybody. It's impossible to do 41 on ones every two weeks, come on. Yeah, so fair. So, so just being able to break the organization down and, you know, divide people into teams. And, you know, so I try to talk to say everybody wants a quarter, but and to meet people who immediately report to me when, you know, do bi weekly one on ones, we have a lot of emphasis on that. And especially growing in a distributed team, like I've never, I've never worked in a distributed team, I've never worked in a distributed team before, and just being able to pull in. So we've read a lot about how GitLab does it like GitLab is like, the poster boy of, of running a remote or a distributed team, I think said, you know, sets the bar for how teams should run. And so we kind of read a lot about how Basecamp is doing it, how GitLab is doing it, how some of these other companies have been doing it at scale. And, and that's when we started to, you know, start to grow up a little bit. And when we realize that, you know, it's we are in a real business, we, you know, we have a lot of people that we need, you know, cater to teams within the team and our users and our community as well. So we have a lot of people to answer to. And so it just means that we need to do a better job. So started moving a lot more to written communication to doing a few rituals where we get to meet people. But yeah, it's definitely been a big learning curve, in terms of graduating from seventh to in terms of how, you know, how I am seen, and how I am heard. So I'm a lot more conscious about what I say to whom I say, and you know how I put it across, because that also makes a big, huge impact. Because I might say something offhand, on on one of these zoom calls or something like that, or I might just write a brain dump and share it with people, but just how it gets perceived is very different from person A to person B. And so I'm a lot more conscious about how I'm expressing myself also to people but I think that's now become a big part of my learning journey is leading and you know, be Being able to talk to people. I've been an introvert. I am an introvert. So so for me just doing this talking, that is very different experience.

Tim Bourguignon 35:09
I understand I understand. So what's in your future still doing more of the same leading people, more teams more a bigger organization? Or is this intrapreneurship idea coming back? Or do you get enough of an entrepreneurship right now? How do you see that.

Arpit Mohan 35:23
So I have a very strong philosophy that the history of software is the history of teams, I'm a builder by heart, but I know that there is nothing worthwhile that I can build on my own. That's impossible, you know, like, so the age old myth of a lone hacker, somebody you know, in a garage, typing away furiously and hacking into the CIA machines, that just does not happen. That's, that is all like, you know, Hollywood would like you to believe that happens, that just does not happen. So in order for us to be able to build anything worthwhile, anything that lasts a period of time, means that we need to be able to work with teams, we need to get teams to work together people to work together and set, you know, some ground rules and some standard operating procedures for people that you know, code of conduct, that this is how things will happen here, or this is not how things will happen here, so on and so forth, give them a guideline or a framework to operate in, and then just let them be. So what it's imperative to get teams to work people to work together in teams. So I think for me, in the future, a lot of my focus is largely around, being able to get your software teams to work better, to work with each other. And secondly, is with absolute, you know, again, for the first time we, we did a large open source project. So I have contributed to open source a little bit in the past. But it's more, it's been like bug fixes, or some small things here or there in some library or SDK that I would use. So nothing's really worthwhile. And absolute was our first open source project. And just embracing the ethos of building is something I'm still getting used to, I'm still trying to get better, a lot better at. And so just trying to do a much better job of building in public with our user community, it's a whole different way of building products. You know, you have the apple way where you know, they're super secretive till they release the product. And each of your products seem to be a massive hit each and every single time, I have a lot of respect for Apple, because we somehow have this vision that this is what users want. And that would be a great way to go. But for all of us who are not Steve Jobs, and you're not Apple, just being able to build in public accepting our mistakes, and our flaws in the open. And then course correcting is a learning curve for people like me, where we've always built in closed source products before. Trying to get a lot better with my open source contributions and building in public with the community

Tim Bourguignon 37:58
that's rebuilding and public is really a whole different beast. It's really something else. I this question is always a bit cringy. But I'm going to ask you anyway, you were able to talk to yourself at this moment in time, just after your studies, when you say no to this first path toward intrapreneurship. And you could give yourself an advice. Would you say something? Would you hint at something that you didn't do? Well, what would be the advice you would give yourself?

Arpit Mohan 38:24
I think the first advice I would do is give myself is the obvious buy Apple stock. That's the first thing. The first thing I would say, but apart from that, I think not doing it initially, or not doing a startup right out of college, I think was helped me kind of appreciate, you know, what it took to startup like I saw a few teams work, I saw how soft I mean, how engineering teams are operating. So at least gave me a little bit of a framework. And of you know, this is how the world works. And and, you know, the other advice I would kind of give myself is so initially one of the reasons why I chickened out was I wasn't very sure, where we will be able to raise money. Like how will we you know, get off the ground, because getting off the ground is the is one of the hardest things to do going from zero to one. And so how are we going to get funding? How are we going to convince people to invest in us, you know, financially, or because we have nothing at this point, but we still need to live and eat. And so the advice I would probably give is talk to your father earlier. Because you know, I didn't talk about this with my dad at that point when I was not doing the startup. But the day I expressed that I want to do something like this. I you know, I'm thinking about doing something like this and etc. He was, I think a little more excited about the whole idea than I was and he's like, you know, if you guys want to do this, I'll be your first angel and And then he gave us like, some money to keep us running for like about six months, he said, You know, I can't, he's like, I can't pay for the business and etc, that you need to get, you know, external investors for, but you know, six months living it is on me. So you don't have to worry about your living expenses. That's all taken care of, you just focus on getting your business off the ground. And so while the entire family was a little, which I say, a little conservative, about, you know, come with us, I come from very engineering lead, you know, job security is paramount, etc. So, and then sharing my father kind of come in and say, oh, you know, you want to start a business? Yeah, absolutely. Go for it, you know, six months living expenses paid off, don't worry about it. And so that was our first angel. So yeah, I would tell myself, like, talk to your father or hear about some of these things. So your parents or you know, people who've seen these cycles, they, you might think that, you know, some of these things are outdated. I mean, their thoughts are outdated, or they don't look, they no longer sort of apply to the current ecosystem. But human beings in general, stay the same. So while certain things might have changed their basic principles for your parents, or your grandparents, or great grandparents, etc, they actually don't change, people want the same things. And so my dad just wants to see, you know, your parents just want to see you financially stable, they want you to have a good life, they want you to be happy. So those basic things never change across cultures, or generations, or whatever. Every parent wants that. And he just wanted that he's like, he saw that I'm not going to work. I'm not happy in my job. He's like, you want to start up? You clearly want to? Okay, go do it. So I should have maybe just done that.

Tim Bourguignon 41:44
I mean, it worked out. Alright. And it's always the trick of this question. So yeah, pass you took is very good. But that's indeed a very good point. Thank you very much for that. So Arpita, where would be the best place to find you online and continue this discussion or start a new discussion with you.

Arpit Mohan 41:59
So the best place would be someone Twitter, my handle is Mo HN. So that's my handle. And you can always reach me out on email, on MI, M, E at the rate Arpit moveon.com. So those are the two best places to kind of reach out and talk to me. And we can always talk a lot more about running teams, and you know, learning from engineering principles, applying engineering and algorithmic principles to running teams. So that's something I'm super, super passionate about. That's how, that's how I found my apartment, I used an algorithm to find an apartment. So

Tim Bourguignon 42:38
I see scrapping some database somewhere and doing some magic around it or not. I need to hear the story before.

Arpit Mohan 42:47
So there's this principle of how do you make a decision? So at the beginning, when earlier, we were talking about, you know, interviewing, like for example, in your case, you had to interview a bunch of people, and then you know, pick a few candidates for your now. So the question that comes up is how many candidates do you interview before you actually make a decision? Because if you're building a team from scratch, do you want to talk to five people before you get a sense of these? Are the people that exist? These are the skill sets that I can expect? And how much are they actually asking for whatsoever. So those are important that does this. So you can use this to find a partner, you can use this to find an apartment, you can use this to find your team members, is reject the first 33% of whatever you see doesn't matter. So, so time bounded, so if you want to find an apartment in the next two months, so the first 33% of the time, just go looking for apartments, and first couple of weeks reject everything, say no to everything. Post that find the Say Yes to the apartment that looks the best yet, like, up to that point. And the first apartment that you see that is better than anything you've seen, just see us don't open anything better than this. Because algorithmically it's proven to not work. So that's the best way to find an apartment. It's algorithmically, the most efficient way to find an apartment. So,

Tim Bourguignon 44:07
okay, I see where you're going.

Arpit Mohan 44:11
So there's a beautiful book called Code cod and algorithms to live by. These are two books I highly recommend to especially engineers who are looking to incorporate their engineering or algorithmic or apply those principles to their daily lives. Yeah, because I often see people like you know, when you're looking for a partner on Tinder, or you know, looking for apartments on Airbnb or something, you're constantly just like flipping and you're like, oh, you know, is this person the best person to be with or is this apartment the best? Please be with me and there's an algorithm for it. Just go for the algorithm. Too much about it,

Tim Bourguignon 44:48
says the engineer. arfid That is a very nice way to end it with an algorithm. It couldn't end anywhere else. Thank you very much.

Arpit Mohan 44:59
Yeah, absolute It is an absolute pleasure talking with you, Tim. Thank you so much.

Tim Bourguignon 45:04
Likewise, and this has been another episode of developer's journey. We see each other next week. Bye. Thanks a lot for tuning in. I hope you have enjoyed this week's episode. If you liked the show, please share rate and review. It helps more listeners discover those stories. You can find the links to all the platforms to show appears on our website, Dev journey dot info slash subscribe. Creating the show every week takes a lot of time, energy, and of course money. Will you please help me continue bringing out those inspiring stories every week by pledging a small monthly donation, you'll find our patreon link at Dev journey dot info slash donate it finally, don't hesitate to reach out and tell me how will this week story is shaping your future. You can find me on Twitter at @timothep ti m o t h e p or per email info at Dev journey dot info talk to you soon.