31. Sergey Stelmakh, Head of Security Engineering at Yugabyte, on Innovation vs Security in Startups

Hello, everyone, and welcome to another episode of the Security Podcast in Silicon Valley. I'm here today, the very special guest, Sergei Stelma. He is the head of security engineering at a really cool database company called YugaBite. Before then, he was platform security architect at MuleSoft, which I believe they were required by Salesforce.

Correct. That's awesome. So you got to see the acquisition process before your time at MuleSoft and Salesforce, which became Salesforce. You were the security architect.

I would say the head security architect at Cipity Communications. And this is where our paths crossed way back in the day. Indeed. It was a lot of fun.

It was a lot of fun. There's some stories there. Before then, you were a software engineer at Bulba Labs. Yeah.

That's Bulba. Yeah. Yeah. Yeah.

I was doing software engineering and managing projects. And before then, this is so cool. You were an assistant professor at the Belarusian State University. Yep.

Yeah, that's true. Yeah. I started my career as a researcher. And even before that time, and maybe even a little bit of overlapping as your assistant professor should, you were a PhD student of mathematics at the same institute, the Belarusian State University.

So welcome to the show, Sergei. It's a great honor to have you. You bring tons of awesome experience to the table. And I'm sure lots of interesting stories.

Hey, John. Thank you for inviting me for your podcast. You've had an interesting journey. And it started off in mathematics.

And you were deep in the PhD program. But somehow you ended up in security. And I'm really interested. And I'm sure our listeners would be interested to just hear a little bit about how did you end up in security?

Yeah. For me, it was a very natural transition. As far back as I can remember, I always loved solving puzzles. And that's how I ended up and gravitated towards mathematics and programming.

And ended up in university studying applied mathematics. And as a side hustle, I started doing programming as well. And over time, transitioned into software engineering full time. As a side hustle.

That's awesome. Yeah. It started as a side hustle. I always consider only career in science at that time.

And so you were in self-taught engineering. I got a solid foundation, college and university. As you study mathematics, the programming and software engineering is a minor discipline. So yeah, normally comes shoulder to shoulder.

And as I was doing software engineering, I, again, naturally tended to pick up quite challenging tasks. And that happened to be in the security domain, cryptography in particular. So it was very natural step for me to move forward into cybersecurity. And yeah, for the past decade, it's been my primary focus.

No, that's incredible. And so with your foundation in mathematics and the overlap with cryptography, now I have to be careful about how I describe that because if I say crypto, people are going to think bitcoins and stuff. But the original cryptography. Yeah.

That's true cryptography. True cryptography. Crypto mining religion. No.

Yeah. Yeah. I mean, that's funny. I mean, I do challenging like old institutions, like our financial institutions.

But to me, like cryptography, crypto is always going to be like a bit smashing. And that all goes back to mathematics. Yep. Yep.

Indeed. So you probably had an amazing foundation to build on. It's something that most security folks maybe don't go quite as deep into. Yeah, it definitely helped.

Though I've seen people, and I'm sure that's true for you as well. I've seen a lot of different folks in our space. And so this, we all got a very diversified background. So that, you know, to have a PhD in applied mathematics is definitely not a must-have to build a career in cybersecurity.

Yeah, definitely not. But it can be one of those steps that you take on your journey as it was for you. And so now at YugaByte, maybe you'd like to share with our listeners just a little bit about what does YugaByte do and what makes it an interesting startup? What do you guys do better than anyone else in the world?

YugaByte is a distributed database for cloud-native applications. And if we get into technical details, which I assume some of part of your audience is. . .

We love technical details. Yeah, why world need another database? That's a good question. So YugaByte is a strongly consistent database.

And that's a technical term. With both SQL and NoSQL interfaces. So it's pretty much one database that you can scale. And you can run SQL and NoSQL queries against the same database.

Awesome. Awesome. And it actually solves some really difficult technical challenges with distribution and consistency. And I'm sure performance is high on your list as well.

But your role there at YugaByte is to focus on security. So I'm super curious, how did you end up as the head of security engineering there at YugaByte? What was that piece of your journey like? Yeah, you pretty much highlighted some of the steps in my career.

