Valeriy Zamaraiev: Navigating the Crypto Landscape - A CTO's Perspective on Web3 and Beyond

00:08 - 00:14
My name is Leszek, and I will be talking with Valeriy Zamaraiev about web three crypto networks

00:14 - 00:17
and the importance of being result oriented.

00:17 - 00:24
So for the context, I'd like to ask you to share a bit of your professional journey and how

00:24 - 00:30
you transition from maybe more traditional tech roles to CTO at one Kx.

00:30 - 00:38
I'm a curious person, an engineer who liked to fiddle with computers since the childhood.

00:38 - 00:48
I mean, my first programming experience was this in Ukraine, and actually in the Soviet Union. It was called Umka.

00:49 - 00:59
That's like a CPU board that you can actually see the bus light on bus lines, and you could

00:59 - 01:03
type in hexadecimal, and you could kind of type machine code.

01:03 - 01:16
And I was just doing hobbyist electronics, and I wanted to program a particular set of codes for doorbell, musical doorbell.

01:16 - 01:19
And I picked the tune and I translated it into hex.

01:19 - 01:25
And then I typed all of this, and you could not save it at this machine, so you have to type

01:25 - 01:28
it, and then you write it into wrong.

01:29 - 01:31
And then you use this rom and the doorbell.

01:31 - 01:36
And I did that, and I then discovered that it sounds wrong.

01:37 - 01:40
And then I was like, okay, what's wrong here?

01:40 - 01:45
And then I realized that I had the upper bit in every byte.

01:45 - 01:50
Inverted all my table, and I was like, okay, I have to retype all of this.

01:50 - 01:56
Or there's actually, you can program this thing and maybe this can do it for me.

01:56 - 02:02
Maybe I can just invert the bit in all the bytes by writing a small program.

02:02 - 02:04
But there's like not even assembly language.

02:04 - 02:09
There's just like a table of hex codes of how machine code works for this thing.

02:09 - 02:12
And it's Intel 8080 cpu, right?

02:12 - 02:16
And then I typed that, like, machine code.

02:16 - 02:20
And then I ran this thing and it inverted that bit.

02:20 - 02:22
I wrote this to Rom again.

02:22 - 02:27
I put this IC chip into my doorbell, and it sounded all right.

02:27 - 02:35
And at that point I realized, okay, that's how programming works. I figured it out. I know everything. I'm the best programmer.

02:35 - 02:38
That was like the moment when I was, I don't know, eleven or something.

02:39 - 02:44
And from that point on, I basically knew what I would do in life, right?

02:44 - 02:46
So everything else is kind of history.

02:46 - 02:52
Like different roles, technical roles, managerial roles, then back to technical roles, then

02:52 - 03:00
small companies, large companies, startups, big enterprises, then big tech, crypto.

03:01 - 03:03
All of that is kind of history.

03:03 - 03:05
But we can talk more about the journey itself.

03:05 - 03:09
But that's like, in a nutshell, like, you just need to have this kind of genuine interest to

03:09 - 03:14
fiddle with things and then to get some result out of it because a lot of people who kind of,

03:14 - 03:20
you know, they just like fiddling and they are not so much focused on the results.

03:20 - 03:25
Like, I've seen a lot of people who would be kind of, you know, oh, I worked in this amazing startup.

03:25 - 03:26
We had so much fun.

03:26 - 03:28
The setup failed, but like, we had so much fun.

03:28 - 03:30
Let's go on to the next one.

03:30 - 03:30
You know, we don't care.

03:31 - 03:33
Like, you know, it's like, okay, this one failed.

03:33 - 03:36
Let's go to the next one that will fail as well.

03:36 - 03:40
But like, we will have a lot of fun for two years, right? So, and that's fine.

03:40 - 03:43
And they just move on and on and on.

03:43 - 03:48
And I was always kind of focused a little bit of, okay, but I do want to have some results, actually.

03:48 - 03:50
I do want things to make sense.

03:50 - 03:52
I think that it's these two components.

03:52 - 03:59
This approach, it was by nature, or you learn it along the way, that it's not about fun because

03:59 - 04:01
for certain people it's like, it's an education.

04:01 - 04:08
Being in big companies like Google, Amazon, it's like there are quite like goal oriented or

04:08 - 04:11
outcome oriented, and it's just like people learn.

04:11 - 04:17
Did you have it like from day one that you were sort of this result oriented person or just out of curiosity?

