‘Building your own tech vs. Leveraging third-party solutions’ with Mihai Valentin, Mentor, Tech lead, and Principal Engineer

Kovid Batra: Hi everyone. This is Kovid, Kovid with a K, your host for another show of Beyond the Code by Typo. And I’m today really excited to have Mihai on our show, who is a very humble, very renowned newsletter writer and author of the book, and really loves to give back to the community. He has had 15 years of software experience in leadership, leading tech teams. And he has worked with organizations like Facebook, Datadog, and whatnot. And right now, he’s a mentor, he’s a contractor with an MNC. Over to you, Mihai. Really happy and excited to have you on the show. 

Mihai Valentin: Hi, Kovid. Thanks for the introduction.

Thanks for hosting me on this podcast. I’m really happy to be here. And a big hello to all your viewers. 

Kovid Batra: Thanks a lot, Mihai. Thanks for taking out time for us. So, you have come to the show for the first time. I’ll quickly tell you about the format. So we are going to have a quick fireside chat. wherein we love to know about Mihai personally and other aspects other than work. So there will be quick two to three questions that we’re going to ask here, and then we will move to the main section where we will be understanding how to lead tech teams better, and then we’ll have that section for around four or five questions.

Is that cool? 

Mihai Valentin: Yeah, absolutely. Let’s get going. 

Kovid Batra: Great. Great. So Mihai the first question from the fireside? Which is your first tech gadget that you ever owned? 

Mihai Valentin: Oh, that’s a good question. So let’s go a bit back down the memory lane in my childhood. I got my first ZX 80 computer. It was one of those computers that didn’t have a screen So you’d need to connect it to your TV set and you would connect it to a cassette player as well because you would use audio cassettes to load and save programs or games. And whenever you would load stuff or save stuff, it would make this noise like kind of the dial up noises from the 2000s, but like 10 years earlier. So that was an amazing gadget because that’s how I learned to program at first. So the ZX80 had BASIC as a programming language. It was a very simple language comparing to what we had today, but nonetheless amazing for being able to learn as a first programming language.

Kovid Batra: Perfect. Perfect. That was unique actually. I haven’t spoken to someone who has had that gadget ever. Great. So your love for tech has been like from your childhood itself then, right? 

Mihai Valentin: Exactly. Like when I got this computer, I was spending most of my day in front of this computer. But I think it definitely paid off because that helped me learn programming and then that basically started my tech career. 

Kovid Batra: Great. Okay. All right. Moving on to the next one. What kind of a person you are, like, are you an early adopter of things? Or you really love to wait and see if things are proven and then you try your hands on that. What kind of mindset do you have? 

Mihai Valentin: So I’m always aware of what’s new. So in our industry, all the time there’s going to be a new technology, a new version of technology and so on. I’m trying to keep up as much as I can with what’s happening. However, when it comes to actual implementation, I’m a wait and see person. However, the way I think about technology Is I don’t look that much into the hype, right? Because if you look at every technology at their marketing page, you will see a lot of hype. And sometimes a lot of technologies are marketed as if they solve all the problems in the world. That’s not actually the case, right? Because in the end, they’re just here for solving a specific business problem. So this is more like a rule of thumb of how to judge a technology is what is possible now using this technology, but it was not possible before. So I’m trying to understand the reason behind this technology existing. And if this reason is clear enough, or if this reason gives me a definitive reason for adopting it right now, I will adopt it. But in most of the cases, I don’t adopt it right away. I wait and see and I go with something that’s fairly known. And this might also be the case because I’ve been working in large and very large companies. So, adopting new technology right off the bat can also pose a risk for stability, for governance, for security and for other things. But being aware, I think it’s super important because if you are aware, then you can, you can adopt, but if you are not aware, then you won’t be able to, to adopt it. 

Kovid Batra: Correct, correct! So I think it’s, it’s more like that you analyze and research at your own level. And if the problem, which the technology solves is pressing enough for you, you give it a early try. And if it is not, of course you are a late adopter for things. 

Mihai Valentin: Yeah. Yeah. Of course. Yeah. 

Kovid Batra: Love that mindset. Great, Mihai.

I’ll move on to the next question. This is a funny one. Which is your most used keyboard shortcut? 

Mihai Valentin: Hmm, okay. I would make a joke like maybe 10 or 15 years ago, it would be control+C, control+V for copying and paste code. But that is no longer the case. The most used key that I have today is command+shift+F. I find and search a lot. And the reason for that is in any tech organizations I work with, I don’t work on a specific project. I work across the whole business, so this requires me to have an end-to-end understanding of all the moving parts of all the services of how data flows and so on. So most of the times I find myself going from repository to repository from understanding how data gets from here to there, where is something used, how many times is it used, where is it used from, so that requires an extensive search. So I’m searching and reading a lot of code on a daily basis to understand how things are going.