And before joining YugaByte, I was with MuleSoft. And I was driving security architecture at MuleSoft. I joined MuleSoft before we went public. And shortly after, we got acquired by Salesforce.

Okay. And yeah, that was very cool and interesting experience helping merge security function from MuleSoft into Salesforce. That's quite unique experience. It was a lot of fun and a lot of cool, challenging activities on the way.

But as this transition ended, I started looking for my next chapter. Yeah. My next chapter in my career. Yeah.

You came, you saw, you conquered. And then you're like, what's next for Sergey? Yeah. Plus, I always wanted to work in engineering companies.

And engineering, that's the companies with engineering culture. So it's a very broad term. It doesn't mean that run the shop got to be run by engineers. It's rather the way the problems are solved in the company.

So you face a challenge and you engineer your way out. And MuleSoft was an engineering company. That's very amazing engineering team. It was really pleasure to work with the folks.

And I just wanted for the next chapter, I wanted to join an engineering company as well. And guess what? There are no more hardcore software developers that are developers writing and developing databases in this space. So it's very hardcore guys and engineers, and it's a pleasure working with them.

So that was definitely a decision factor for me. Yeah, the people that we work with can make a huge difference. And I'm detecting a theme here. And I heard it a little bit of how you got into security.

And I heard a little bit of from just going into mathematics in general. But it feels like that you really love hard problems. And then you love the creative bubbly juices that sort of are you have to access in order to solve the problems. And not just solve them, but maybe solve them in a beautiful or elegant way.

Yeah, you pretty much nailed it. It's definitely my job matches my personality. And I think it's important for everybody's career to make sure that whatever you do is aligned with who you are as a person. Oh, that's so true.

And I love diversity, too. And the differences that everyone brings to the table, it makes it super interesting to build teams and bring different people together. Because everyone is going to bring something different to the table. But everyone does bring something to the table.

I think you nailed it right there, too. Thank you. The how about a typical day at YugaByte? What's your focus?

How do you contribute to the success of the company? How does security play a role in that? A security domain is very broad. And if you just Google, and I always encourage whoever is joining security space, have this OWASP domain diagram, even pinned on your desk.

Security domain is very broad. There are like 20 different areas where cryptography, for example, is just one of them. And in my role at YugaByte, I primarily focus on DevSecOps and application security. That includes vulnerability management, threat detection and response function, certain security architecture, and secure SDLC activities.

So that's in supporting compliance. That's also part of my daily routine. That's some challenging space, compliance. It can be.

. . Yeah. I feel that in OWASP space, a lot of people misinterpret the compliance.

It's to me. . . And again, working with engineers, I hear a lot of them complaining about certain compliance requirements.

And it's coming from misunderstanding the concept. The compliance gives you a framework, making sure that you're not going to miss a thing as you harden your organization security posture. Like, I love crypto. If I had a chance, I would probably spend most of my day doing just cryptography and interesting cool things about a key management, certificate management.

But with having this framework, it forces me to think beyond that. You're thinking about how do I upgrade the software? How do I keep the supply chain secure? How do I roll into production without unnecessary risk?

Yep, absolutely. Yeah, that's. . .

You know the drill, John. Yeah. I've been in the industry as long as I am. So what would you say your best day at YugaByte has been so far?

So far. Yeah, I think it's still ahead of me. Frankly, maybe when we go public, that's going to be one of those days. Oh, when you go public.

Okay. Amazing. Yeah. Yeah.

I'm reserving that for that day. My joy. It will be a joyous day indeed. What about the most challenging day that you've had so far in YugaByte?

I think it's days, not a day, not that day. We are, as you're aware, security is a risky business. Right? We take into account a lot of variables and try to come up with quantifiable risk level.

Right? We are in the risk management business. And when, for example, a breach happens in the industry, what notorious examples would be like Log4J or LastPass. Because every time things like that happens, the level of uncertainty is quite high.

And you've got to operate as a security professional under a lot of unknowns. So those days are the most challenging. Like when LastPass compromise happened, yeah, we figured out within an hour that we're not affected. But that was a very tough hour.

You always, if there is something that you are uncertain about, you always assume the worst. So those days, they are the most challenging. Yeah. It's tricky sometimes to operate and to make decisions with missing information or things that we don't know.

