Podchaser Logo
Home
049 How should dev teams deal with product pivots?

049 How should dev teams deal with product pivots?

Released Thursday, 24th March 2022
Good episode? Give it some love!
049 How should dev teams deal with product pivots?

049 How should dev teams deal with product pivots?

049 How should dev teams deal with product pivots?

049 How should dev teams deal with product pivots?

Thursday, 24th March 2022
Good episode? Give it some love!
Rate Episode

Episode Transcript

Transcripts are displayed as originally observed. Some content, including advertisements may have changed.

Use Ctrl + F to search

0:00

Founder Vision 49 - Izicap[00:00:00] Tancho Markovik: What founders need to be clear with is what do I want to achieve? If you pursuing the first shipment of your product, then by all means you need engineers. You don't need a manager, a high-level manager that will point fingers and say, do this, do that. You need yourself building that idea with a few other people around you.Wuick and dirty, taking shortcuts, regardless. You're sprinting to the finish line, which is version one in production. It will. It'll burn. You'll fix it. That's fine. You need to prove to your seed investors or angel investors that you have something which you can ship. But once you've passed this point, when you're going to raise a more serious round, like if you're going towards round eight, you've exported, you've exceeded the seed money.You're going to round A or even the round B even more, let's say more serious. You definitely need a CTO.[00:01:04] Brian Gupton: Hello, and welcome to the latest edition of clear views, founder vision podcast, where we speak with founders and startup leaders about their journey. Today, we're joined by Tancho Markovik, who is the CTO of Izzy cap? How are you today? Tancho? [00:01:22] Tancho Markovik: Hi, first of all, thank you for having me. I'm doing good. I'm a little bit under the weather today.Last week was, I got a cold, so I'm sorry in advance. I know it's all right. [00:01:36] Brian Gupton: Well, tell us a little bit about what is the cap [00:01:37] Tancho Markovik: does. Yeah, sure. So the company was founded about two more than five years ago. It was a company that was bootstrapped for the first couple of years. And then after a while you discovered that you needed money to grow.So it raised round A. This was just before COVID what the company does is kind of interesting. I think I'm going to give you a use case, which everybody should relate to, you know, how you go to stores and they offer you, a membership card that has this barcode. Did you have to remember to have on you or do you have an app that will scan the barcode and keep it in your phone?We do that without the barcode. It sounds stupid from let's say, when you explain it this way, Small merchants do not have the capability to put the infrastructure software management style to remember, to give you the barcode scanner, to remember to scan the barcode scanner every time you're there, the user flow should be simple.In a sense, you go to the store, you buy yourself and you leave and you get the benefits you would get through the barcode by just using your credit card. So in a way, when you just pay with your credit card, we have already done the necessary shenanigans with regards to the barcode membership, but that's the transaction to your account.The other, you just get the rewards. The merchant has a simpler experience where they pay us the subscription fee monthly. And they completely removed the hassle or the whole user case where they need to give you a car and they need to remember this can the card, like you can just forget about all of that, just do your thing.And everybody wins. [00:03:05] Brian Gupton: Okay. Yeah. I'm old enough to remember having to carry in an, an actual like card that merchants would, would punch to get a free sandwich or something. Right. So this is interesting. This is like a, a loyalty platform for local brick and mortar merchants. And it's tied into whatever card you're you you're using.So you pay and then what it, it tracks your benefits just based on the. [00:03:30] Tancho Markovik: Let's say in a more engineering, specific approach, I'm going to try to give you the same use case you purchase on a post, a payment terminal, which your card, your card gets tokenized. Our system tries to see if it knows that token or not.If it doesn't, you're not a member. If it does, you are a member. If you are a member transactions attributed to the account, if you're not a member. A popup shows up on the table and says, do you want to become a loyalty member of this shop? If you opt in, you become, if you don't, nothing happens when you are a member, these transactions atomic, once even they will be attributed to your account as life goes on.And for example, the store said at, I don't know, 10, a hundred euros, a hundred euros, you get 10% off on the next person. Next time you come in, you have a voucher which you can redeem with a, with the shop and you get the eat asks, be it let's say incentivize people to come back to the shop, which is why it's very interesting to the merchants.It also gives the merchants, the capability. Reach out to their audience, to the people who are the loyalty [00:04:35] Brian Gupton: members. Oh, very cool. So I guess just one more question on that. I'm sort of assuming that like, if somebody comes in and they, they use a different card than what they had used, when they originally signed up, they'll get that prompt because you don't recognize that that's a card linked to a loyalty member and then that additional card it does that get linked back to their, or the original.[00:05:00] Tancho Markovik: Exactly. So there's two ways. When you get the new account, you can be proactive as a member and you can go to our portal and add your account. So basically you insert it into a browser. It gets tokenized on the spot. So the token for the card is stored in the server. So we can recognize your credit cause we can transmit the actual card itself.And if you're not proactive, which is fine. Cause like I personally am not, I don't want to care about anything. My car through the 50 shops, which I'm a member of. I show up there, I do my purchase. I get the opt-in prompt because it's a new card. The system doesn't know me. I punch in my number, the system then attributes that token is a new car to my council.There's just this one step, which is intermediate when shopper with a new account. Interesting. [00:05:43] Brian Gupton: So I live in south American in Columbia currently. And, it's interesting here that local commerce is like really dominated by like WhatsApp, as far as like communication platforms. What is that? Is WhatsApp huge in Europe as well, or [00:05:59] Tancho Markovik: what's up is huge.So it depends years, a big, big place. And because Europe has multiple countries which have multiple. I'd say characters. It depends on location by location basis. If you go to Europe to Eastern Europe. There's an app called Viber, which is more popular. I think it's in the south of America as well. If you go to Spain and Portugal, communication for businesses is more popular on WhatsApp, but in France, SMS is king for some reason.So we today support, email and SMS because we were primarily in. We are about to launch to commercial markets, which are allowing us to get out of France and go on to, on to European soil. And one of the things that we discussed was a what's up for business or exactly what you're talking about. It's actually quite nice because it's a much cheaper, it's less restrictive with SMS.You know, let's say France has these accented characters. You made an accent, which is pronounced like you would in English, that takes two characters. So then you need to educate merchants that the message which they typed, which is 160 characters, actually 120 could use an accent. You know, WhatsApp is more permissive in this regard.So it's on our plan. It's on the roadmap because we're about to launch outside of France in France, people perceive what's a messages is to integrate. So we don't want businesses to go. [00:07:19] Brian Gupton: Isn't that interesting? How, depending on how a platform gets started in a, in a country, it really kind of changes, you know, the character of, of how that platform gets used regionally.It's crazy how much like payments and, and, you know, local merchants are changing right now. It's like a real revolution and you know how we do business with these. [00:07:43] Tancho Markovik: Even payments, like, come to think about it in, if you think globally, you're thinking, let's say payment industry, right? You're thinking MasterCard, visa and Amex, right.That's kind of 90% of the world in anybody's head. If you don't put them in. If I put you in context, context, being restaurants in France payment industry changes because you don't, you no longer pay with visa or MasterCard, you pay via a national payment processor, which supports visa and MasterCard, but support something calledSo restaurant tickets, meal vouchers, where like this is the friend it's not just France. There's like in France, in France, in Italy, in Portugal, in Spain, I think as well. They have this concept of a low lunge vultures, where you get the physical card that looks like it might even be stamped by visa, but it's not real money per se.Right. It's a different payment obligation. So like the world's an amazing place. Like you can go from here. 50 kilometers to the south is the way that you would enter Italy, different rules apply and based in the south of France in nice. So from, from where I am right now, What let's say certain miles, right?You get in a different country where different rules apply in not only the language is different, but the way people interact with their phones, the way people expect to be communicated with businesses is completely different. Right. [00:09:05] Brian Gupton: And of course, that creates a barrier. If you're trying to, if they're a company is trying to do what you do in France, but they've, they're coming from like the U S mentality of how shopping gets done.There's so many nuances to learn. It kind of creates a little bit of a Mo for the, for those businesses. [00:09:24] Tancho Markovik: As you said, like in, in the south of America, WhatsApp is quite popular, right? So you would be expecting a communication from a business to go there, but if you're, if a French person receives a message on WhatsApp, they will be like, why are they even pinging me on WhatsApp?That's where I like chat with my mom. You know, I [00:09:42] Brian Gupton: don't want you here. When I was living in the U S. Nobody used WhatsApp. I'm sure that has changed, you know, but it was when I first arrived in, like everything was, was WhatsApp. It was like a big surprise because I knew that that product existed, you know, because Facebook had acquired it and I knew it was, you know, big in other markets, but I really had no idea it was as big as it was because of the U S at that time, it was not big at all.Well, interesting. So now you're the CTO for it for Izzy cap, like tell us a little bit about your background. Like, how did you get, you know, what what's been your career progression? What are some of the interesting places you've worked in projects you've worked on that you can share with. Sure. [00:10:24] Tancho Markovik: So about, about 10 years ago, I moved to France and I moved to work in a university, which sounded interesting.Like France was a challenge from a perspective of, I didn't know the language, they know the culture, then they knew nothing about it. And that was like one of the good reasons to choose the country to go to. Right. so my, my vocabulary in French at the time was born. That was about it. Anything you reply?I couldn't tell you how many words you just said. Like my, my level of French was to the point where I could repeat what French people would say to me. I just could not go there. we, in the work that I'm in a university, I was kind of the liaison between companies and, and in the school I could understand had enough academic knowledge to understand what the PhD is.They had a lot of experience, which would tell me what the companies are expecting from them as a delivery. this was in the south of France, which was like 50 kilometers away from Paris are quite difficult to navigate. Like it was not the life I expected to have. So five months in, I decided to quit and kind of my journey starts.So I joined the company called Ashlyn, which is a password manager. I was employee number like 110. I can't remember exactly how many we were in the office, but quite few, you know, the kind of a startup where you're in an apartment where the. The, the bedroom of the apartments, the meeting room, the walls are feeling that's where w that's [00:11:44] Brian Gupton: where we were.Oh, it's funny. I knew the founders that had dash lane, like pretty early on, not like super well or anything, but I had met with them when they were like a company of like nine people. I think. [00:11:55] Tancho Markovik: So probably I was probably there when you spoke to them, because like, time-wise. If it was a single digit number, it was probably about to join a join.Oh, wow. And so you name it because it was there for five years. I went from a single engineer on mobile to leading the team. We managed to do amazing things there. Like it's very nice when you have the capability to write the first line of. For a platform and then see the a hundred thousand user on the platform.So we went from shipping version one, seeing it crash a million times, trying to fix et cetera. You know, like the, the, the deal fund story, which happened there. We had like this, they had the capability, the, the chance to work with. A Googler from, she was Scottish based in California. So the weirdest mix of accidents, you can find, we managed to find the common language.So we were thinking of, I was abusing the accessibility as the cake and Andrea Google was up to happy. So one of the people which worked in the authentication team reached out and the deal was like, can we provide you with a different. Because there was no other options that they could, they could use to do what they needed to do, which is detective form on the screen.One, three short, we worked on this open source project for about a year and the project was an API which got shipped in Google play services. So I was like super happy at this point in time, because something I wrote was shipped on all the Android devices in the world. But even though it was like one, like there was a lot of contributors.I was one of the founding ones with them, but what we wrote shipped and all the devices in the war. that's like an amazing thing for five years, then I decided to do a career kind of company shift. So I started looking in the market and the head of it was looking for companies, which would give me the concept of the possibility to grow.Right. I was working in industry and it was quite in a very nice place there, but I'm not known to be comfortable in the comfort zone. I wanted to re to leave the comfort zone. So I joined a company called content square. It was a company of a hundred people, the diamond. But still extremely like it's a, just the after round day.So still very early on still the company was a couple of, couple of years old and then the deal was I wanted to take over more than mobile. So we kind of set up a deal where. There was some targets you needed to hit. And the problem that the company had was like, you, didn't what the country square does is they inject.And as they came into your app, you inject this decay. You do no changes in code the app. The intercepts all the events of the finger towards the screen and tries to understand what you're doing. So to the person delivering the app. So imagine you are using, I'm giving me an app. You're let's say you're using WhatsApp, right?If the music is injected in. And build them. Of course, I would be able to see the whole use cases to how you use WhatsApp. I can see which menus are you triggering, how much time you're spending on your screen. Think of Google analytics without adding the tags. The fun part was they did this for the web, but not for mobile.And mobile was the primary source of traffic for net for the internet, like for people of the use e-commerce, which were the primary target that content square was trying to hit. So we managed to, I managed to hire a team. Like I was the first engineer there on mobile. I managed to hire a team and I.Figuring out problems in the overall platform where the way it was built, it couldn't digest mobile traffic because of the nature of mobile. What I mean by that is like, when you're browsing the internet, you have, an active network connection. So it ended up that you send the server receives because you're actively browsing on mobile.You could be in the, in a train doing something they need to store the events, partially send them resend afterwards, you know, this whole. The system couldn't digest. So we started changing attributed with the team and this team was working with me. So it was part mobile for the vacant per data. So we started building a parallel system, long story short in about 12 months, we managed to sign the first contract with remote, which was mobile exclusive in the company.So quite a nice win. And then I got an offer from a company called symphony similar communications. Based out of California to join the team, moved to the south of France, which was quite interesting for me, like the south of France park. We didn't know much about the company because it was in the banking industry.So I couldn't use it as a, as an end user, but the deal was, they offer the title, which was director of engineering, which I had no idea what he meant. So it kind of pulls me out of the comfort zone. So the deal's like, why not? Let's go with it. I did interviews. And I said to them, like, I don't know what the title is.I would like through the interviews for you to convince me I'm a good match, which, I mean, they convinced me I was a good match because they said, so I still understand it. And they joined this company, which in France had like four people. The company was quite big when joined like post round CA I think at the time, but the French location with like six or seven people when I joined, that was one of the more senior managers I think were two at the time that that's focused on the growth.One of the things that we needed to do was a. Grow our respective teams and migrating from one location to another. Cause my teams were dispersed between Vietnam Brazil. Stockholm. Nice ahead. A few, a guy in Macau as well. So all over the globe, they need to centralize more within France, but on the site itself to grow.So we managed to grow for within like 15, 18 months. We grew from six to 135 people. And like this kind of a growth you need to really sit down and plan. It's not just doing interviews like hiring 130 people. Probably 600 candidates to screen or more if you're, if you're lucky, it's [00:17:26] Brian Gupton: definitely a full-time job at that [00:17:27] Tancho Markovik: point.Oh yeah. So they're within the time I spent with symphony, I didn't understand director, but they got promoted to a senior director along the way. So that was fun. And then after like two something years there I go to ping from, an executive search company. That's offered this job, which was. CTO in a company of the size of a company used to work in the past.So kind of the size was a conveniently say and known. So I decided to accept the job and here I am. So I'm [00:17:55] Brian Gupton: curious for companies out there that they've got a little bit of traction and maybe they're looking to hire a CTO or, well, first, like what is the decision-making process that a founders should go through?When deciding does my next hire need to be a CTO or more individual contributors. And at that early stage, like what are some of the characteristics of, you know, an engineering leader that founders should be looking at? This [00:18:26] Tancho Markovik: is Bernie like the million dollar question, right? When do you hire a CTO and what kind?I don't think there's one answer what you need to be very clear. I mean, what the F let's say, what founders need to be clear with is what do I want to achieve? If you pursuing the shipment, the first shipment of your. Then by all means you need engineers. You don't need a manager, a high level manager that will point fingers and say, do this, do that.You need yourself building that idea with a few other people around you can. We can. They're the taking shortcuts, regardless. You're sprinting to the finish line, which is version one in production. It will crash. It'll burn. You'll fix it. That's fine. You need to prove to your seed investors or angel investors that you have something that you can.But once you've passed this point, when you're going to raise a more serious round, like you, if you're going towards round eight, you've exported, you exceeded the seed money. You're going to round the eight or even round me even more. Let's say more serious. You definitely need a CTO. What kind? That's the other question?Other parts of the question. You need to know your team. You need to know whether the team is experienced enough and they need a good manager to make sure that they have the right in the right moment. You stop to think you set up the architecture so that it can scale. It can grow, or maybe you have a team which is not as experienced.And then you want to hire a CTO, which is more hands-on that will push the younger engineers to make the right. So you really need to look at it in a case, on a case by case basis. But when it comes to companies which are before around me, I would definitely suggest to find the CTO, which is. Energetic and hands-on, if you've done what they proposed, let's say with a seed round, which is you've cut corners to make sure that you ship when it comes to round day, especially around me.If visitors are going to start asking for specific things, I can even give you a few questions, which I have from technical due diligence is from partnerships or from investment rules rounds with like they're generally [00:20:23] Brian Gupton: the same. Yeah. What are some of those questions? I'm curious. [00:20:26] Tancho Markovik: So where does your system break?If you have a hundred times more. Right. And usually when it comes to a scaling issue, like there's a single point of failure, depending on which area of the system we're looking at. So the other thing, like let's say, I'm going to try to shoot a few questions that come directly to my head. What's your cost to serve and the cost of service comprised of two parts.It's comprised of the infrastructure costs. But it's also comprised of the human cost. You have some companies build their systems around human interaction. So for example, you have support. And in order for people to continue using the service, they might need support. For example, approximately 0.5, support requests per person per month.That means that you need to have a support team dedicated to this. So in order to scale, you'll have to scale the human factor as well. If you start looking for investor indicators, You're probably gonna find a ton of, short abbreviations, like three liters, which will be very insightful numbers that will pinpoint the financial stability of your company or your product.Not going to focus on those because you can probably find them in a medium post. Like, if I send the re so here's another one. If I send a bogus request with a fake password, how deep does it enter your. So try it. You have a forum. We imagine the Facebook forum, right? You try to log in with your username and your password and you know, the password is wrong.So we need to type in a string, which is hello world. How deep in the system does it go? Does it fail in the beginning? Because there's some way to authenticate the password or do you go all the way to the user's database where the password hashes, hopefully not the password. The hashes of the buzzwords, the story, and to think about these kinds of things, you might need to be compliant.For example, we're working with credit card information, so we are PCI DSS compliant. So that specifically means something. So if you're working in the sector where securities is. You need to know which aspect of security my previous company was ISO 27 0 0 1 and SOC two certified different security rules applied.And this, you cannot get through just the random senior engineer. You can find that will be really good at building a product, but not good at selling your business to an investor. So let's say around eight and above, you need somebody that will have these kinds of experiences, that will be able to point you to the problems you have ahead of time.Because when you get to the investors and you start asking for them, You might get to a point where they'll see the future of the product, but they'll give you a lower valuation in a high investment. So imagine you get validated at 50 million and they give you 20 million. They just purchased it 40% of the company.But if you get 20 million for 200 million valuation, they just purchased 10% of the company. So. Good thing is small investment, big valuation because they get the smaller piece, right. And to do this, to have this proper balance of things, you need to be sure that the person that you have technically next to you is the person that knows these things ahead of time.They've been, they've been in the game, they've been asked for the difficult questions and they can ask them to the team and make the appropriate changes ahead of time. [00:23:26] Brian Gupton: And how involved would, would you, or, or a CTO be in that kind of due diligence? Is that a lot of due diligence with the CTO at series a or not until series B?[00:23:38] Tancho Markovik: I wasn't here at series Z. I joined just out during the, a little bit after I did due diligence for a few strategic commercial partnerships that we, that we have. So we were part of MasterCard's, start their path where MasterCard's helping us reach out to partner banks that they work with to establish a commercial, commercial relationship.So we had to go through the technical due diligence of MasterCard itself, and then we had to go through the technical due diligence of every partner. So I meet in the VP of customer. working hand-in-hand to deliver these. I'd say usually the way that we split the work is if it's legal, the customer, the VP of customer success takes over.If it's purely technical, I take over. So when it says, what's your SLA for uptime, what's your response? Time to production level one incidents, or what is the encryption mechanism you use to encrypt your data? That's usually it usually comes to me. And then when it says, like, let's see if it comes to legal aspects of things where it's contractual, that's the VP of customer service.So I would say pretty much involved, like very heavily involved. Okay. Think about it this way. If you're a technology company, what you do is you write lines of code for which you ask for money for people to use. That's your digital loss. And that's what you do. If you're a. You sell your skill of building chairs.If you're an engineer, you sell your skill of writing code. You ask people to pay you money to use your code. When somebody is else needs to invest into that code, they need to either see. For us difficult questions like these that you have to ask her, which will give them the confidence to give you money.[00:25:13] Brian Gupton: So talk to me about how you approach interviewing and hiring developers and how that approach changes when you're, you know, just hiring one or two at a time, versus when you're trying to scale up the team much more quickly. Yeah. Mass [00:25:32] Tancho Markovik: hiring. So mass hiring, I did them a previous. which I mentioned, like we hired like 130 plus engineers and I'm doing the T cherry picking in this company because we're not hiring that many, but we really trying to find good skilled engineers.I try to. So like in coding, even in hiring, you have kind of three of the triplets of, of success yet you can either focus. Quality score per time and you need to sacrifice something. So in terms of hiring, you have speed hiring, you can have genius engineers, or you can have good team players. So if you're careful, you're going to usually try to sacrifice time and try to find people who are good engineers and good team players.And the cost of hiring them with elongated period of time, like looking for them very, very, for a longer period of time, when you do mass hiring, you need to, you cannot do it yourself. The 130 plus people, which I mean, I just helped design the process. I didn't hire all of them, myself. I built a team around me with people who helped me, who actually did the interviews for most of the people.I was one of the interviews of the group, but they, I worked on building a group of people. I personally work well in the team and they prefer working in a team than working by myself. So mass hiring, you need a group of people that will dedicate a percentage of time on interviews. You can schedule it.You can make sure that this li like enough time attributed, et cetera. But at the end of the day, this takes time hiring in the U S is a little bit different than hiring in France. in France, we have the French labor law, which really protects people. So once you hire, it's like a marriage, it's very difficult to.So you could be less careful in, in the U S because of the, let's say ease of leaders, letting somebody else go in France. It's not that easy. So we're even more careful to make sure that when people join, they don't leave on the, unless they leave on their own. So the actual process itself, I try to think in the following way, I want to see code.I want to speak to. And then one of those, see how you think. And that's my guideline. There's an HR call. So they speak to you. Then there's a phone screen by the hiring manager. If I'm the hiring manager, I'm going to try to book the 30 minute call. And in that 30 minute call, I'm going to try to understand who you are and how smart you are.And that's super new. But also how honest you are. So these are like super difficult things to do in a short period of time, especially 30 minutes. So trying to, let's say my phone screen, that James was split into five minutes of sending the company and introducing myself, right. Who we are, because I am assuming we reached out to you and you don't know much about us because most of the time I've been working in B2B company.So you're not exposed to us as a, as a product, right. Even better if you are, cause then you don't have to sell, the person will know the product. Then I tried to go through. Asking what you do. And I try to ask you questions about the projects you work on. If it's projects you work on, you're probably more expert at them than I am.You should be able as an engineer. You go deeper into, within not going to explain technical topics with ease, should be able to fully understand the, the, the problem you're describing. And I will ask you questions out of interest for what you're explaining, but they focus on one problem. So let's imagine, let's say I worked on a, in a company that built a communication suit that would focus on which technology do you use to actually exchange.How do you deal with wag on runtime real-time communication? What do you do when it comes to, reaching out to a person who is in a train while on the call, how do you deal with lag, et cetera? I will try to pick those difficult topics and try to see how much you are able to explain. Even if you didn't work on them, I need to see your understanding of things.And then I try to dig into a subject where you, when you say, I don't know, this is something which is super important. For example, I would, if you're a Java engineer, I would try to ping you about something in native code in C plus plus or whatnot. I don't want you to, like, I'm trying to find a subject for which you're sitting.You're going to honestly say, oh, I don't know how this works. If you're capable to take, say, I don't know, during an interview, you're definitely going to say that in the actual day-to-day work, right. I want to have people that will not bullshit me. I want to have people that's below. Invent things or the Finnair.Right. I want to have people who are down to the ground and they're honest about what works and what does it, so these are kind of the, let's say the tips and tricks tricks. I build, an opinion based on how the person. Describes technical topics, how much they synthesize them into a simple answer. I don't want to have somebody that will come up, kind of go down the rabbit hole.Then I have like three stages, which are kind of standard, which is, I either ask for code, which the person wrote, which is open source or a mini project that they did for anyone which we evaluated, or we give them a project. And then this is kind of a mini homework. And then we have a behavioral interview, whiteboard interview and a project.Project being the code you shipped to us, a whiteboard is a problem solution kind of approach. We focus on solving a problem together, right? So there's a ton of websites where you can see problems. You can go to YouTube and see videos of actual whiteboard topics. And we'll go focus on that too much. The only thing I would say is in Europe, whiteboard interviews are not that popular.They are very much in the U S but not. So we tried to modify the approach where I'm not looking for a genius that will create compilable code on the whiteboard and looking for a person with whom I can have a deep conversation about a problem using the standard tool that we work on. The day-to-day. I need to know that, you know what the center is, where the hash, my prayers and how they work and the details on it.[00:31:11] Brian Gupton: It is the whiteboard exercise is that, is that generally to kind of weed out the people that actually know how to write the code versus the ones that just know how to go find, you know, how to Google, how to [00:31:26] Tancho Markovik: actually. So this is, I think this is the purpose behind whiteboard interviews. I try to screw that into a different.For me, the whiteboard is we look at the problem together and I don't want you to code that much I'll code for you. That's fine. I can write the code. I want you to tell me which code to write. I want to figure out how you think, because every time you're going to solve the problem, I'm going to throw a wrench in your feet by changing it a little bit so that this code doesn't work anymore.I want to see. For the actual writing of the code, we can even do it. Like I have problems, which I do with candidates where we cannot do video. So we talk over the problem and I have problems which we can discuss. So there's no code, but the idea is just to see how you think I want to attack a problem, which is unknown to you, which takes you out to the company.And I want to see how you try to this assault, this assemble the problem. It's not about the code that you export. It's fine. If it doesn't compile, if it's fine, if you don't even write it, I want to see how you think out loud here, how you think about [00:32:26] Brian Gupton: when you've gone through this kind of a process and you, someone hasn't worked out what.Typically the reason, you know, that did someone just happened to full you in the interview or were there other factors that were less about aptitude and more about, you know, aptitude or execution? I personally, when I do interviews, I've kind of fine tune my spidey senses to sniff out a good engineer.[00:32:53] Tancho Markovik: What's difficult to sniff out is a good team player. So I've had cases where we hired the person that ended up being. This happens, right? Sometimes the person is in a very good mindset during the interview, because they're about to leave their company. They're seeing it's going good. It's going good. So they're very positive.Or during the interview, Very open, et cetera. Then things change after the joint. After a couple of months, maybe they decide they don't like the team. Maybe there's this new person that's pissing them off, whatever. And they switch mentalities. This is tough, right? Because at the end of the day, regardless how brilliant you are.You're just one person. If you polluting 10 other people, then like probably the problem is up with them. It's you [00:33:30] Brian Gupton: with video right now? Do you find that that, that happens more often with engineers? You've not worked in a startup environment before, because there's one thing that's common. I mean, depending on when you're joining, but if you're like joining at like the seed or series a stage and you're joining an engineering organization, technical debt is going to exist.I mean, it's always going to exist, but a lot of times engineers joining a company at, at those stages are coming into something. That works on the outside, but on the inside, there's a lot more problems than people realize. And I always find that people that if they don't just understand and accept that that's the reality of any, you know, technical business at that stage, they might quickly develop a bad attitude that thinking that, you know, people don't know what they're doing at this company.And how could they let things be like this. [00:34:27] Tancho Markovik: I mean, I have an allergy to technical debt, but I've also been a person that created a lot of it. I can tell you, like it's a fact and I'm sure that I'm still producing technical debt nowadays. the important thing for me is that, even at a young age, if you're allergic to milk, you're going to find substitutes, even though you're like five years old, right.You're going to have juice and whatnot through the blinds, the same way in engineering. That's a quote unquote, allergic to technical debt. You might skip unit testing, but you're going to build your code in a way that's testable. So you'll at least catch up in the future. I don't mind people introducing technical debt.I mind people that don't care, introducing technical debt to give you a very practical example to a group of engineers that I work with, I shipped a commit to their project workspace. Right disabled, the keystroke command control D because the control D in intelligence duplicate the block of code that you've captured.It's a very subtle thing. I made code duplication to be a little bit, a little bit more difficult. I'm not saying don't do it. Just saying like things three times. I put a small tool that will block their build. It will, market is unstable. It will fill pass. It will just be drained on green. So I wanted to kind of pick their interest if they introduced new methods, which are public, but don't have documentation.Everything works. It's just green, not green. So if it pisses you off, right? The documentation, I want you to mind that that's it right? Once, once you mind, once this is constantly in your head, you're going to find ways to introduce less of it. Simple, stupid example, Newport, put a dependency injection tool instead of creating singletons.When you do decide to do unit tests, life will be much simpler. You don't have to rearchitecture your app. You just need to write it. Right. So there's easy, right. But that's just one step in the direction. So I want you to mind now, [00:36:17] Brian Gupton: now what about the ultimate tech technical debt? And I'm using this term loosely here, but like when a business is forced to pivot because their original hypothesis was turned out to be incorrect, obviously that can potentially create a lot of technical debt for an engineering team.If you know, depending on how, you know, the business has pivoted. How do you deal with that from within your teams and not just managing the, you know, the new development that has to be made. And, and, but also I guess, like helping the team understand that, you know, no, all the work we did before, you know, it wasn't a waste, you know, we, we learned from it and what we learned is, you know, we need to take a new approach.[00:37:02] Tancho Markovik: And the end, it kind of boils down to whether just said, like, you need to mind the technical debt. So first of all, what's the purpose of pivoting to different direction because your business is forcing you to, if you want your company, if you want your product to continue living in a different shape, you need to make this change.This is absolute needs to happen, period. Fine. You had the time you thought it through, you decide you need to pivot. Okay. When you do pay. Then you made the hard choices. So when it comes to modifying this, this, this product you built in a way to serve a different purpose, what stops you from kind of carving pieces with a knife in such a way that you can expose them to a different module to say, this is garbage, that we'll have to rewrite in the future.This is explicitly technical debt and this other stuff can stay. It's fine. But like, Rapid with a piece of wrapping paper. So you know that this is it, right? This is the, this is the debt itself. It's not everywhere spreading like cancer. It's just localized in this big smelly piece of like, garbage, which we know we'll have to rewrite because you will mind you do it, but you label it.And then you label it through CACD to say that piece of code fine, but for the rest, make sure that unit testing is there that piece of code fine, but for the rest, make sure that the linting tools do not import throw warnings, be aware of it. If you are, if you see it for your eyes open, you do the right choices in the long-term and then you'll like any piece, any technical that imagine that.Obligation is 10% unit tested. You have a lot of incidents. You fix the incidents call is fine, but the test didn't move. There's still 10%. If you want to move it to 90% tested possible, how much does it cost? You get a bunch of externals. You throw money at the problem, right? You begin a bunch of externals.If you've done your job. Well, if you designed the system to be testable, you give them money. They'll put you in this. Changing your CACD to say new code needs to be 90% tested problem, fixed, solve with an amount it's a, it's a dollar, it's a Euro dollar, whatever it's currency, you you've solved the problem, but you sold this way.Paying other people to write this. The important thing is the core product needs to be you, right? There's different kinds of technical that there's architecture, which is even more difficult, right? Because. Change the engine of the car while running, while driving at a hundred, a hundred miles an hour, that's more difficult.I've been there as well. So if you mind, you're going to compartmentalize it into sections, which think you close the door and you leave it there, right? The horse that wins you don't change. So leave it be. But at one point invest because at the end of the day, your company builds any company builds assets and your assets are lines of code code has a life cycle of five.One human year equals 20 cold years. So something which is five years old is the equivalent of a hundred year old human. It doesn't work good. You need to make sure that your code is like, it's like a steak, right? You marinate it. You keep it properly. Like in you properly clean it, you properly put salt and pepper, whatever, whatever makes you have.When you, you take care of it. If you take a slab of meat and throw it on the floor, you come back three days later, what will happen to it? It will not be good to be eaten, right? So you need to invest in your assets. Your code is your asset for, for [00:40:20] Brian Gupton: company. So you, you actually, this has been a great conversation.We're almost out of time, but you actually led me into kind of the last question. I, you know, of questions I wanted to ask you and, which is what are your top three? Investment priorities right now for the PO for the next year, to like either improve your, your engineering team or just improve the product overall.Like w what are you looking to invest in?[00:40:50] Tancho Markovik: So, what we're trying to do is we're trying to focus on reducing our cost to serve. It's. One of the things they described at the beginning, we have made architectural choices in the past, which we needed to make to get where we are. But now that we're there, we need to make different architectural choices.Since we reduced the infrastructure costs to serve a single customer. There are technical decisions to be made to get to there. But the primary reason is this because we want to reduce the amount of money that we spend on services to provide service, to provide our service to the customer. The second thing is we want to do while we're doing this, we want to focus on scaling.we want to be able to consume, let's say I think our target was 10 times more data than what we call. Without affecting the cost to serve. So this is the second topic. And the third topic is in, it's kind of linked, right? All of it is, is intertwined. And th th the third, if it has to be three, the second topic would be while doing this, reduce the amount of technical debt, technical debt by us is comprised of disability of code and the quality of code.[00:41:56] Tancho Markovik: And like through tools, you can actually measure this and quantify them. [00:42:00] Brian Gupton: Okay. And, and what, you know, for, if there's engineers out there who are interested in joining your team, what's your tech stack? What do you, what do you look for? What are you looking to hire for in the next three, six months? [00:42:13] Tancho Markovik: I think a stack, is front-end is JavaScript, sorry, TypeScript and react.We have a previous stack, which is frozen, so we're not touching that. And we're just investing in new revamping or product by investing in react and TypeScript for the front end, spring boot and Java. We basically write the rewriting, let's say a monolith into microservices by carving out a piece, rewriting it, shipping it, and then doing another data is Java and potentially Scala on spark.And that infrastructure is built on dockerized Microsoft microservices. Basically the whole fact that we're building is we're trying to rebuild our whole product piece by piece into micro front-ends and micro services, which are. Each feature is comprised of a micro front-end in the microservice, which serves as a backend and the features communicate through each other in a way that gives you the full [00:43:06] Brian Gupton: experience and for, the, the engineers out there who might be interested and qualified for, for all of that.What's your 32nd pitch on joining is the cap. [00:43:17] Tancho Markovik: So I like working with smart people. That challenge what we do on the day to day. And if you are interested in joining a place where you can speak your mind and push your, have the ability to push your ideas to production, we will not talk to you. [00:43:32] Brian Gupton: Awesome.Well, Tonto, it's been great having you today. This has been really informative for those listeners out there. We'll put the URL in the information field, but you can find Izzy cap at www dot Izi, cap.com. Thanks so much. Tonto is great. Thank you for [00:43:50] Tancho Markovik: having me. .

Unlock more with Podchaser Pro

  • Audience Insights
  • Contact Information
  • Demographics
  • Charts
  • Sponsor History
  • and More!
Pro Features