04:17 - 04:26
No, I'd say it was much earlier because for me the result was always important.

04:27 - 04:34
And I was like, I always like to be this lazy programmer that, you know, if you don't have to

04:34 - 04:37
code it, if you find a way not to code it, you don't do it.

04:40 - 04:47
And I had this conversation with someone while we are, for example, there is a system that can

04:47 - 04:54
be tweaked by changing its configuration file, or you can rewrite some modules, some code.

04:54 - 04:58
I'm pointing someone to say, we just can reconfigure it a bit.

04:58 - 05:01
And the person says, well, but I am programmer.

05:01 - 05:02
I can kind of do some c coding.

05:02 - 05:05
And I'm like, well, I'm not assisted.

05:05 - 05:06
Mean, I'd rather do that.

05:06 - 05:08
And I'm like, but that stuff is easier, right?

05:08 - 05:12
So you just kind of tweak a few lines of config and here you go.

05:12 - 05:17
And it's not always, you see that this mentality is like that.

05:17 - 05:21
I mean, my mentality has always been like, do more with less.

05:21 - 05:26
I'd like to talk a little bit about one KX and your role as a CTO here.

05:27 - 05:33
Could you tell us a little bit about the core mission of one KX and how does it differentiate

05:33 - 05:36
itself from other venture capital funds in the tech.

05:36 - 05:47
Space so one key x is an early stage vc fund focused on crypto networks, and that is basically

05:48 - 05:50
what it is since 2017.

05:50 - 06:03
I joined a little over a year ago, and the fund has been supporting some stable projects in the web three ecosystem.

06:03 - 06:05
So for example, we have safe, like nosis.

06:05 - 06:17
Safe is one of the big positions, like wallet, Connect, like cowswap, ARV, even that's just not infrastructure.

06:17 - 06:30
We have, for example, budget penguins in our portfolio, various projects, defi NFT, infrastructure, deep in networks now.

06:31 - 06:37
So across the crypto ecosystem is pretty much everything now.

06:37 - 06:43
Gaming is becoming a very interesting direction for you guys, autonomous worlds.

06:46 - 06:57
And I think the major narrative is being like this partner that companies can rely on, the startups

06:57 - 07:05
can rely on, because the founders have themselves been entrepreneurs before starting the fund.

07:05 - 07:10
So their mission was like, okay, let's make a vc that's actually useful.

07:11 - 07:15
And I have pretty good feedback from founders.

07:16 - 07:24
The best thing that I can experience is then when I am on a call with the founders and it's

07:24 - 07:31
supposed to be kind of a technical due diligence calls or something, and the founders say, well,

07:31 - 07:36
you know, we are with you because we had very good references and like in the industry there

07:36 - 07:37
is a very good reputation.

07:38 - 07:46
And sometimes they say, somebody had a good feedback about me specifically.

07:46 - 07:50
And that's the best praise that you can get in the industry.

07:50 - 07:54
Probably you have a good reputation and that's actually the most motivating thing I would say.

07:55 - 08:04
Nice. You mentioned that you want to make a VC company or a fund that is actually useful in that context.

08:04 - 08:11
Could you share or describe your main responsibilities and how do you contribute the strategy?

08:12 - 08:14
So I basically do four things.

08:14 - 08:17
The major one is portfolio support.

08:18 - 08:20
We have these companies and sometimes

08:23 - 08:25
they have varying technical needs.

08:25 - 08:34
Sometimes there is a gap between multiple portfolio companies and I can see how they can work together.

08:34 - 08:40
For example, sometimes they need some guidance on technical leadership, sometimes it's a narrow

08:40 - 08:46
technical problem that I just know from experience of, I don't know, working in previous crypto

08:46 - 08:50
companies or in big tech or something that I can contribute to.

08:52 - 08:57
There's a lot of these type of kind of support things.

08:58 - 09:02
Sometimes we can build something that they cannot for whatever reason, right?

09:06 - 09:09
Could be interviewing people, right?

09:09 - 09:13
Sometimes, like I'm a secondary interviewer, like a recruitment process.

09:13 - 09:14
Okay.

09:16 - 09:18
Then that's the first thing, that's portal support.

09:18 - 09:22
And the second thing is internal projects.

09:22 - 09:31
So we have an internal technical team and I run this team and we do internal projects and the

09:31 - 09:36
products will be focused on like essentially providing public good.