And just even the ability to stay calm and focused and like over the top optimistic, but positive. And compassionate to the human side of everyone's emotions as things unfold. It's a sweet spot of what makes a good leader. And it sounds like they're very lucky to have you at Utabyte.

I hope so. No, absolutely, Sergei. We've worked together for a good chunk of time back in Symphony. And I know that I always felt that way.

Yeah, it was a pleasure working with you, John. We had a good team. It was a very good team. And it was the people that made all of the difference.

And we were all part of that. We're all in the same boat together. And it was a startup. And we're all running towards the same direction.

But we all bring something different to the table. I encourage people to try big companies and small companies because you get different things, different types of experiences. So they're hard to compare. But I do think that I do prefer the smaller companies.

Yeah, it depends on the stage of your career. Sometimes after a few small companies, I want to join a big shop and deal with their work with a big budget rather than scrapping things. Oh, big budgets are nice. Always.

Always. But yeah, I agree with you, John, that this combination of the small and big companies, I think it's you get to think, you get to see a lot of different things and be exposed to different functions. In a smaller company, this exposure is much bigger than in a big corporation. Yes, yes.

And then the experience at the big companies tends to be very valuable at a small company because it's what they're missing. And vice versa, too. Like at a big company, like all of your experiences from a startup would pay off huge, like many times over. Like they have the opposite set of problems.

And you always get to pick the set of problems that you deal with. But you know what, oftentimes in the security world, people think we have this reputation of being the guys that show up in a meeting and we're here to say no and throw a bunch of requirements on the table and draw out the time to market. The timelines of a particular project and want to do deep dives into threat models of new features and stuff like this. And I've been put in awkward situations like that.

And it's always, yes, we have to do the right thing in terms of security, but I've always struggled. Is there perhaps a way to think about security that enables innovation, enables change and enables people to move fast? That's a good question. And it's a very important topic, I think, in our industry.

Actually, I want to mirror this question back to you. What do you think? Is there a way? Is there a way?

I think so. I think so. I hope so. And I'm optimistic about this.

And like I've worked with people on both extremes of that equation. I've been thinking about this problem for a while. And I'm frankly a bit more skeptical than you are. Oh, really?

Okay. Yeah. Let's just think about it. Security is all about mitigating risks.

Right? You mitigate risks. It is. You're reducing the risk.

We're reducing risk. That's right. Innovation is actually quite opposite. It's all about taking risk in order to make a big improvement into a certain space.

That's right. So your goals are radically different. This is true. You're probably familiar with this for everybody in the industry with this very famous metrics, reversed dependency between security and usability.

Oh, yes. You want to make something usable and secure. Like it's impossible. So it's one way or another.

You got to balance out. And I feel that we overall in the industry, we got extended to the same concept to like security versus innovation. We are, it's all about finding the right balance and letting your organization be innovative and secure at the same time. Because if you're not, and we as professionals, our job is to pin this security controls into the right place.

That's right. One of the famous examples would be the recent Google versus ChatGPT situation. Google was a leader in AI space. And they're losing this battle.

And they're losing the war to ChatGPT and OpenAI. And Microsoft, no. Yeah, and Microsoft. Yeah, indirectly.

Indirectly not. Yeah, there is this big guy in the room, big elephant in the room. But I bet what happened, and I'm going to be a little speculating right now. But some time ago, like five, ten years ago, when Google was a leader, there was a big meeting.

Like on a big, long table. There were a lot of guys sitting in the Google office. Very expensive meeting for everyone. Very extremely expensive meeting discussing the future of their AI technologies.

And there were a few guys, and I bet there were a few guys from security sitting in that room saying, oh, you can't do it. It's too risky. Yeah. I could see that happening.

There's just so many unknowns. As a result, now we see Google losing to their competitors. And we can extend this example, and that's what pretty much happened to Tesla. It used to be a leader in self-driving technology.

And I don't think it's even in top three these days. Yeah, so it's a lot of, so at some point, the companies became too cautious, and they misinterpret certain security risks. And I think as security professionals, we need to, first of all, we need to acknowledge that's the fact. Yep, yep.