Kovid Batra: Great. I thought when you said earlier, 15 years back, it was controls+C, control+V and now it’s not there. I thought you were going to say chat GPT or something like now I don’t code. I asked chat GPT. What’s the code? 

Mihai Valentin: No, chat GPT is super, super useful, but you need to give it a lot of context if you want for the answers to be really helpful, because if you don’t know what you’re asking, then yeah.

Kovid Batra: Great. And I think we’ll move to the last question of our fireside chat. Which is your favorite mantra that you live by? 

Mihai Valentin: Okay. So, my favorite mantra that I live by is a combination between life and career. And I would call it something like live your best life so you can do your best work. And the reason I live by this mantra and it’s always on the back of my mind is because I met so many people who unfortunately postpone living their best life until they get to retirement. And they are hoping for one day they say, like one day I’m going to live in that beautiful place. One day I’m going to do what I want to do. And the truth is that you can actually enjoy life while working eight or nine hours per day if you live in a place you love and if you have a role that you love and for some people, sometimes this seems hard to grasp because it seems complex, but all you need is a remote role. You need a Airbnb in a place you love, and then you just work during the day and then enjoy your evenings, enjoy your weekends. And if you do this for a couple of weeks in places you’ve always wanted to visit, this should be extremely beneficial for you. And you’ll see that the quality of life will increase and then also how you see work and how you see the future will definitely change.

So, yeah, live your best life so you can do your best work. 

Kovid Batra: No, I totally relate to this and it takes years for people to actually to arrive at this position. So, like Einstein used to say people know things, people understand things, but believing in them and living by them is something that really takes time. So, I’m really happy to hear that, that you believe in this, and I’m sure you’re living your life like this. Would love to give this thought to everyone in the world and not just dev teams but everyone because this is the crux of life according to me also. Great. Mihai. I think we’ll move on to the main section and main section is all about leading dev teams and today we’ll be specifically talking about your area of expertise, your area of interest, which is more around whether you should build or you should like buy, making a decision there so that you can reduce cost, improve the time to market, do all those things. And a lot of engineering leads, engineering managers, find it tough to make that call. But before we jump onto that area of expertise, I just wanted to understand a few things from you. You have been working with companies like Meta, Datadog, and you are currently working as a mentor and contractor with MNCs. There have been a lot of challenges which you would’ve faced while leading these teams, right? Can you just bring up certain experiences of yours, like one or two, which would be really helpful for other people to learn from you because every time you come across a challenge, you solve it. And when you look at it in retrospect, you have a good perspective on how actually that problem could have been solved. And in fact, in that situation, you would have done extraordinarily well. So any of those examples would really, really help our audience to understand how to actually lead teams like pros.

Mihai Valentin: Yeah, definitely. So one thing I’ve seen how it works and how it fails. Because if you want to understand, how to do something, you need to see it working, and you also need to see it failing. So only after you see both sides, you know, what would be the best way to do it. So one such thing is consistency. So for example, if you as a small company, let’s say of 20 to 50 engineers, if you build your tech organization in a consistent way, then you would be able to ship faster. You will not have to waste so much budget on operational tasks and so on. And what I say by consistency is using a single stack, for example. Unfortunately, there are so many companies that use, let’s say, react and javaScript for the front end, then they do some Python and maybe some go on the back end and then they make a microservice in rust and then they use some other language for some other microservice. And the truth is it can be exciting. Like it is exciting for engineers to build all these new services in all these technologies. But then when they need to manage when they need to be fast in them, they will not be able to do it because first, it’s very hard to move one engineer from a team to another to be able to help because they know different languages and different tech stacks. Second, there’s always going to be some corner cases or very weird bugs in each of the tech stacks. So if you have three or four tech stacks, you’re going to have three times more, weird bugs or situations that require debugging and lose time. And down the road, like immediately you won’t notice it. But down the road, it’s going to be so slow because you’re not working as a single team. You’re working as three or four or five different teams that are trying to solve a problem. So what I’ve seen works incredibly well is using a single tech stack, meaning here javascript or typescript depends of how you prefer. I personally prefer typescript and then use it for the back end. Use it for the front end and then also if you’re a company has a mobile app, use it for your mobile apps, and then you’d be able to build in an Android and build in an iOS. So it’s one technology that you need to know, one build system, one test system, one knowledge of corner cases, like understanding what are the subtleties of the language. Um, and once you do that, you can move your whole company with the same speed. Otherwise, you would every time need to go from one thing to another. And the speed at which you develop will not be the same. And one other thing that I love about this approach is that you can do a lot of code sharing. So if you have code that’s in multiple languages, it’s going to be very hard to reuse a part of functionality from the back end to the front end and vice versa. So for example, validation, right, you do validation on the front end, but you also need to do it on the back end for security, of course. So in case you don’t use the same language, you’d need to write the code once in JavaScript, and then once in Go or Python or Rust or whatever. But then if you have a single language, you write it once, And then you import it in front end and you import it in back end. And validation is not the only thing. It can be any sort of business logic that can help you. 