09:36 - 09:40
We're not incubating companies within the fund.

09:40 - 09:48
At least at the moment, we're just focused on improving things in the ecosystem and maybe building

09:48 - 09:50
something that does not exist.

09:50 - 09:57
For example, we will be releasing soon a tool that allows you to observe latencies of different

09:57 - 10:01
RPC endpoints from across the world.

10:02 - 10:12
In Berlin last week, we announced that we will be publishing soon zero knowledge module for

10:12 - 10:23
gnosis safe that allows you to sign transactions anonymously, like you have a list of owners

10:23 - 10:29
and you see them, you know them, but who exactly sign a particular transaction will be able

10:29 - 10:35
to kind of hide, because privacy in multisig is something that does not exist today.

10:35 - 10:43
But we are bringing this to the world, and there are sometimes other more internal projects

10:43 - 10:47
related to kind of internal infrastructure, or like infrastructure of our companies.

10:47 - 10:53
We would run some nodes from these networks just to give them feedback, how it all goes.

10:54 - 11:00
But usually with these projects, there's no goal to make money, because we just want to make

11:00 - 11:03
money in a very different way. Right.

11:03 - 11:08
The goal is to kind of support again this whole network.

11:08 - 11:13
So it's like goes back to the first point for this, but eventually in internal projects are

11:13 - 11:19
kind of also aimed at this purpose, but they're public also.

11:19 - 11:21
So they contribute to the entire system.

11:21 - 11:27
Actually, there's like internal projects privacy between us and this portfolio company that's also kind of.

11:27 - 11:30
And the fund, it's like a financial institution, if you will.

11:30 - 11:35
So there's like internal projects that are focused on that, like optimizing internal processes.

11:35 - 11:38
That's also kind of part of what we do.

11:39 - 11:46
Then the third thing is, well, technical due diligence as the new projects come in into the

11:46 - 11:55
pipeline, I just need to kind of have a look at and see if the technology is reasonable.

11:55 - 11:56
Do I see any red flags?

11:57 - 12:01
Interview the team, see if people know what they're talking about and things like that.

12:01 - 12:08
So that's a very typical vc type of snob, like technical due diligence of all incoming projects, right?

12:09 - 12:12
That is a big, big one as well.

12:12 - 12:14
Sometimes it's critical, sometimes it's not.

12:14 - 12:19
Sometimes it's like everything is so obvious that I'm not even involved in those conversations.

12:19 - 12:25
Sometimes it's like there's not much technical depth, or it's just very obvious that these people are kind of competent.

12:25 - 12:31
There's no doubt when there is some additional need, just sanity checking, then I'm at home.

12:31 - 12:41
And then the fourth thing, and I think this is kind of the major one, actually, is just staying

12:41 - 12:48
on top of everything that's going on in the industry, understanding the trends and just being

12:48 - 12:56
hands on and some of those new things that are coming right market and just maintaining the

12:56 - 12:58
level of expertise across the board.

12:58 - 13:05
Because when you work on a specific project, you tend to just focus on that and maybe a few

13:05 - 13:11
ages and areas, but not really going broad.

13:11 - 13:15
And here it's important to kind of have some bread.

13:15 - 13:18
Cool. I'd like to do two follow up questions to that.

13:18 - 13:24
First, I'd like to ask about this staying on top of things thing.

13:25 - 13:33
Do you, I mean, it's a continuous thing, I can only assume, but you reserve or book time for staying on top of.

13:35 - 13:36
I don't have a recipe.

13:36 - 13:37
I wish I could do it better.

13:38 - 13:39
I wish I could do it better.

13:39 - 13:43
So there's always some kind of a focus area.

13:44 - 13:46
So I'll kind of, I want to learn this.

13:47 - 13:52
And therefore we may just start some kind of a project with a goal of learning.

13:54 - 14:00
We have internal hackathons sometimes where we just basically try to use the technology of our portfolio companies

14:03 - 14:09
and sometimes the outcome of that is useful and we move forward with it and it gets bugged.

14:09 - 14:13
Internal product, yeah, but I mean, it becomes external.

14:14 - 14:23
For example, in gaming, we did a hackathon that became a separate, later became a separate game, Hexcraft.

14:23 - 14:31
And the company that's involved in this playment actually kind of started using this, like what

14:31 - 14:39
we did in the hackathon and their processes, and that's the kind of portfolio support that they like in other hackathons.