So we, and I always say that you were, and actually in the question, that we tend to say no if we don't know something. And now I'm probably going to give advice to, not the security professionals, but the people that work with security professionals. All the product managers, all the product managers that want to know how to circumvent security. Here we go.

What's the secret? No, when you hear no, it only means that we don't understand. There is an unknown element. To me, I always say, listen, there is yes, no, and fuck no.

As long as you haven't, you didn't see the, you didn't hear the latest, last option, there is a room for us to have a conversation and come up with a reasonable solution. Yes, no, I love that. I actually just ordered a t-shirt. And on this t-shirt, it says, short answer is no.

And then the long answer is fuck no. I'm going to, I'm going to buy another one and I'm going to send it to you. Yeah, get me one. Yes.

And wear it on all of your Zooms. European large size or US medium. So that's. Okay.

Or Australian medium. Yeah. That's again, it's a, that's a big question. There is a lot to unwrap here.

How you do it properly. If we get to a bit more practical. Advices or recommendations. I tend to focus more on threat detection and response.

Yes. Yes. Yeah. Okay.

So the way that I've navigated that question. And I've been in big companies. I've been in small companies. And in small companies, like one of the things that you can take advantage of, and that I certainly have taken advantage of in the past is if you're so small that you have no market share and you have no customers and you're just like experimenting and you're, you're the guy on the team.

You're the guy in the company that the only guy in the company, maybe, or maybe a gal in the company that has that security mindset that cares deeply about things like data privacy and being able to close like bigger and bigger deals maybe, or whatever it is. But if there's no customers, like there's oftentimes no risk. Right. And then as you release things and you acquire those customers and you can predict, oh, we're going to have a hundred million users and we're going to have, and then by, by year two, we'll have 10 million users.

You can just be like, yeah, okay, that's nice, but that's not, odds are it's not going to happen. Just let's accept the reality of do an experiment. If you're a startup, you're doing experiments. You are taking risks big time.

And then security, I don't know, in that sense, like I always try to tie it back into the business and make a business case for security. And just in those particular cases, maybe this is why like startups, because they do take risks. Yeah, I guess I would rephrase it a little bit. So when the smaller company, you not taking risks, you have a better, you have an ability to better interpret security controls.

Yes. So, and you can interpret those security control that is, they're still secure for your customers. So they're still keeping the product secure and robust for your customers. And it's not a burden for your engineering team.

The example I would give here years ago, I've seen security control that, oh, you must white-list IPs for internal infrastructure. But that was at the time when Kubernetes was becoming a standard to run in microservices. What is the IP address in that environment? It's just ephemeral.

You got to take that control and reinterpret it. And that became, at that time, we started doing something with, we started using Kubernetes network policies to harden by spirit. And it is even better. And it's more secure than the original control was.

But in a big bureaucratic corporations, it's much harder to push it through. Yep. No, that's, that is true. And there's certainly less red tape in the small organizations.

And so it's much easier to get something adopted to, to start using a new technology to reinterpret controls quickly. You don't have to go through a bunch of committees. If you're like the one that has the ear in the company around security, you could just maybe suggest something, try POC, do a demo and boom, you've just won over the other like 20 people or 40 people or whoever is also in the company. Which is not something that you can do in a large organization.

I mean, you could, but it takes much more effort, takes much more time. It's an interesting experience though, too. I've done it in both things, smaller company meets, mid-sized companies. Actually at Salesforce as well.

So when I was there, it is possible. It's just a number of meetings that you need to have to do that. The cost is number of meetings. Oh my goodness.

Yeah. Yeah. That's the cost. That's the cost.

Yeah. You, sometimes you just need to get the stuff done. Oh yeah. I remember, I remember, I actually just recalled a very cool project that I had in my Nolsoft days when we were going through FedRAMP certification.

Not sure if you had guests or when you discussed that framework. Which, which is the framework? FedRAMP. FedRAMP.

Yes. Oh my goodness. Okay, go ahead. What was your FedRAMP experience?

Oh, that, that was painful and interesting. Yeah. A lot of, that's the most probably sophisticated security framework that I ever seen. On paper, I got exposed to impact level certification.