Kovid Batra: Great. this is interesting. Just a quick follow-up question on this. Most of the times, when you are in a situation, you have to take a call, you choose a stack and you start working on that, right? You’re saying that we should have a consistency here to have speed to not waste time on fixing bugs or catching corner cases for each of those stacks. So what do you think motivates the people to take the wrong step at the very initial stage itself? Like, can we inhibit that itself? Any thoughts on that? 

Mihai Valentin: Yeah. So I believe it all starts from the engineering maturity. So the more mature an engineer is, the more their focus will be towards solving problems and less towards a given technology. So it this is kind of normal, because at the early phases of their careers, engineers are super excited to learn, to grow, to see how various languages work, like to see, oh, how is Go working, how is rust going? And it’s totally fine. Like all these languages have their use cases, but unless you’re using them for their strength, for their specific use cases, like for example, for high concurrency, which could be Go or like for high performance, which could be rust, for example, or for Python, which is fast development and also a bit into this whole data science, machine learning and so on, unless you’re using them for the strength, then it might be better to actually use something like TypeScript, which is more like a general language that you can do a lot of things, even though you can do something like very specific, like I said earlier. And one way to prevent developers from going down this route of adding technology after technology in the team is to make sure you hire mature engineers and that you always talk to engineers about the fact that it’s the results that we ship that pays our salaries and the customers don’t care so much about whether you’re using this technology or the other one, but they care about results. And the fastest we can go to get to those results, the better for us, the better for the team and for our iteration speed.

Kovid Batra: Perfect. I think that really helps in understanding how we can actually avoid this problem. They should be mature engineers. mature leadership who is taking call on that stack at least. And of course, learning is one good aspect, which engineers should be enthusiastic about, but it should be put right. Not at the cost of company’s velocity. 

Mihai Valentin: Exactly, exactly! Yeah. 

Kovid Batra: Coming to this point of velocity getting impacted. This is a very important metric for every engineering team. How fast teams are moving, where are the blockers? So from your experience, as you said, that having a consistent tool stack solves this problem and of course impacts the velocity of the team positively. How in the initial phase itself, you are able to identify that, okay, teams are moving slow and this is the root cause. I just want to understand, like if this problem exists in a big team, how would you realize, let’s say you come from outside the system. And now you see teams are moving slow or what is that indicator that tells you, okay, this is the problem.

Mihai Valentin: Okay, that’s a very good question and I’ve been doing this many many times. So first I try to talk with engineers on the team. I try to grab them, have a coffee with them maybe, a very informal chat and trying to understand how they work, what they have achieved so far. And what they feel is currently blocking them. So this is the first thing to get the perception because sometimes perception is different than reality. But in order to make these two converge, I need to understand both point of views. So after talking to engineers and figuring out what’s slowing them down or how their process looks like, I spend a bit of time seeing how the normal development workflow takes place. And one place I clearly look at is a PRs and code review because in some companies, code review takes so much time to complete. And for example, for a very small PR, there is a lot of back and forth comments. And, while this is extremely useful for the code quality, if that company is growing and it’s very likely to rewrite that code in three months or so. Then it wouldn’t matter so much if people are going above and beyond to make a perfect code review for that PR. As I said, I’m trying to look at metrics, like how much does it take a PR to get landed? How many comments usually take, like how detailed are these comments? Do people want to solve all the existing problems or people are just looking for things that would, I don’t know, break or cause an issue in production if landed? then I also look at the pragmatism and the focus of engineers, like are the engineers talking about what to build? Or are they more talking about how they build it? Do they know the requirements? Do they know how their company makes money? Do they know what’s the biggest cost of their company? So this again comes into the maturity of engineers, because the more mature an engineer is, the more they understand that It’s the results that we ship that pays our salaries at the end of the month and not that the technology, the 100 comments on PRs and, and other things that really matter in this picture.