14:39 - 14:46
It could be like, okay, we, we did something, we built it, we shelved it, we moved forward,

14:46 - 14:59
but we had so much experience and understanding of the stack that we regarded as super useful

15:00 - 15:07
for interacting with these companies and for technical due diligence and future investments and for portfolio support.

15:07 - 15:11
So the net outcome is positive even if we shelve that project.

15:12 - 15:18
I've heard also another tactic which is interesting for me, it's that if there's not a possibility

15:18 - 15:23
to deliver something that is tangible, I mean, like a piece of software, people also write essays

15:23 - 15:26
to have some kind of output and oh, absolutely.

15:26 - 15:30
And I'm going to try, I learned recently about the tactic and I will.

15:31 - 15:39
We do that too. Like sometimes there's a blog post, so you kind of research some topic and then

15:39 - 15:43
I actually don't do this myself, but like our analysts do this quite often.

15:44 - 15:50
They would research some topic, they may fiddle with some technology, and then they just write a blog post. Right.

15:51 - 15:53
Because like that's kind of the best use of the time.

15:54 - 15:57
It's very different from like what I was doing before.

15:57 - 15:59
When you have a like two year old map.

15:59 - 16:04
And you have to deliver and you have to hire people to deliver on this roadmap, you have to

16:04 - 16:09
coach them, train them, you have to manage the projects, you have to fire fight and so on.

16:09 - 16:12
But you're like laser focused on that goal.

16:12 - 16:17
I mean that's obviously one way of doing this.

16:17 - 16:24
When your goal is kind of delivering specific product, your goal is broad work across the whole industry.

16:24 - 16:26
It looks different and different set of challenges.

16:26 - 16:32
The second follow up question is to the portfolio support part, and I'd like to ask you, how

16:32 - 16:36
does your process look like, how often do you check with those companies?

16:36 - 16:38
Is it regular, on a regular basis?

16:38 - 16:40
Basically, how do you approach it? It's very interesting.

16:40 - 16:50
Of course the fund overall has a specific cadence for these interactions, so they maintain all the contacts hot.

16:53 - 16:57
Otherwise it's going to be just some investor update and that's it.

16:59 - 17:04
Myself specifically, it's more of an as needed basis.

17:04 - 17:06
So it's just very informal.

17:06 - 17:15
Like founders and ctos would ping me on telegram sometimes or somebody else in the fund will

17:15 - 17:21
tell me, hey, we talked with this guy and he wants to talk to you. And that happens.

17:21 - 17:25
So it's more on as needed basis for me.

17:26 - 17:29
But it doesn't mean that they are kind of left.

17:29 - 17:35
Like there are people who kind of own all the communication in the fund, they do their job.

17:36 - 17:39
This is all fascinating for me, honestly, based on your experience.

17:39 - 17:47
You've been all over the place, we've been around and what are the key factors you consider

17:47 - 17:52
when managing scalability, especially in high growth tech environments?

17:53 - 18:00
The major challenge is that as the company grows, like at every stage it has to redefine itself.

18:01 - 18:06
It's like the people who were most effective when the company is like five people could be,

18:06 - 18:10
not the people who are effective when it's 50 and when it's 500.

18:10 - 18:15
And I can of course say this from the perspective of the fund like this have to be small, but

18:15 - 18:20
from the previous experience, I don't know, to give a specific example, I joined YouTube when

18:21 - 18:29
it was like under a thousand people and maybe even a few hundred.

18:30 - 18:40
And somehow like it's already a big right, but somehow you could remember people's names, right?

18:40 - 18:47
At least like quite many of them, you would remember, you know, who does what in principle.

18:47 - 18:52
And then as it became like 4000 engineers.

18:52 - 18:57
It's a totally different structure with totally different people and totally different management style.

18:59 - 19:07
I guess this is kind of well known and accepted that things just change when the company grows.

19:10 - 19:20
I don't think I have been in an environment which grew from, I don't know, organically from

19:21 - 19:26
like a handful of people to tens of people or hundreds of people.

19:26 - 19:29
So I've been in organizations of different sizes.

19:29 - 19:33
And have I experienced this growth in one place?

19:33 - 19:35
I don't think I have this experience actually.

19:36 - 19:39
It's always like, yeah, I mean,

19:42 - 19:52
from those hundreds to thousands and Google, or like another, another angle to look at this,

19:54 - 20:03
within Google, YouTube is like a few thousand people and it kind of generates a ton of revenue right now for YouTube.