That's for Department of Defense in the US. Yep. So yeah, those guys are extremely crazy. But from a company friendly framework, I say FedRAMP is a top, top notch.

They're the most holistic security framework I've seen. Yeah. And yeah, it's actually a lot of thoughts and a lot of security controls and a lot of engineering work that needs to happen for you to comply with their requirements. Yeah.

I remember like the amount of detail and the amount of attention and like the auditing. And it was perhaps one of the most rigorous processes. Yeah. And on top of that, I think it was AWS, right?

They just scrapped their regular AWS accounts and they're like, okay, if you want to do FedRAMP, you have to use like all of these special services. Go off cloud. And that was like years behind. So in reality, your product couldn't even work there.

It's a quite challenging technical problem. And GCP is, it's much better now. Now there is a more or less feature parity, at least for GCP, Google cloud. That's the case.

Or maybe AWS. I didn't reassess it recently, but it's much better position now. But you know, like when you talk about security, you think about, okay, what are we actually protecting if it's just a big pile of data in like Facebook or something? Yes.

It's people's lives and it does matter. It's PM. And there's like cyber bullying that can go on and all sorts of like nasty stuff. But when you talk about FedRAMP and you talk about like defense contracts, you're thinking like three letter agencies.

Those might actually be people's lives on the line. If there's a security breach with everything that's happening in the world today, the conflicts. From their recent exposures and the breaches that we've seen, it's a human factor. It's an internal intruder or some internal idiot who shared some, overshared some information.

Yeah. So yeah, but partially because technical controls are pretty good. Yes. Yes, they are.

It's funny what you can get when you just get somebody on the phone and you can win them over with a slight sense of trust or an email. You know, security awareness is a key for success here. So you got to spread awareness within your organization and advertise what we do, what our profession is about. So yeah, that's why your podcast is handy and can spread the word.

Thank you, Sergei. I'm so sorry. You were about to mention how to enable innovation with security. You must feel like the pull or the drive to sometimes accommodate like what a business is trying to do, needs to do in terms of its innovation or its feature sets or the customers that they're selling to.

Sometimes customers can be our best friends. I mean, I don't know exactly who you're selling to at YugaBite, but in large B2B deals, it's super easy to do security because in the companies that are trying to sell to larger and larger businesses, you'll have security teams in those other businesses put up requirements and say, where's your SOC2? Where's your FedRAM? If you're in HIPAA, where's your B?

They want to know about all of the details. And then you don't have to be the one to be like the quote unquote bad cop. The customer, like the growth of the company now depends on your security. And your security posture.

Yeah. No, that's, let's have a discussion here. Let's add some spice. Oh, yes.

To our conversation. Yes. I do work with customers and I see there's some, the requests, the feature requests coming in for security. And it's been in every company I worked, I was exposed to that function.

And frankly, some of those requests, they don't make sense. They're shenanigans. Some of them. They're like.

So I. I actually saw one yesterday that was like totally insane. Some potential customer asked us if we were going to ask permission to add a new vendor from this customer. And keep in mind, like we have a hundred customers.

So. Yes. Of course, we're not going to ask for a hundred people's blessing. Add a new vendor.

If we're going to add, for example, Datadog or something like that. If we wanted to add that to our tech stack. It's not. Or YugaBite.

Yeah. YugaBite. Or YugaBite. I would love to add YugaBite to our tech stack.

I hear it's very secure. Oh, yeah. That's just a tip of an iceberg. They often operate with some security questionaries from 90s.

They haven't been able to. Some controls, they just, you read them and they're the questions they don't just. They're 20 years old. They're not real anymore.

We are operating completely different reality. So, yeah, I tend to always get our, when I get requests like that, try to find a better business justification. So I would rather accept feature requests from business customers rather than security teams of those customers. Because they're not in that particular business.

They just have a list of requirements and they roll it to you. And actually, one of their challenging asks that I had to confront was everybody seemed to be obsessed with their HSM. Oh, yeah. And yeah, I actually feel that it's just CISOs, HHSOs, something like that.

It's just. Yeah, I think they have a booth at the Volcom Street there. Yeah. They're like, hey, try to set up an HSM.