Kovid Batra: Great, Mihai. Thanks for this. We’ll move on to the next question, which is interesting to you, to me and I think for our audience also. It is about building versus leveraging existing technologies. And it’s a very hard call to take when you are on the go, you need to deliver fast, you need to take care of the technical debt and long term shots also. So how do you take that call in which situation it is good to build in which situation it is good to leverage an existing technology. Throw some light on that and give us some great examples like the previous one. I think people would be able to relate it better. 

Mihai Valentin: Yeah. Yeah. Okay. So whenever I have to take these decision and I’ve had to take the decision many, many times, I always look at two things.I look at the cost and the time to market, like these are the only variables that matter in this equation. Nothing else like things like feelings, things like emotions over a given technology. Okay, they might bring up some discussions, but they are not actually, real data. And, for this costs and time to market, there’s also another dimension, which a lot of the people don’t look into is the first order costs. And the second order cost. So, for example, the first order cost is I decide to build from scratch, and I know it’s going to take me three months, and I’m okay, this is the time. But if then it takes me two people, two engineers to maintain the solution every month, this can quickly add up to the cost. And this usually is a second order cost that people don’t see it. So it’s very rare that you can just build something, keep it in place, And require no maintenance, no bug fixes, no further developments and so on. So, that’s something I really look into. Then, I usually go for a building or using a third party integration in case, the available SAAS’s are extremely expensive or if they pose a vendor lock-in risk and there are no alternatives that would be easy to replace down the line. So for example, if there are two SAASs and they have similar APIs or similar ways of functioning, then I don’t see this as a vendor lock-in risk because you can go from one to another fairly easy. But if they’re not, then it’s a bit risky to have the whole business rely on a single SAAS.

And on top of that here, coming more from the development point of view, every SAAS I integrated with, I don’t integrate with it directly. I make an intermediary service, which is like a proxy, so to say, so that, the application communicates with that service using a very clearly defined protocol. And that service communicates to the SAAS through an API so that when I change the SAAS I don’t need to change my application. I just change the service in the middle to know how to work with a different SAAS. So in this way, if my SAAS is being used from, let’s say, 10 places throughout my code base and, requires some changes, then I just change in one place instead of changing in many other places.

So this is a very useful tip for development. Now I do also look into building or third party whenever what needs to be done is a strategic decision for the company. So for example, if a service is of strategic importance and we know that we’re going to use it for the next, I don’t know, 10 years or so, because it’s like Core business functionality, then it might make more sense to build it because then you can build exactly the features that you want to have rather than try to adapt a SAAS, which is not going to have all the features you might want. And it’s also going to be difficult to negotiate with a SAAS company to add various features that you might need because they need to serve hundreds or thousands of clients and not just you.

Kovid Batra: That makes a lot of sense. Great. I think, moving on to the next question, which is about moving fast. So moving fast is very crucial in this tech world and it also sometimes lead to technical debt, right? So what’s your approach towards maintaining this momentum and managing the technical debt alongside that? How do you usually take a call on that? 

Mihai Valentin: Oh, that’s a good question. So technical debt, all these things are always correlated with the maturity of engineers. So I see technical debt as good technical debt and bad technical debt.

So it’s like in finance, you can get a mortgage to buy a house, which is a responsible thing to do. But if you get the mortgage for consumer, which is of a higher rate, that’s not ideal to do. And by splitting this technical debt into two things, like good technical debt and bad technical debt. I see the good technical debt as a way to move faster for shorter amounts of time. And for example, If you’re applying this rule for a small company and, you need to release things very fast, then that code will definitely be refactor or rewritten completely in a few weeks or in a few months as you grow. So then you need to move there as fast as you can. Even if you add a bit of technical debt because at the end you just delete the code and rewrite it again for the next phase of growth, because usually as you grow in terms of scale, let’s say 10 X to 1000 X, it’s not going to be the same code. Because it’s not going to be the same scale because things change and it’s natural to change. So if you spend so much time crafting this code in a perfect way, then you spend a lot of time and then you just deleted that entirely. The debt will simply disappear when you rewrite the code. And then I keep mentioning this, but the more senior the engineers, the less technical debt will produce because what is the technical debt is a way to cut corners to achieve something fast and good, but if you are a senior engineer, you will not do a horrible hack. You will just do something that helps you move forward with a little expense. And if you understand what can break there? What are the limitations of what you did? Then that’s absolutely fine. So it’s okay to create technical debt, as long as you know what you are doing. You know how things are fail, you are okay with them failing at some point and you have a process in place to mitigate or to fix it. I noticed that also a lot of technical depth gets created when Teams and engineers aren’t able to take decisions. So, for example, let’s say an engineer works at a feature and the communication in the team is not perfect. And then the one engineer needs to take a decision. And if that decision is not the right one, that can create technical debt. However, if the whole team works together and is able to take very quick decisions on a certain topic, then technical debt is less likely to happen. Why? Because, think about it, you need to implement a given feature, and if you are able to let’s say, write on Slack, make a poll, say, here’s our context, here’s our problem, here are the three solutions I propose for fixing this. Hey folks, please vote until, let’s say 3 PM. So you give people time to choose and if they haven’t choose, you go with whatever choice you prefer. And then if the culture in your team is to tackle these things immediately, to vote, to express opinions and so on, it’s very less likely to end up in a situation where you create technical debt. So taking quick decisions together as a team reduce technical debt. 