20:03 - 20:05
And even if when it did not, it was kind of super important.

20:06 - 20:08
It's like Ctubers super Google product.

20:09 - 20:16
And then you move to, let's say Google Cloud, which is tens of thousands of people and you know,

20:17 - 20:22
tons of processes and it was not like generating much, but like it, it's catching up, right?

20:22 - 20:29
So it's a totally different culture, it's the same company, different department. Absolutely, totally different culture.

20:29 - 20:35
Like absolutely, completely like different types of people, different types of interviewing.

20:35 - 20:38
Like by design or by evolution?

20:38 - 20:40
I think by evolution more.

20:40 - 20:45
But at some point at Google they realized that okay, we can make digital products, but do we

20:46 - 20:48
like cloud is about selling to enterprise.

20:48 - 20:51
Can we sell, can we do enterprise sales? Oh no, we cannot.

20:51 - 20:55
So let's kind of, we need a different skill set and that's across the board.

20:55 - 20:59
Like how do you do project management? Totally different style.

20:59 - 21:08
Because when I was a technical program manager at Google, the thing I used to tell on trainings

21:08 - 21:14
for new project management, new technical project managers, is here is a traditional project

21:14 - 21:17
management role elsewhere, and here is how you do it.

21:17 - 21:20
We do it in a very unconventional way.

21:20 - 21:25
Then Google said, you know what, actually for cloud, we want the conventional way.

21:25 - 21:31
We want people who are certified with PMP, for example, right?

21:32 - 21:37
Whereas in all the other functions, you don't want these people because they were perceived as too formal.

21:38 - 21:40
So this is the difference in culture.

21:40 - 21:45
It depends on what the company does and it's the same company, different parts of it. Right.

21:45 - 21:52
And for startups, yeah, I think startups, well, they also go through some stages.

21:53 - 21:55
They have to pivot sometimes.

21:55 - 21:59
And sometimes the growth is also not super successful.

21:59 - 22:06
I have been in a situation where I had to like lay off most of the company, right?

22:06 - 22:11
So I was a peer of engineering of a startup and I had like 33 people under me.

22:11 - 22:16
And one, at one point I had to, you know, my boss comes to me and says, you know, like you can

22:16 - 22:23
leave nine people only and it's like, okay, we have to make these cuts, right?

22:24 - 22:30
And then of course the culture changed immediately at this point, because that's a totally different situation. Right.

22:31 - 22:36
And in that particular scenario I realized, okay, if we're doing those cuts, I'm also not needed, right.

22:36 - 22:45
So probably just go, right, so these things happen also, not when it grows, but when it shrinks.

22:45 - 22:48
And sometimes, and like last year we had to see this as well, right?

22:49 - 22:51
All the job cuts in tech.

22:54 - 23:03
Speaking of that, do you have some kind of rule of thumb or advice how to balance rapid growth

23:03 - 23:07
versus operational stability, reliability of that sort?

23:08 - 23:15
There are trade offs here and companies at different stages with different objectives, maybe

23:15 - 23:21
do different decisions on the scale of rapid growth versus operational stability, reliability.

23:21 - 23:24
And what's your take on this?

23:24 - 23:32
I think that again, it depends whether this is a lifestyle business for somebody which kind

23:32 - 23:39
of generates some revenue and is kind of established, or is it like a bigger company or is it a startup?

23:39 - 23:43
A startup's function is to discover a working business model.

23:43 - 23:49
So it's like, it's by definition in the discovery phase, if it doesn't work, you just need to shut it down. Right.

23:49 - 23:52
So for startups you like this?

23:52 - 23:59
Definitely the bias is towards less operational stability, more discovery.

23:59 - 24:09
Of course you need to, I think in web three this has a specifics though, because when especially

24:09 - 24:15
the project is financialized, right, when it's

24:18 - 24:22
people's money at stake, you cannot afford this.

24:22 - 24:27
Sometimes this puts these projects in a very tricky position.

24:27 - 24:35
Also, when it's infrastructure projects like networks, like mainnets, testnets, but primarily

24:35 - 24:39
mainnets or token launches, you only do it once.

24:40 - 24:46
Like you cannot iterate because startups need to naturally iterate.

24:48 - 24:57
But these projects that launch something with a value attached to it and take public money,

24:58 - 25:05
and then they work towards this event, either a network launch, which is kind of may not be