No, seriously, if you ever work with HSM, you wouldn't like that technology. No, of course not. It's very hard to manage. It doesn't work.

And it only, it's designed for a few particular use cases. That's true. If you're not running like DigiCert or public certificate authority. Maybe we should share with our listeners, like, what is an HSM for some of the newer folks in security?

Yeah. HSM stands for hardware security module. Basically, that's a piece of hardware that does cryptographic operations for you. Yep.

Yep. And yeah, physically, it looks like a server. Any old regular, like, rack mount server. Yep.

Yeah. And yeah, it's really hard to operate. If you shake it too much, your key that is stored in that piece of hardware, they're gone. You know what it's doing is it's trying to fail safe.

It tries to like, yeah. Yeah. And the crazy example, I think all those crypto companies, they actually store their private keys for their crypto in HSM. And yeah, if something happens to those HSM, the keys are gone.

So I wonder, yeah, I wonder if you had any guess from like Coinbase. What's the backup mechanism for the keys? Because you can't have too many backups because then it's not secured because you share your keys. You're exposing yourself.

Yeah, you're exposing. It's a risk to your whole business model. And yeah, how did they solve this problem? Yeah, that's a great question, actually.

So yeah, the HSM is a nice piece of technology, but there are so limited, so very limited number of use cases for that technology to be used. And I see that everybody seemed to be obsessed with that. Let's integrate with HSM, but it doesn't make sense. Right.

Like you guys want to store one secret and you want me to add a support for HSM to store and manage one particular secret? Right. It's just unbearable. I mean, use key management solutions instead.

Or like CacheCorp or AWS KeyMask. There are plenty on the market. Yep, exactly. Or let's build a chat system and have it all inside of an HSM.

All of the keys saved inside of an HSM. Does that really develop a surrogate? It does. It does.

For all of our listeners, this is what we built at Symphony Communications together. It was a great technical project. And maybe for that particular use case, it was worth doing. But yeah, that's just a very limited number.

Yeah, it did open up a lot of sales to Goldman Sachs and JP Morgan and BlackRock and all the big names in the industry and the financial industry. But it never broke out of any of that vertical and was able to grab market share in anything else. And then Slack came along, which was like super easy to use and grab the market share. Security versus innovation.

There you go. That's the prime example. Definitely one in the dampen innovation space, maybe. Yeah.

I mean, Symphony, it was a special case because all of the large institutions, they were not only the first customers that Symphony was going after, but they were also. They were all on the board of directors and they basically owned the company. So it's a double-edged sword if your investors are also your customers, I think. Yeah.

They have a very strong vision and they're pushing that vision. So yeah, it is. I can't agree more, John. I got the sense that you really enjoy tough technical challenges, things that you can engineer your way out of.

As you put it earlier, when you're team building, like what do you look for? Do you have a favorite interview question? Is there like any red flags that you want to share that are like, oh, yep, for sure. Maybe not the best fit.

Or like green flags where you're like, oh, yes. And you fight to the death to bring in the candidate. Over years, my interview toolkit kind of simplified a lot. Oh, that's good.

My mind is mine. I just asked candidates, just give me your top challenges that you worked on and I let them drown. That's it. You let them drown.

Yeah. Is this a Russian expression? Yeah, sort of. It is.

It is. What is it? What is it in the authentic, like original language? So the meaning would be that they're just, that's a good analogy.

If they're not good in swimming, they're just going to drown. Very simple approach and you see it right away. So you, and also I don't like asking some, the questions that are, this are all technical questions that a person may not be familiar with. So I let them choose the area they're comfortable with and have a conversation in that domain.

I think it is fair and also you see the professional right away. So in the interview, to me, it's a conversation between two professionals and you just see if there is a, it's a good match for you to work together. Yeah. You feel it through and you make sure that there's positive energy on both sides and you know it when you see it.

And of course there are multiple rounds and we also do coding interviews and stuff. So I do expect some technical skills going to be assessed at a different stage. Sure. Maybe by someone else's interview.

Right. And then like when you do the huddle and I assume like you, you would invite like most of the folks that would be working with the person together. Those inner discussions. Okay.

