Data lifecycle management for seamless source-to-destination data movement, next-gen analytics and AI integration.
An automated data orchestration and pipeline management platform.
An AI-powered, enterprise-ready Gen AI platform for internal teams.
Parsing engine and interactive mapper.
Precision parsing, mapping, transformation & health data analytics.
Data lifecycle management for seamless source-to-destination data movement, next-gen analytics and AI integration.
Custom, integrated predictive layer.
Automated data movement for faster time-to-insights.
Consolidated data for improved accessibility.
Structured data for reporting, analytics and model training.
Data lifecycle management for seamless source-to-destination data movement, next-gen analytics and AI integration.
Explore how businesses leveraged our data solutions to their advantage.
Keep up with the latest trends to scale faster and outwit competition.
Data lifecycle management for seamless source-to-destination data movement, next-gen analytics and AI integration.
We are a bold team supporting bold leaders like you ready to adopt and migrate to new technologies.
Discover the essence of our tech beliefs and explore the possibilities they offer your business.
Unlock your business potential by leveraging Gen AI and capitalizing on rich datasets.
Lead your business to new heights and scale effortlessly with expert guidance along the entire customer journey.
Unlock the boundless opportunities presented by digital transformation and thrive in this era of rapid change.
In this episode of the podcast, our host Ratnadeep engages with Advait, an accomplished engineering leader with a career dedicated to advancing customer-centric innovation. The conversation navigates through various facets of engineering leadership, exploring defining moments that have influenced Advait’s approach, fostering a culture of innovation, aligning engineering decisions with customer needs, overcoming challenges, and embracing data-driven insights.
Data-driven leadership emerges as a central theme as Advait discusses his reliance on data to guide key engineering decisions. He shares instances where data-driven insights have driven pivotal choices and addresses the art of balancing quantitative data with qualitative insights, ensuring technology harmoniously serves the human aspects of customer experience.
Ratnadeep: Welcome everyone to another episode of “Leaders Perspective”, where we explore the minds and strategies of the industry’s foremost leaders. Today, we are honored to host Advait, one of the leaders in the field of director of engineering who professionally truly embodies impactful development, transparency, and constant learning. His passion for understanding customer problems and translating business needs into technology-driven solutions has led to a career marked by innovation and growth, with a focus on delivering exceptional customer experiences and a leadership philosophy.
Guided by a data-driven decision framework, Advait’s insights are set to inspire us. Join us as we dive into his world of engineering leadership, exploring how to lead Innovation, navigate challenges, and drive customer success.
Advait, welcome to ‘Leader’s Perspective’.
Advait: Hey, I hope you’re having a great day. I’m really excited to be here. Let’s just dive in then.
Ratnadeep: So let’s get to the point. Looking at your career till now, you have been leading various engineering projects. I’m curious to know if there has been a defining moment that really shaped your approach to engineering leadership. Would you mind sharing that with our listeners?
Advait: Absolutely! When I was just out of grad school, that’s when I started my first thing, which was the fitting room as that’s where we both met actually. While I was working on it, absolutely as a deep tech problem- the fitting room, which is like this whole idea of creating virtual rooms for people to try stuff digitally in fashion, you sort of get used to the idea of failure.
You will fail and that’s the only thing that’s constant. And amongst those failures, you have to sort of learn how to navigate, how to understand that you’re not the bad person here for failing. You’re not having failures because you’re incompetent, because you are suffering through that imposter syndrome of understanding that it’s okay to fail as long as you’re learning something from it. I think that has been a massive defining moment for me.
Because that sort of also changes the way you approach your team. Your team suddenly understands that it’s okay to fail, that it’s okay to experiment and it’s okay to basically not get the result that they wanted. As long as they try it, and as long as they don’t do that same mistake again. I think when you internalize that into how you grow your product, how you build your product, how you do literally anything, it sort of helps build that cohesiveness in the team.
It helps understand how the company would grow. Because at the end of the day, everything that you do is something that defines where the company would be. Let’s say a month or two months from now, that whole idea of learning through- okay you’ve failed at creating a virtual room that loads up in, let’s say 10 seconds. But you’re getting 15 seconds now, why is there a gap of five seconds?
What is it that is actually not working properly? What is it that is failing? Why are some of the outfits not loading properly? It’s those tiny things that you have to sit down and introspect, and understand. That’s okay, maybe I try this thing instead of trying a rapid time SquareSapce to queue everything up. Maybe we can try a different multiprocessing tool. Maybe there’s a different way of optimizing the GPU usage which is something that we did a lot.
And that helps you in figuring out, how you actually approach this problem, not just because you want to solve it. Because as an engineer, that is what you do. You want to solve problems that you think are unsolvable. But you also have to realize that in the position that I was, at the fitting room, in which I had a massive team under me if I’m failing, I have to make sure that the team understands that it’s okay to fail. And that it’s okay that we spent, let’s say a month even, two months just trying something that didn’t eventually work.
Now we know not to ever try that again. And failure, when you’re at zero, is a lot more palatable than when you’re at massive revenues. Because if you fail at massive revenues, it stings a bit too much. then it stings when you have literally no money coming in because of it. So I think that shaped the way I approach engineering problems and how I approach leadership itself in a team. Because something has to
You either learn that failures are like the most terrible thing in the world, and you know you are afraid of them or you can say, ‘You know what? they’re part of my life.’ They’re part of your career. They’re part of your growth and just learn and grow from them.
Ratnadeep: So while you were talking to us about your journey and your career, you touched upon a very important aspect of the team. But when we talk about teams, one of the most important words is team culture. You have been a director of engineering, guiding teams to be both innovative and collaborative. Can you share a story where this culture made a real difference in your product development journey probably?
Advait: Absolutely. I can iterate back on the idea of culture. I am very young as you all, probably can see. So I never really had the chance of getting into the idea of corporate politics, getting into this whole thing of that you have to do things a certain way. Because I came in from an academic background. I did grad school and all of those nice fancy things. And then once I was out of it, academics pretty lacks, except for the whole hierarchy structure, which we can get into sometime later.
But the one thing that happens when you’re working with everyone who is almost your age, but older, or people who are a lot more relaxed about failure because academics is mostly about failure, is that you sort of have this nonchalant attitude towards how to deal with problems. You don’t take anything personally, and that is sort of what has reflected in the way I handle my team, the way I manage my team, and the way I grow my team.
Literally, do whatever you want as long as you’re getting the results. As long as it’s not illegal to actually say that. but it doesn’t matter how we approach a problem because the way you think, the way I think, it’s always going to be different because of millions of reasons. So I can’t really expect you to do things exactly the way I want you to do. And that is sort of how I started working through the team and I’ve kind of developed that culture over the years now.
It’s like seven years now in which you first start with the idea or at least when I was just out of grad school, it used to be like- okay this is the problem, do it. And every single person on the team would have the same objective. You just have to solve that problem. Then I later realized that not everyone is going to be the same. Some people require a lot of push, some people need less push. So you change your approach on a per-person basis.
For example, we had this incredible DevOps engineer who had come in from this lab in Toronto. An incredible engineer, who never really delved a minute into machine learning even though he worked in a machine learning lab. And when I interviewed him, he was trying to get into this non-academic professional world. But because he was so academically inclined and he’s an introvert, and all of those things you could see that in the interviews itself.
He was uncomfortable with answering questions and speaking. Because not everyone is built like that. That’s what you learn in computer science. A large number of people just don’t like to speak. They’ll do their work and they’ll be fine. And it’s okay. That’s the one thing that we realized. I gave him a chance and I said, ‘Here’s the thing, I’m taking a risk by hiring you. You don’t have the exact requirements that we have for this role but I like you as a person. And I think you’re really hard-working, really talented. I think you could do it. Just give us six months and you should be fine.’
Last week or early last month, in July, he messaged me saying that he just built this massive infrastructure thing that is completely scalable on the machine learning tools that we have at the fitting room. He’s been actively developing things in the machine learning tooling space like internal tools and stuff like that, which considering his background what he studied in undergrad what he did in academics is a massive difference.
But that’s just a year and a half in which you just have to trust the people that you hire. You have to basically assume that you’re going to be fine, that they are adults who understand how to do things on their own. All they need is a little bit of guidance, a little bit of support, and someone who says, ‘You know what? do it, it’s fine. If something bad happens, if production just fails tomorrow, I’ll take the heat for it. It’s fine. Don’t worry about it, just go ahead and do your stuff. I’m there.
I think that is how I approach my leadership. I know there are a lot of people who don’t do it this way because again as you grow your organization to have a thousand people, two thousand people, then it becomes a little different. But right now, I don’t have to do that. I have a small team so I can get away with just a bit of lacks with everything. But yes, that’s basically how I do it.
Ratnadeep: Okay so is this what we call impactful development? If it is or if it is not, perhaps, what does a culture of impactful development mean to you? If you think about it as a concept,t what does this concept mean to you? Can give an example with it, it will be helpful.
Advait: So back when last year or so, I was reading this book called ‘Principles by Ray Dalio’. Incredible Book. Ray, I think he’s one of the top performing investors like the hedge fund and just the General market. And a large amount of his philosophy of how to actually grow a company and how to actually manage teams comes from the ACT fact that as long as you’re honest about everything that you’re doing, as long as you are very straightforward with how you speak, how you do, and there’s no correctness associated to you, it’s a lot more efficient.
Impactful development is on the same idea which is just do things that create impact. The impact doesn’t have to be like, Oh I just grew the revenue of the company from hundred dollars to a million.’ That’s fine. That’s still impact, that’s a good thing. But sometimes impact can be, ‘Hey I just spent a year developing this tool that is probably not going to be used anymore’. A year is a long time, let’s say a quarter. ‘I just spent a quarter developing this tool that probably is not going to be useful but I know what we shouldn’t do ever.’ Or figuring out what the customer needs exactly and developing for that niche.
A large amount of how you do development has to be centric on the customer that you’re trying to serve. If you’re a startup that is just starting up, which has zero customers, just choose one or two of them and figure out okay if I have to basically create a product just for that customer, how do I do it? What impact can I make on that person’s life? How can it change the way the business is done to create a positive flow or a positive net flow down the line?
That is all that means for me, at least. That’s what impact-free development means. Just do things that push the company forward, pushes your team forward, pushes you forward as long as it’s not illegal. Honestly, every sort of thing that you do is sort of impactful in certain ways, as long as you learn from it. As long as the team learns from it, and as long as it adds to the knowledge, base of the team or the company.
Ratnadeep: You touched upon a very important point. I think it’s an interesting segue to my next topic, which is customer centric approach. So aligning engineering with customer needs is key to probably your philosophy as I can understand. Can you walk us through how you make sure this alignment happens? Perhaps with an example of a process that works well for you.
Advait: (Sorry I just sort of yanked my mic out of the way)
So a large amount of what the customer-centric approach is, it’s just talking to your customers quite literally. I think DoorDash first started this program back in the day, in which the cashers or the software developers in DoorDash would literally just deliver food. The CEO still does that. Because that’s when you understand what the issues are. Customer Centric approach doesn’t have to beat this massive framework of you have to do everything right or you have to do everything with the customer in mind. If you want to understand what the customer needs, just speak to them. Just literally email them. Get them on a call.
Just text and whatever. If you’re small enough, you can text your customers. If you’re a SAAS company, you can do that. Just do it. Just talk to them, ask, ‘Hey what makes this platform better for you? What makes this product something that you cannot live without? What is that one feature that it misses? What is that one feature that you can’t live without? Develop that product, add that product. See if that customer is still using it. See if that customer still feels the same. Do it for one customer, then do it for 10, then do it for 100. Then figure out what customer profiles you have. If you have all students, figure out if they are engineering students or art students. Find out the materials.
Semiconductors are a big thing today. Just figure them out. Figure out what every single one of these niches needs. And then once you understand exactly what that person wants, just develop for them. Developing niches is not a bad thing. Developing for one customer is never a bad thing as long as that one customer can now be converted into two. That two can be converted into ten, then two hundred. Because if you find, there are seven billion people in this world. No one is alike. As much as we say everyone is unique, no one is that unique. As long as you don’t micro-focus on just one customer, and as long as you understand what is it that makes your product stick for that customer and just iterate on that, and make sure that you have a significant customer base, you’re fine.
The company that I’m working on right now, it’s all CV. It’s sort of like a social networking platform for creative fields. So be that your video production, your film production, architecture, anything that is not programming basically. Because a large amount of these people rely on visuals instead of a resume, which is paper-based.
Networking them, using LinkedIn or quality work for that matter, which is like a new platform now, it’s not really that useful. Because visuals are not really the mainframe of these platforms. And while we are developing this, and we recently just launched, we literally did cohort analysis. We had 10 friends that we bought here.
(I don’t know if I’m allowed to say on this podcast, but they’re adult, thirty-plus. So everyone was of legal age)
We bought beers for them, we bought them dinner, bought them to sit in one room, all of them. We were like, ‘Hey this is the platform. You all are one of a few of the top people in LA who do illustrations. Some of them work at Netflix and all of these places. Just tell us what you feel, tell us what this product makes you feel like, tell us if you would use something like this, tell us what this is missing.
It was a two-hour dinner drink slash cohort analysis. Let’s just call it that for business purposes. But we understood that we lacked six or seven different features that are crucial because that is what people use Squarespace for. There’s a reason why SquareSpace and Linkedin cannot be merged together. Because they just are like so separate right and for a creative person. If you want to build social networking enter SquareSpace or SquareSpace into social networking. You need those certain features, you need that accessibility and ease of moving things around and making the pages seem like they’re just created just by you.
You want things that are up in the forefront because visuals are important so you want to make sure that those things pop. We’ve built a very simple platform that didn’t do any of this. It just took us two hours to understand everything that was missing, two and a half months to develop every single feature, literally the date we developed and released that feature. We called those same 10 people again and we called 20 more people because in the two and a half months we figured out okay why not.
Let’s just get 20 more people, a cohort of 30. We told everyone we will buy your bear the next time maybe after you fundraised or something. Just help us out again, just create another profile, and see what feels right. Everything that you’ve done until now has been deleted. If your friends are fine with it, just do it for us. The one caveat of doing this sort of approach is that in this way you learn a lot as long as you have friends, especially those who are not always nice to you. As long as you have that one friend who will say the truth to your face exactly the way it is, you’re fine. Because you have to start from somewhere and even as you grow today, we are sort of growing. And that’s a good thing. But that also means that you lose that personal touch with the customer because know away from the customer. Because they are beyond your reach.
In that case, just find the customers who either come back a lot for using the platform differently than you thought using the platform. Figure those people out, find someone who lives in New York, because again New York and India are the big creative field industries. Find someone who lives in New York, find someone who lives in La, find someone who lives in Chicago. From all the people that are using your platform, ask them why they use the platform, and what is so useful for them, because they’re living and working in a different industry.
I asked my friend who does game development and I was like, ‘Hey, you literally cannot use this because you’re under NDA and stuff. It’s the companies that you work with. Just use this platform anyway, just go and do your stuff from your undergrad. When he was learning game development, he did that. He was like, ‘This is what works for me, this is what doesn’t work for me from a technical person’s perspective who is in design.’ which is again a creative field but is not really a creative field. Because you’re working with Unity and what Ubisoft thing was called anyway Unreal Engine. Figuring out these customer issues and then aligning yourself to allow them to succeed by using your product is the only thing that matters in a customer-centric approach. Honestly, I think products that are built that way fail a lot and iterate a lot because again you’re sort of navigating through what is right about the customer and what is wrong about the customer. Because customers have wild needs sometimes, which don’t really translate well outside that one person or two. But it’s okay.
There’s a reason why you get stories that are iterating out of the same topic. LinkedIn has stories. No one really used it. They moved it but they thought it’d be useful because some niche would follow or they would wait. And that’s okay for them to experiment. Because what’s the worst that’s going to happen? You’re going to have to roll back some changes. Who cares? You’re changing your code after every six months anyway.
Ratnadeep: So customer feedback experimentation, those are the key. Now let’s talk about some challenges. So leading engineering teams come with their own set of challenges, especially in today’s dynamic markets. Can you share a story about overcoming a significant obstacle? And can you also describe probably a project where the technological hurdles were complex yet you managed to create something that truly resonated with the customers?
Advait: So when you’re building any sort of team, the first thing even before technology comes into the picture is their people. They’re human beings. And I know this sounds funny or rude or whatever but being a human sometimes is just tiring. Because every single person has their needs, every single person is different. And a large part of just building a team is figuring that out. A large part is even before you actually go into the technology of it. Even if you go into the market, just figuring out and building a team that sinks with each other, that is always on the same page, that understands exactly- if I’m saying something they get it before I complete a sentence, that is a great thing. If you can do that you’ve achieved half of your issues. Because then you know they’re on the same page. They’re in sync with the knowledge base that the company has.
The other thing that the team has to be is a child. They have to be able to move quickly. They cannot be the people who are too slow. Especially in the startup world in which the market changes every six months, in a world in which you don’t even know if your product is fit for that market. You have to have a team that is aligned for it. You cannot have a team that is like, ‘No. I need to perfect this one front-end thing.’
If you have that team you’re probably losing out on days, if not weeks of development. Because you are trying to perfect that one small thing. Just release it. What’s the worst that is going to happen? People are going to say, ‘Hey, it sucks!’ Great! Why does it suck? You have an answer to why. Just keep on iterating until that why just end, until the whole idea of it becomes ‘This is not bad’ start popping up.
In a cohort of 100 people, you just need 20 people to say this is not a bad thing. From those 20, you need to find 20 friends or evangelists. Get those 20 people to bring another 20 people right so you get a very multiple-level marketing scheme.
But that is how products grow. The only reason why you use Instagram is that one of your friends uses Instagram. The only reason why he used Instagram was that she used Instagram, as opposed to their friend who used Instagram. That is how you grow a product. You just make sure that your product is in the vicinity of people who would use it and you have one person who is shouting that product out for you. That’s just the Evangelist that you want. The only way in which you can do that is by making sure that your team is ready for it. If tomorrow the market changes and suddenly it is illegal for you to send out emails without whatever reason, it’s not ever going to be that way which is assuming, your product and your team are ready with different things that they can do instead.
A major example of this could be something at the company at which I was the director of engineering, which is Buena. We were quite working part-time for a thing that we saw from the data that we were receiving after six or four months of development. It was that a large number of people would open their emails but they wouldn’t really click on them, which is worse than them not opening the mail. Because why are they not clicking on it? And we tried a ton of different things. We tried A/B testing, seeing if a certain design appeals to them.
Or just to give you context, we’re now working in a creator economy space. So for a creator’s email to not be opened is surprising. For example, let’s just say you have like a favorite YouTuber or an Instagram artist and you received an email from them and you are not opening it. We sort of wonder, why? Why is that happening? Or if they’re opening a lot of it then you also wonder why is that a random thing? Is that a thing that where that data is corrupted? Because if the industry average is at two percent and you’re suddenly getting fifteen percent open rates, you’re sort of wondering why. That shouldn’t be happening. That’s stupid.
And that’s okay. That’s not a bad problem to have in any case but we used to see the industry average people opening their thing, but not industry outages things. No one was clicking on the links, even if we made links frontend center, even if they were highlighted properly, even if the text was proper. That sort of got us thinking that maybe the email approach is not the right thing. Because when you think about it, for a large number of creators, most people assume they’re trying to sell you something if they’re sending you an email and if they’re seeing a story about something. That’s great because they’re creating content and you love their content which is why you follow them.
But unless it’s a niche, which is only for fans, or when you have some subscription for a service, you don’t really buy anything from an influencer. Unless it’s their makeup line or an Amazon sale that they’re getting into. And we realized that maybe that is an issue. And again this comes with a lot of maybes. Because by this point, we had about 200k monthly active users, approximately. So figuring out the exact answers becomes slightly difficult if you’re a small team. So you have to prepare your team and be like, ‘Okay, the next one and a half months or six weeks, we are just going to keep on iterating.’ And they’re figuring things out.
We’re going to keep on testing small changes, we’re going to keep on testing alternate solutions. One of my team members went, ‘Hey, why don’t we just send them an SMS? Everyone in this world sends you an SMS, from your bank to like a random real estate developer. Why don’t we just create an SMS thing in which it’s like- hey it’s your favorite creator, I’ll now text you. Who wouldn’t like that?’ And we’re like, why not?
(Sorry, I don’t know if I’m allowed to curse YouTube)
But why not? Who cares? What’s the worst that’s going to happen? You’re going to lose five dollars in testing, will you? It doesn’t matter. Just create an account and test it out. We chose a small group of people and asked them to provide us with their phone numbers. Half of them did, and some of them did not. The ones that did, we just tested out with them. So did they actually like it? Turns out they do. Because it comes directly to your phone and you generally check your messages at the end of the day or at the beginning of the day. No one really checks their messages when they’re working. Most people don’t.
So they were just clicking on the links that we were sending them. What this also allowed us to do is create a situation in which not everything had to be a sales pitch. Some things can just be something like, ‘Hey! I’m really excited to let you know that today is my dog’s birthday,’ which is an SMS that actually went out. ‘It’s my dog’s birthday, just send me all your wishes on my Instagram stories.’ It’s a personalization on an SMS that feels different than a sales pitch because now you have a line of connection which is one way.
Don’t get me wrong. No one else could reply to them and the influencers couldn’t read those messages. But suddenly you had messages that were going in that were slightly more personal but they also could send in stuff like, ‘Hey! My Amazon wishlist is on sale,’ or ‘Hey! Here’s my Amazon shopping page. Why don’t you buy something from it for yourself? or ‘Hey! It’s Father’s Day. Why don’t you buy Father’s Day gift for your dad?’
That changes the dynamic drastically between an SMS and an email. Because you send your emails to your professional colleagues, you send an SMS to your best friends. That sort of dynamic we wouldn’t have really had if
Ten years ago, emails were the king. Then Slack came and email sort of lost their thing. SMS is becoming a thing now because everyone’s sending you emails. I have 500 unread promotional emails all the time. I don’t read them because I don’t care about emails. I just get them from everyone because I’m using the same email ID every time. But no one really knows my phone. Or only a special few people know my phone number. So I read all my texts. My text boxes are zero and I think that is the way you overcome changing markets. Because the only way you can do that is just to keep swimming. The minute you stop swimming, you travel.
Ratnadeep: I understand what you’re trying to say. Ao I’ll take a little turn from our discussion. I want to understand one thing, being a director of engineering and being a technologist more or less, throughout your career, how do you determine what kind of technology or what kind of technological tools or tech stacks should be involved while building a product?
So there are two different types of startups. One is an early-stage startup, one is a growth startup. Let’s say an early-stage startup would obviously be building or trying to build a product. A growth-stage startup already has a product, already has good customer feedback and you know they would want to iterate on their product. They would want to imbibe new things which they have understood from their customer. So how do you determine for both these sections what kind of technology would be fit for a new product and for a growth stage startup? How do you say, ‘Hey, I think you know this was a mistake. We should probably go on this route or something of that sort.’
Advait: So when you’re building some technology product and you’re a small team, just go with the lens of the team. It’s as simple as that. Just figure out if you have a team of three people. What is it that each of those three people knows? If there’s someone who understands React really well, they’re experts in React for the frontend, just use React.
You don’t have to build a massive technology overload in which they have to learn new technology because they feel it’s the best thing ever. It’s the same with the backend. Same with other stuff and the infrastructure. Just go with your strengths. When your team increases from five to ten, you have a tiny amount of time to experiment. Maybe you figure out that instead of using RabbitMQ for queuing if you can use Celery or instead of Celary if you can use RabbitMQ. If there’s something else that you can use to reduce stream, if there’s something else that you can do to propagate SMS. And trying to figure out what works and what doesn’t work. It’s now not more about individual strengths but the teams.
If someone else is working on a product that is completely different from any legacy code that you have, if one other member of your team is able to take over the legacy support and if their takeover is not affecting the general growth of the company. Because at the end of the day even if you’re a small team of 10 people, you’re still growing. You’re still in an early stage of startup obviously but you’re still growing. And you have to make sure that you’re growing. You should never have a zero-take growth or zero-growth day.
Now as far as choosing what tools you should be used for certain things especially if you have a choice, just go with whatever is the easiest without compromising the quality of your product. I have worked a lot in Python so I just go with Django or Flask anytime I have to do a backend thing. But if I have a team member who’s basically doing Node, he’s really good at it and I know for a fact that I am not able to do full-time coding because I now have other things that I have to worry about, like the meetings that I have attended and all of those things, I just feel like, ‘It’s fine. Just do Node. I’ll learn more. I know how to do Node and if I have questions, I’ll just ask you.’
And just building a product that is good enough, although not perfect but one that is usable and that you can actually expand on it, is a great thing. The other thing that no company should have at least at an early stage, in my opinion, is a massive infrastructure overload. No one really needs a Kubernetes cluster that you have to manage. Unless you’re like one guy who knows Kubernetes in and out, who knows how to pipeline everything, no one cares. Just open two servers up or whatever. Spin two instances, and use them. What’s the worst that’s going to happen? You’ll have to go into your console and increase the node size every time to replicate them, which I think most companies like Google allow it, Amazon allow it. You can just replicate them now. Just do it, who cares. Once you’ve reached a point at which you have five servers or four servers and now versioning is a massive pain, then think about Kubernetes. When you have 10 different services, five different services and you have to figure out- Okay, how do I actually deploy a new one without downtime? Then figure it out.
Generally, as a rule at an early-stage startup, we have to make a lot of sacrifices, especially in leadership. I sometimes stay up late at night. I’m in India right now and I’m working nights and I wake up early because I have to work out. But on the days I’m not working out, I’m checking the product and see if the dashboard is working. And I know this is terrible advice. No one really has to sacrifice their work-life balance. But sometimes you have to do tiny things like this once a month. When you have to upgrade something just do it when everyone else is sleeping or schedule it when everyone else is sleeping. And like if you wake up in the morning and you see that this is not working properly or this is not the product that you’re expecting, and people are getting errors, just roll back quickly and figure out what the error was.
Because again, you have DevOps teaching at any given point in time. Just use them. But you don’t need Kubernetes and I think that’s the one thing that people forget. While you’re building a very sophisticated infrastructure, the amount of time that you’re spending on it is the amount of time you could have actually spent on developing and building a new feature. Because it’s not going to be like zero hours spent, even if they claim it to be a zero-hour spend. You still need to write your YAML files and all of those things. You have to maintain them because everything changes like Eversoft. And even if you get a managed service, it’s not going to be free. So you’re now capital intensive so just do as minimal as you can to get the product out the door. Because if your product is successful you can just hire someone to do it for you. Just hire someone to get their instructions around just get a consultant. There are people who do that for you. They’re going to be significantly cheaper in the long run and it’s fine.
As far as when you go from an early-stage startup to a growth startup, a large amount of how to prevent massive upgrades is just making sure that you don’t have a significant technical debt, which you will have as an early-stage startup. So it’s always like a coin toss. You can’t really spend a lot of time optimizing every single code line like one of the bigger companies in this world would do. Because the amount of time you’re spending optimizing everything is the amount of time you’re not using. This means there will be some code that you’ve written that is going to be a trap.
The way I like to do things is to have four weeks of development or one cycle of development, which is two sprints. And then have one week in which you just do that cleaning. Just clean stuff that you’ve developed in the last four weeks. And maybe if you’re done early, just think about resting for a while. Don’t do anything. It’s fine if you’re losing out on one day of work effectively but your technical debt is very tiny, which means your documentation is apart. And that is more important when you go from an early stage to a growth stage.
Because the minute you’ve created a growth stage startup in which a day of you not being there or a day of you being off, because you have to upgrade everything, means you’re losing hundreds of thousands, if not millions of dollars. You can’t afford that. Because that’s one loss of a day or a week. You feel really bad and what you would rather just do than that is like make sure that your upgrades are happening async, that as you’re developing things, just develop a new code. Just have one person who is converting your legacy code into a new code or just ignore it. It’s fine to have a c code in your system.
I know that people who work in very big companies, people who work in those companies, some friends some not, who have code that was written when the company was created and they still use it. Because that’s the core engine that runs the whole thing. And that’s okay as long as you maintain it properly, as long as you make sure that the development, the versions are proper and nothing is dying. And if it does die, you have a backup. Then you’re fine. It’s okay to have terrible code in your system because chances are, you already have a lot of terrible code. Just build around it.
And when you have the chance, and when you have the ability, just make sure that the legacy code that you have is slowly becoming smaller. So that instead of it controlling 80 to 90 percent of your code base or the functions that you have in your code base, it now has 70 percent coverage. And the rest of it is taken care of by the new code that you’ve written. Then 10, then zero percent, and once you’re at zero percent, you now have a new engine, almost. Do it slowly and figure it out again. It doesn’t matter how big you are as a team. If you’re reaching a growth stage, there’s a significant amount of team base that is already created, unless you’re like Reddit. And I think 30 people, by the time they were a billion-dollar company. But unless you’re an outlier, you generally have enough people on the team that the tech stack is set. And even if there’s a new thing that is coming in, a new tech stack that is coming in, there will be enough opinions on the table that you can basically make a more proper choice about it.
Just listen to every one of your engineers who work in that tech stack and figure out why something is useful or not useful and then make a decision on it. The worst thing you have is half of your code written in PHP and half of your code written in Node. And now you have to basically always keep them separated and maintain. Sure if PHP is sort of dying or not getting enough maintenance, move everything to Node or whatever is the latest thing in the world.
As far as technologies are concerned and I’m sorry if this is slowly a long-winded answer here, but your market changes and so do the technologies that are associated with it. Less than a year ago, we had two major technologies coming. Generative AI is a massive thing now. CNN’s were a massive thing three years ago, four years ago. Then there was Gans in 2016 or 2017. AI is the king of the feast or whatever that’s called. And they’re always going to have to figure out if something is useful. The major thing that you always have to do, whenever it comes to any new technology, is figure out how can you use that. Or if you can use that to improve the experience, that your customer is having on your platform.
Just because something is useful or seems useful, doesn’t mean that your users are going to need it or you want it. For example, we have a CV, we don’t use a lot of AI. Use a little bit of it for the recommendation feature and all of those things. But we are not AI Centric, because our users don’t demand it. That being said, we’re working on a few things in the background which we think the users are going to find useful because it helps with discovery. It helps with user growth, it helps with figuring out how the customers are using a product, without them actually understanding.
Not every single Improvement has to be in your face. Some things can be subtle. I love the way Apple approaches things in the same light. They have a lot of machine learning that happens in the background. You don’t really realize it because they do things that are very smooth and very soft. Those just happen and you sort of get used to them.
A large number of new technologies that come out need to be improved or added to your product that way. Because if you build something that is in your face, you’re going to scare your customers. Because your things have just changed rapidly and they can’t recognize the product that they loved. Just give them a tiny iterative change. See how they are reacting to that, see if they’re using it. Just figure out if they’re not using it. Why not? Do they not see it or do they just don’t care? Once you have those answers, then slowly keep on integrating your technologies.
If you don’t include your new technologies, you die as a company. Because you are not innovative enough and someone else will take your place. But if you include newer technologies rapidly without testing, without figuring out if something works or does not work, you’ve died too. Now people are just scared of using your product. Because it’s changing every six months. Figuring out that balance is important even at an early stage, even at a growth stage, especially at the growth stage. Once you’ve figured out product-market fit because you have a core base of users, now you just need to make sure that you’re serving them.
Ratnadeep: These were all very-encompassing answers, basically. So thanks for that. For those listening who want to innovate and succeed in engineering leadership, what’s your advice? Reflecting on your journey, what’s something you have done or a decision you have made that made you feel proud of, and also, why?
Advait: The only two things that I would say is that just don’t be afraid of losing. You will fail and it’s okay to fail and it’s okay to just learn from your failures. As a leader, you’re not perfect. No one is. No person is perfect. You are going to have bad days, you’re going to have good days. All you have to make sure is that your team is growing, your company is growing and you are growing personally, which is the most important thing.
If I look back on how I was, let’s say, four years ago or five years ago, this is what I am today. I’m a completely different person. Not just in terms of personality and stuff. But the way I think about products and the way I think about businesses, the way I think about how to develop stuff, how to build a team, all of those things. Five years ago, I was a lot more rash. Because I was younger. Today I’m a bit more chill. Today I take a minute to think before I act.
The other thing that you have to do is be prepared to take risks. Half of your leadership journey is going to be you taking risks, making some big bets, and hoping that they are going to succeed and that’s okay. Obviously, there’s like a lot of caveats there. I was lucky that I have a support system that is built around me. So even if I’m feeling low, I have people around me who are like, ‘It’s fine, don’t worry about it.’ I have mates that I can go out with and have a beer with or I have friends that I can call at random hours and be like, ‘Hey I need to chat.’ Building that support system is important because sometimes it does feel like you’re the only person in the world, because there are things that are happening, that you can’t tell your team members. Because they’ll be scared. And it happens when you’re failing. Because the growth isn’t happening the way you want it.
And it’s okay to talk to your team members and be open and slack about it. Be vulnerable about it without giving them extra stress. Because they already have a lot of stress but it’s also unfair for you to have that extra stress. So join therapy, and exercise a lot. Just take care of yourself. That being said, in order for you to get into leadership, just be open to criticism. Be open to knowing that you’re not the best person in the world, not the smartest person in the room. And it’s okay to say ‘I don’t know. I learn what I need to learn and I’ll do it or I think I can do it. I’ll figure out how to do it but I don’t know at this moment. I have no idea how we are going to do this.’ It’s okay to say that. It’s okay to be vulnerable and open to the idea that maybe you just don’t know everything in the world because you don’t.
And it’s one of those things where you have to put yourself in that position or you have to be ready to put yourself in that position in which you’re at risk all the time, at which you believe probably everyone is going to laugh at you if you fail, or at least that’s what you think. No one really cares enough to laugh at anyone in this world. And that’s okay. It’s okay to just not be bothered by what the world is doing around you, as long as you’re true to what you believe in, as long as you are loyal or keen, as long as you’re treating them right.
It’s basically being a team person and a team player, just with the higher risk involved. Just be ready to take those risks. I honestly work a lot and I know it’s not an expectation, it’s not a requirement ever, but I’m constantly reading stuff that I don’t need to read, like papers academic papers that I haven’t worked on, in AI or in deep tech, in a long time. But I still read them because it’s always interesting to see what other companies are doing, what other researchers are doing, and to figure out what the industry trend is like.
And the second thing that you have to do as a leader is just learn how to network. You just need to learn how to sell. You just need to learn how to, because that is what is expected of you in a leadership position, that you can get team members to be championing your product, that you can get recruitment in. If you are in need or have a requirement, you know someone who can recruit or who is looking for a job or you can find someone who is looking for a job, and is going to be really good for your team.
You want to be sure that you can sell your product, that you know your product in and out, and that literally if someone wakes you up from the middle of your deepest sleep that you’ve ever had and asks you a question about your product, you know exactly what that product is. That’s all that leadership is for me. It’s just building a product in a more responsive way and I think emulating that slowly over the years helps you. Because it’s not something that you are just born with. You have to develop it as you go otherwise you’re never really growing in your career or professional aspirations.
Ratnadeep: Yes, I understand. To conclude what an enlightening conversation, where your insights into engineering leadership, your commitment to innovation, and your dedication to customer-centric have been truly inspiring on behalf of all our listeners at Leaders’ Perspective. Thank you for sharing your wisdom and experiences with those tuning in.
This episode has been a remarkable journey. Through the complexities of leading an engineering team, blending technology, empathy, data-driven decisions, and creativity, all those sorts of things that brought together an advanced approach offer a unique perspective on how to excel in today’s dynamic landscape. Thank you once again. And to our listeners be sure to join us for the next episode of Leaders Perspective. Until then, stay inspired and keep leading the way.
Don't forget to share the post!
Leader’s Perspective- a podcast to unearth insights from exceptional trailblazers who have been at the heart of defining strategies and execution of Digital Transformation initiatives in their careers. As organisations scurry to implement the Next Big AI initiative, the cognitive perspectives of our guests help you to find the winning mantra, or what might just save you from a pitfall. Let’s aim for collective wellbeing and implement successful data initiatives.
We’re committed to your privacy. We use the information you
provide only for notifications regarding our podcast.