25:05 - 25:10
even the token launch can be a separate event, but it's still very hard to undo because as people

25:11 - 25:17
start building on this and they start depending on this, but then especially token launch events,

25:18 - 25:22
it's like you only launch token once, right?

25:22 - 25:30
So this is actually quite tricky because you kind of want to iterate, but you cannot.

25:31 - 25:37
Which I think is the reason why we have so many crypto projects that are kind of zombie projects.

25:37 - 25:41
So they cannot die, although they should, but they cannot die.

25:42 - 25:45
And there's some people who are kind of still working on them.

25:47 - 25:55
Another point related to this is that because these projects tend to have this waterfall style

25:55 - 25:59
overall, like, you have to manage them accordingly.

25:59 - 26:05
So because it's water, because it's like a once in a lifetime event, right, one that you, you

26:05 - 26:13
have to plan accordingly, you have to manage risks very well, you have to have scope well defined.

26:14 - 26:17
You have to have like resources assigned.

26:19 - 26:22
You need to be sure that you have those resources.

26:23 - 26:25
Risks is a separate category.

26:25 - 26:34
So across, just project risks, just not making it right, then quality, security, all of those

26:34 - 26:37
dimensions, you really need to flesh them out.

26:37 - 26:43
And that is not consistent, in my opinion.

26:43 - 26:49
It's not very consistent with what agile practices have been advocating for the last 20 years,

26:49 - 26:55
because they're basically advocating that you need to kind of push as soon as you have a product

26:55 - 27:02
that's good enough and then iterate, and then you basically push every day or every week, whatever your cadence is. Right.

27:02 - 27:07
And like, you don't do this with crypto networks, you simply cannot do it.

27:07 - 27:08
Even smart contracts, you cannot do it. Right.

27:08 - 27:16
So smart contracts, software, it's supposed to be, but they are either not upgradable, which is then hardware.

27:17 - 27:20
Developing smart contracts that are not upgradable, it's just hardware.

27:20 - 27:27
Or if they are upgradable, nevertheless, it's an expensive event in the sense of communication.

27:27 - 27:31
You need to know that all your community needs to be updated.

27:31 - 27:34
If there is tooling involved, it also needs to be updated.

27:36 - 27:40
Making a push to smart contracts is a very expensive event as well.

27:41 - 27:43
So this is totally different style.

27:43 - 27:45
Okay, let's talk a little bit more about it.

27:45 - 27:53
So you mentioned that it's generally different in two context versus the launch.

27:54 - 27:55
For example, the token launch event.

27:55 - 27:57
You mentioned waterfall approach versus agile.

27:57 - 28:03
But are there any significant differences besides the ones that we talked about in a second

28:03 - 28:07
between web three and traditional tech environments?

28:08 - 28:19
So I think related to what I said before, security is, and quality has a huge impact in web

28:19 - 28:27
three because again, sometimes people say that web two will move to web three soon.

28:27 - 28:35
And various projects tried to build tooling for more traditional web two programmers to move to web three.

28:35 - 28:44
And I think that there is a big challenge in this because you cannot, let's say like traditional enterprise development. What do they do?

28:44 - 28:51
Well, they would write some, let's say, java code for, you know, microservices and stuff like that, right.

28:51 - 28:53
Or some web apps and so on.

28:53 - 28:56
Can you imagine moving this to web three?

28:57 - 29:02
And the first thing that will happen is like, okay, let's say we found a way to run the Java

29:03 - 29:11
code on web three, but their process is like, okay, we push the software out, that's good enough,

29:11 - 29:14
that has some bugs, but we are ready to fix them.

29:14 - 29:20
And this just doesn't work on web three because the moment you see this code out, somebody will exploit it.

29:21 - 29:27
And because the control is decentralized and sometimes it's not decentralized.

29:27 - 29:31
In many cases in web three projects, they don't start with fully decentralized, which is kind

29:31 - 29:42
of the right approach maybe, but eventually the goal is to have some kind of community ownership or full decentralization.

29:42 - 29:50
And there your level of quality security needs to be so high that the current industry in web

29:50 - 29:52
two is just not used to.

29:52 - 29:59
It's only like mission critical software that's close to that, but we never call it web two. Right.

30:00 - 30:08
Very interesting. On the other hand, I assume that it offers a lot of opportunities compared with some traditional tech.

30:08 - 30:09
And could you explore it for a second?