If someone raises a concern, is there like a process around like championing the candidate or challenging the fit or it's just like a relaxed conversation maybe. If you look for consensus. I've been at other places too, where it was like someone could raise a concern, but then there could be a champion and then the champion. Yeah.

I don't get it, John. Yeah. I don't. It's not a democracy.

No, it is not. No. Yeah, it is. I mean, I do.

If you say no, I expect justification. You can't just say, ah, I don't like their outfit. So you've got to be very reasonable explanation. Of course.

In fact, you need a lesser explanation when you're given yes than when you actually say no on the interview. I do expect a very detailed explanation on why you're rejecting the candidate. And all the red flags and what you found. Yeah.

Everyone has a different interview style and will ask different questions. So that sounds like a really healthy approach. Very healthy approach to team building and to interviews. When you team build, is there anything that you do look for complements with new members?

And diversity in skill sets. That's definitely something I'm looking at. And also for security team, I also look for, I'm building a global team. Because in case of security incidents, we need a better time zone coverage.

So yeah, my team tend to be quite diverse geographically as well. Oh, that's great. And then you can get better. It's always possible.

So it's not a generic advice. But yeah, for me, that was an option. And I love to have this flexibility. With geographic diversity, you're going to get all sorts of great diverse teams.

Just as an actual caveat to that too. So that's awesome. Okay, Sergei, if you could go back in time and meet your younger self. And I'm going to let you decide how far back in time you'd like to go.

But if you could go back in time, you could meet yourself and you could give your younger self a piece of advice. Anything. Or maybe you would pass on the opportunity. Would you?

And what would that advice be? I would love to get a beer with younger myself. Oh. And have fun.

And yeah, it's interesting how they're. You're a different person. Oh, super different. Yeah.

Yes. Yeah. I guess from. I would probably advise to prioritize mental and physical well-being.

Oh, that's such good advice. Yeah. How would you sell that to your younger self though? Because I'm sure your younger self would be like, oh yeah.

Great. Thanks for the advice, Sergei. Older Sergei. You old man.

I don't know. Maybe I would miserably fail in giving this advice. Oh, I know. I would.

I would have missed. You're really cute. I. But actually there is something that I.

I. But I actually got a motto. Like a catchphrase. Not a catchphrase.

Oh yeah. Oh yeah. What it's. Amato.

Amato. Amato. Amato. Amato.

Amato. And. When I was relatively young in my career and. I'm following it until this day.

It's. It's about. If you don't. If there is something you don't like doing.

You gotta stop doing this. Even if you don't have alternative. Because you need to free some time. In order to do something else.

And yeah. I would. Probably start following that. Even earlier.

In my career. That's really good advice. If you don't. Absolutely love.

Something. If you don't like doing something. Stop doing it. Yeah.

Get yourself bored. And then you'll find something else to do. You'll find it. Yeah.

And it doesn't always need to be the same thing all the time. I think people are allowed to change their minds. And I know I've changed my mind several times. And I've been lucky.

Absolutely. To always have that land somewhere in the security space. In a professional sense. But in a personal sense.

Like. Same thing. Same thing. Very good advice.

I love it. I have this game that I play with myself. It's almost the same as your advice to your younger self there. Your motto.

Is. We know that one day will be our last day. And if you had an opportunity to replay any previous day. I just go through like the experiences.

And. That day. Like one more time. Like before.

Your last day. If you would swap that. Last day with. Today.

For example. If the answer is no. Like if the answer is no. I wouldn't pick this day.

It's just not a very good day. I ask myself why. And whatever I come up with on the why answer. I change it.

Just change it. Yeah. Frame slightly differently. But yeah.

That's a good one. Thank you so much Sergei. For joining. For a show on the security podcast of Silicon Valley.

It was a great pleasure to have you on. To hear about your experiences. The philosophies. And have a little bit of a discussion around security versus.

Innovation. Thank you Sergei. Yeah. It's been a pleasure.

Thank you for having me John. You're always welcome back. Would you like to leave. Listeners with any.

Final. Girls of wisdom. Spread awareness. And.

Yes. Teach someone about security today. Yeah. That's what we're here for.

Okay Sergei. Thank you so much. Thank you John. Thank you for having me.