Kovid Batra: Makes sense. I’ll not take much time on this, but just because I found it very interesting. Let’s say I’m a junior developer and I’m working on a problem. I am sure to make certain mistakes, which could be from the scale of horrible to be okay with them. With every junior developer in the team, how will you ensure that whether they’re writing the code piece right or not? Of course, code reviews are one good way of going about it. But when you say that teams should be looking at it together, and these are the solutions which would propose to avoid such technical debt. What should be done for the junior developers who are working, how their code should be reviewed, how they should be looked into so that they don’t create that problem. 

Mihai Valentin: Okay, that’s a very good question. So I think, you need to treat juniors, not as juniors, but as people who will at some point be mid level developers, senior engineers, and even higher. And why I’m saying this is that instead of just giving a task with very brief specification, you would need to give a bit of context. Why are we doing something? How did we solve this in the past? So help juniors to make the right choice. Don’t leave juniors isolated. Don’t leave juniors without, let’s say a mentor or without a buddy. Keep juniors in the loop with the whole team. Of course, as you said, code review is a very important step because when the juniors will put up a PR, everyone will come to review. And also here’s a very important thing, not to do critical review. So don’t say this is bad, this is wrong. Because you will demotivate the person. And, if you do this, you’re lacking self-awareness that you’ve been in their shoes at some point, not long ago, most of the time. Exactly. But then help them and try to feel them welcome to ask questions because if they are not feeling welcome to ask questions, they will not ask questions and they will be afraid of doing this, and maybe they will take some decisions which can hurt the team. So, the most important thing here is to acknowledge that juniors are juniors. Juniors need help for development, for learning. And it’s your responsibility as a team or as a senior engineer to make sure that they are growing a bit. Because the seniors today will be the senior software engineers of tomorrow. So, there no other way it’s going to happen anyway, but at least make it happen in a way that everyone benefits from it. The junior engineer, the company, the team, everyone. 

Kovid Batra: Yeah. I think this is a good way to go about it.

We should just always keep the junior developers also in the loop in terms of the context, in terms of taking decisions. And of course, reviewing is one good way of going about it, but assigning a buddy or a mentor would really, really help. Great. Mihai great thoughts. I know you are leading the best team. And people in your team would be happy. So I think, the last thing that I just want to know, the name of your newsletter- “How did I get here?” So what’s the reason for putting out this name? It’s a very interesting one. I have recently subscribed to it and I’m loving reading it. So what do you have to say about it? 

Mihai Valentin: Thank you. Thank you. I started writing on LinkedIn for the past one year and a half, I guess. And initially I started writing like once per week and then I ramped up to write many times per week. And as I wrote, as my audience grew, people came to me, messaged me and told me, Wow, Mihai, you have such a, such an impressive profile and CV. And I’m like, No I mean, everyone that puts in the work, everyone that takes the right steps, everyone that’s open-minded and wants to get things done, will be able to, to get in these companies to get this experience. And so on. It just takes the work. So then I thought, what if I instead of just talking about what I know, I’m talking about, how did I come to know the things that I know and how my mindset go to be the mindset that I have today? So then I thought, it doesn’t make much sense if I just throw things like out from a position of someone who has a lot of years of experience, but then show what were the steps, like what were some key moments of my career in which I learned something that has made me challenge my assumptions and drove me further up the growth slope. So I called it, how did I get here? Because I’m interested in sharing not only what I know now, but also what were the steps that I took to, to get here and not only the steps, right? Because the steps are fairly easy, right? Like you interview, you get into Facebook, then you interview, get into another company, and so on. But no, What was the toughest thing when interviewing? How did I view interviewing before or after? What was my biggest fear? How did I overcome it? Who did I learn from? What did I read? So all these things that create a context around what happened rather than just saying it happened. Right?

Kovid Batra: Makes sense. Interesting. That brings us to the end of the show. It was a really nice talk and would love to have you again. 

Mihai Valentin: Likewise. Kovid. I really enjoyed talking to you and looking forward to talk to you again.