30:09 - 30:14
What are the opportunities here with this technology and this approach?

30:15 - 30:22
So the opportunity is. Yeah, once you've figured out security and reliability, you actually

30:22 - 30:25
have, like as a platform blockchain.

30:26 - 30:31
What is fascinating for me is that it's kind of an unstoppable computer.

30:31 - 30:42
And when I started my career, at some point I worked at DHL, and what I did there was maintaining

30:42 - 30:45
a software stack that was designed to run on mainframes.

30:45 - 30:52
It ran on emulators in my time already, not on mainframes anymore, but you could see that the

30:52 - 30:58
way it was designed is that the hardware level is supposed to never ever fail, right?

30:58 - 31:07
So these machines that had everything duplicated, multiple cpu's, one cpu dies, the other can

31:07 - 31:10
still work, the seamless disk.

31:10 - 31:16
So a lot of redundancy, pretty expensive hardware overall.

31:17 - 31:24
And we ran it on servers that were kind of very expensive, Hp 9000 architecture at that time.

31:27 - 31:34
And then you look at these kind of big tech startups and Google and they said, you know what, we're not doing that.

31:34 - 31:37
We just assume that hardware always fails.

31:37 - 31:44
Now what that leads to is you have to create this layer of handling these failures and these

31:44 - 31:49
errors, and then you have to create a profession of Sres, of the reliability engineer who kind

31:49 - 31:54
of looks at the graphs of how many errors do we have in each microservice?

31:54 - 31:56
And is the error threshold reached?

31:56 - 31:59
And if it's reached and loaded, we need to do something.

31:59 - 32:02
And it's actually hard to keep this whole thing running.

32:02 - 32:04
That's actually a slight digression.

32:04 - 32:11
I think that AI will not kill us simply because somebody has to keep it running and it's hard. Right.

32:13 - 32:17
So, but back to the point of reliability.

32:17 - 32:24
When you have a blockchain platform running and it's a quality blockchain platform, then it

32:24 - 32:29
looks to you then like absolutely reliable hardware never fails.

32:30 - 32:34
So in your programming model, you just assume it never fails.

32:35 - 32:41
It may fail sometimes because the world is not perfect, right. But we're getting there. Wherever.

32:41 - 32:44
Most popular blockchain platforms, they just run

32:47 - 32:55
super reliably. So you do not have like there is DevOps in crypto, of course, because running nodes and all this.

32:55 - 33:00
But for the smart contract layer, everything that smart contract based. Yeah.

33:00 - 33:04
You don't have anybody who would be looking at alerts.

33:04 - 33:15
How it's running is, is it like how many requests per second is my service getting right or something like that? How many failures?

33:15 - 33:18
Because there are no failures for the network overall.

33:18 - 33:25
Yes, you need to look, but for the system, but for your particular dapp, you just put it out

33:25 - 33:28
and it runs autonomously, lives its own live.

33:28 - 33:35
That's quite fascinating to me, but you have to pay the price of making sure the code is right.

33:38 - 33:48
Well, the other thing is, of course, the openness and kind of opportunity for anybody to build anything.

33:50 - 33:59
Basically the projects that we've seen, I don't know, such as uniswap or something like that,

33:59 - 34:13
or others that somebody can just hook up pretty quickly and the project may grow to amazing

34:13 - 34:17
TVL numbers just simply because

34:20 - 34:27
it's like doing something new and to scale, you don't need to do much. Right.

34:27 - 34:34
Because the scalability is taken care of for you by the underlying blockchain, which is itself

34:34 - 34:36
a problem, like the scalability of blockchains.

34:36 - 34:42
But there are so many people working on scalability of problems that you as Dapp developer don't have to.

34:42 - 34:45
I'd like to talk a little bit about leadership.

34:45 - 34:50
So, Mike, my first question is, how would you describe your leadership philosophy?

34:50 - 34:59
Right. So at some point in my journey, I was like multiple times I had this situation where

35:00 - 35:04
I'm just a technical guy, but who cares about the delivery.

35:04 - 35:12
And because some, some leadership didn't work, I get appointed to kind of, you know, run the

35:12 - 35:15
project further, mostly early in my career.

35:15 - 35:20
And in one of those situations, I,

35:23 - 35:30
well, I led the team to deliver the next milestone and we were so happy that we delivered the

35:30 - 35:36
project on time, or maybe slightly not on time, but that's okay.

35:37 - 35:43
And at some point I realized that I'm super happy that we deliver this, but what makes me much

35:43 - 35:51
more happy, and it was like a new feeling that I see these people who are happy about this delivery

35:51 - 35:55
having happened and I'm more happy for them than for the results.

35:56 - 35:58
And that was like this moment.

35:58 - 36:02
Oh, that's actually a different angle here.

36:02 - 36:06
Caring about these people being happy is actually more important.

36:06 - 36:14
And I must also say that through 20 plus years, I had, of course, many projects and many of

36:14 - 36:15
those projects I don't remember at all.

36:15 - 36:21
Like, I mean, yeah, if you tell, somebody tells me, oh, yeah, I remember we did something like

36:21 - 36:23
that, but I remember all the people.

36:23 - 36:31
You know, a while ago, somebody reached out to me on LinkedIn, and she said, like, you know,

36:31 - 36:37
I'm kind of a person from your team from ten years ago whom you probably don't remember.

36:37 - 36:38
And I'm like, come on.

36:38 - 36:39
Like, of course I remember.

36:39 - 36:41
Well, are you kidding me?

36:41 - 36:47
You know, but I probably don't remember much about the details of what exactly was done. Right.

36:47 - 36:49
But I definitely remember all the people and all my teams.

36:49 - 36:53
Nice. Nice. I think that's a great approach.

36:54 - 36:57
In that topic, I'd like to ask how.

36:57 - 37:05
What are your tactics or strategies for nurturing the culture in an organization?

37:06 - 37:08
Yeah, I think, first of all, it has to come, really from the toll.

37:09 - 37:11
So you need to check who is kind of.

37:11 - 37:17
Is it the founder, CEO, or maybe somebody from the board?

37:17 - 37:23
Like, if they don't set the tone in this culture, it's gonna be an uphill battle.

37:23 - 37:28
You need to be compatible with this organization yourself first. Right. So.

37:29 - 37:33
And at your level, well, set example.

37:33 - 37:41
First of all, you need to kind of live this through, and then there has to be a lot of communication.

37:41 - 37:46
You have to talk about it, because this is not, especially as we work remotely, more and more,

37:46 - 37:53
unless you actually talk about it, it's kind of not obvious. Right.

37:54 - 37:56
And which culture is right?

37:56 - 37:57
Which culture is not right?

37:57 - 38:05
That's a separate question, because different situations lead to different cultures.

38:05 - 38:08
And some are more functional, some are less functional.

38:10 - 38:20
But overall, the changes in culture, especially if you want to make changes, then there is this

38:20 - 38:25
model of unfreeze, then change, then freeze.

38:25 - 38:33
You have to do something that is unconventional, that is disrupting the normal patterns. Right.

38:33 - 38:35
And it might be some reorganization.

38:35 - 38:41
So it might be some events or something that actually disrupts the normal flow.

38:42 - 38:52
And then there is a period of when the new culture is being formed, and it's usually not a simple period.

38:53 - 38:55
It's okay to have some conflicts.

38:55 - 38:57
Like, conflict is healthy, right.

38:57 - 39:03
You can kind of manage, navigate it, and then as things settle the new way, then you try to

39:03 - 39:05
kind of freeze it that way.

39:05 - 39:10
So kind of establish the rules, policies, cadence of communication.

39:12 - 39:17
But also redefine every now and then, once it's growing. Right.

39:17 - 39:18
I mean, in reference to.

39:18 - 39:20
You just said, like, yes, yes, that too.

39:20 - 39:21
That too.

39:21 - 39:27
Combine the two. That would be my takeaway, in a way.

39:27 - 39:35
Like, yes. And it's also kind of sometimes the way I've experienced is this is sometimes, like

39:35 - 39:42
in the small to medium companies, this is defined by the person who drives the change.

39:42 - 39:49
So, for instance, as I came to one Kx, like before me, one of the GPS was managing the technical

39:49 - 39:57
team, and then he handed it over to me and I started doing it in a completely different way. Right?

39:57 - 39:59
And he was like, oh, okay, that's kind of your thing now.

39:59 - 40:03
You do it your way, and that's totally fine. Right.

40:06 - 40:11
So in many cases, the culture is the function of what I was running.

40:11 - 40:13
Thank you very much, Valerie.

40:13 - 40:22
Better tech leadership powered by Brainhub Follow Les Schick on LinkedIn and subscribe to the Better Tech Leadership newsletter.

‍