Alex Akimov: From Startups to Giants - API Strategies and Organizational Insights

Disclaimer: This transcription of the podcast is AI-generated and may contain errors or inaccuracies.

Matt

My name's Matt, and I will be talking to Alex Akimov about balancing start up and large organization dynamics. Hey, Alex. Good morning. How are you doing?

Alex Akimov

Hello. Hello. I'm very good. How are you?

Matt

I'm doing great. I'm doing great. I'm looking forward to today's discussion. We will talk a lot about the fintechs because you work, at Adyen before, and now we are working on Monite. And I think you are I would call you API Guy, the guy who knows everything about the APIs. Am I correct?

Alex Akimov

Thank you. Thank you very much. I would say, of course, there are many more people who know about APIs much more than I I do, but APIs is one of my expertise, my passion. So, yeah, let's talk about that as well.

Matt

But maybe we can get a step step back before we dig deeper in a technical, matter of the API. You work at Adyen. So this is, I would say, one, of really well known and successful European Fintech companies. And you were there during the transition from 250 people up to 3,000. Right?

Alex Akimov

Yes. Yes. This is correct. I joined Adyen in 2016.

And I think at that time of course, there were a lot of people who already knew Adyen and believed in it, but it wasn't still in the place where it is right now. And it was an amazing journey to see how everything grows, not only, of course, from from the business perspective, but also from the company perspective, from from the culture and processes and the technology. I I I think it was really, really amazing.

Matt

So this is really interesting. So the I I'm building company myself, so I scale it, like, from 3 people to 100. And I remember all the stages that were significant for the company, but this is really small scale. And I assume scaling from 250 up to 3000, there is a lot of things that are changing, and each year, the company is a completely different company. Could you elaborate more on the lessons learned and how this affected the the engineering side on which you were working?

Alex Akimov

Yeah. I I would say, first of all, if we think about the company and Imke and everything, of course, like, number of people, number of products, and, yeah, all the business indicators, it's important, but this is not the Matt goal. So you need to scale only when there is, like when it is super painful not to scale. Right? So this would be the and that's what we observed at Adyen. There was a constant feeling that we need more people because we have so many areas, so many things to tackle, so Matt amazing projects, so many cool customers. And at the same time, we really wanted to make sure that for all the people who join us, we have a very good click.

So we have something that is called, like, company culture. Like, at Adyen, they focus a lot on what they call adding principles, adding formula. You can easily go and look up on the website. But it still a lot of videos from founders and from everybody explaining that. And I think, actually, looking back, this was a key to success for, idea story. Because when you scale that fast and that much, you really need to make sure that you can also scale the mindset. You can scale the approach to solving problems, and you don't have to waste time on different things that would slow you down.

Of course, it's still challenging because Adyen, originally, it's a Dutch company and headquarter here in Amsterdam. But they had, like, more than 20 offices all over the world. And even in Amsterdam, people, I don't know, from more than 80 countries and nationalities. So you you bring all these people from different places, from different backgrounds, like, doing also different things in in the organization, and you're looking for something that are important both, like, for you and for your counterparts and your colleagues. So and this was quite interesting. I would said that we did not do any mistakes. And, obviously, like, when you grow so fast, you want to experiment and try a lot of things.

Adyen always tries to stay lean, and so accurate as a start up. And at some point, for example, that's my personal opinion when I observed when we are several thousand people company, it's not always working when you try to do things as we would do in the start up. But this is also conscious choice. Like, okay. Do you want to spend time on solving this problem for customer, on on setting up this process, or introducing something?

Matt

That's that's all Imke it always interest me, like, because this is the accelerator for a car year. I mean, scale, like, the being while the company was scaling so fast and so big. So you mentioned one of the downside, but do you see some do you have some lessons there, like, what you would do differently in a similar setup, like, in a similar piece of speed of scaling, with the next company, like, when you get, such a possibility?

Alex Akimov

Yeah. That's very interesting Gaus once you're part of this success story, you can always say, okay. Now I know the the perfect recipe. Right? And how how to do everything. And this is partially my story as well because, after 6 years at Tadeum, I decided, okay. Now I joined Monite as a small start up, and we build an API platform, which is perfect.

Something that I like to do. And I have good ideas in mind how to build things, also company wide and technology wise. And at the same time, you're going down, like, several levels deeper in terms of maturity in terms of maturity of the processes of knowledge of everything that you have. And then you see that some things are not, like, working properly, and you should actually, like, do it differently, or you understand why there were some decisions probably that made differently in your people. Again, these are only, like, 22 different experiences that you have. I Imke what's important here is not only to look at your experience and talk to more people. Talk to our people who succeeded.

Talk to our people who fail and learn from them. And that's why I think it's amazing that we have this podcast in general. In the end, there are so many folks that are willing to share, their fund. In in general, if I compare working in a big organization like Adyen right now and a startup like Cognite. I think you need to always understand, like, what's applicable, what's not applicable. And I have a a separate talk about this. If you want, you can look up.

It's about your API strategy to enterprise versus startups. So API did docs, last year, so I can share a little later. But, basically, you identify different patterns, and you see how these patterns fit into your organization and in into, like, the product that you have and and to the people. And sometimes you make choices more about the speed, sometimes more about the quality. Sometimes you focus more on customers. Sometimes you just don't do this, and and you move on because you

Matt

and you have for quite a while in, Netherlands, and I'm always wondering, and that's always it's always interesting from you. You are both foreigners, working pre international environment. And do you see something specific about the Dutch culture that influence the way you work, the engineering works? Have you noticed something like this?

Alex Akimov

Yes. Definitely. I think the Dutch culture, is amazing, for achieving things together.

So it's very cooperative. It is also, I think, called egalitarian when you need to reach consensus on on different topics to move on as a group. And this is perfect, when you have some complex challenges in mind when you don't have, like, a a perfect solution only yourself. So you need to talk to other people before you can come up with something that can be improved. Adiyan is a perfect example of also Dutch culture. One of the principles is that you always shape your ideas with others. So even if you think you are the smartest, if you know everything about APIs, it's always good to have more people in the room to learn their perspectives.

And that's what we did, for example, with API consoles. We started inviting more people, like technical support, implementation managers, account managers, back end developers, other people. Not only just engineering, not only just product, but multiple people. And every time we had the discussion, we were able to improve search engine. Yeah. Dutch people are also known for talking straight. They always claim that they are one of the straightest people on this planet. Probably, yes.

Probably, no for me. I think also coming from Western European background, that's quite okay. Yeah. I I think being straight is helpful, especially when you deal with tech and you don't have time sometimes to figure out how this works. You need to move Matt. So you just say Gaus you see it is, and then you agree or disagree, and we'll bond together. It's more important that you have shared values and shared goals.

You want to help customers. You want to achieve. Matt maybe just some findings, but, obviously, when you live in the country, you find a lot of other circumstances. Matt, also, you find that all the people are different, which is quite normal. My neighbors, like, from one side and from another side, they are very different, and they all die. So then that also means that that's the route we are really.

Matt

And let's talk about the API. So you built APIs for millions of users. So I'm wondering if you could share some lessons learned about it. Like, if there are some come companies on that are scaling, they they are on the enterprise level, and they want to build something for to handle so many users. Like, what are your lessons learned? How how would you approach the building the API?

Alex Akimov

Yes. Thank you for the question. I think there are a lot of playbooks already available on the Internet, how how you build an API, how you expose an API. It in my opinion, it's important first to start with understanding, like, who are the users, who are the audience you are building the CPI for. And is it something you are just building from scratch? For example, if you're a startup or small organization, you never had a public API, and, actually, your whole product is an API Imke in the case of. Right? That's one approach.

Another approach would be if you're working for a big traditional bank, for example, and you never had a public API, but you have thousands of internal APIs, microservices, whatever. And now you need to comply with, I don't know, PSD 2 often banking, Gaus a standards and you also your API or you build an API for partners. These partners will be, you know, only no more than 10 organizations very well known to you with the development team. And if you really know, like, these users who will be connecting to API, You can start with experimenting sharing them with them the documentation examples and adjusting your API only to their specific needs. But when you are building an API for millions of users, that's another story because you will never be able to talk to all of them. You will only, like, make assumptions. And this means that you really need to stay agile.

You really need to understand that you will change your API. You will break it. And this means that you need to have a good contract understanding what's a breaking change, what's not a breaking change, which is also not given in the industry. There are still a lot of different debates with that. You will need to have your API versions. How do you version it? How your customers understand about the version they're using?

Do you release 1 version a year, or do you have, like, 100 versions a year? All of this is sounds quite straightforward, but when you start implementing this, it's quite complex. And at the end of the day, what's still important, and many people, especially in engineering, tend to forget Matt, of course, it's a technical product, and, of course, it's another developer impacting it. But at the end of the day, it's not about JSON versus, I don't know, REST GraphQL. It's not about only how you name this field. It's, of course, about security. It's about performance.

It's about scalability. But at the end of the day, it's about the value that the end users will see with this API. And that's why you really always need to understand how the end product look like, which is not easy.

Why not just an API? So you need to visualize. You need to understand what kind of UIs can be. And this means you need to be in a constant, like, learning process trying to see, okay. These are the examples, talking to customers, talking to somebody who understand it. That's not easy. But if you achieve this, then you achieve a high quality API Imke Stripe, like Adyen, like Twilio, like

Matt

And the biggest mistake that you have seen, that maybe are not slow, obvious. Do you have some, like, biggest mistakes that you see around while people are building the API?

Alex Akimov

I would say, of course, not having API versioning. I I've seen this too, and it's amazing that even the way very big companies established organization, sometimes they just break something or they tell you, okay. In in in 10 days, we will remove this and and you have to adjust your integration. Obviously, there is an alternative strategy evaluation when you don't have version in or you just keep adding stuff, which is also fine, but still it means that you're accumulating internally a lot of technical debt. So you will need to have some strategy to clean up, which is even more complicated sometimes, which is and and then the second biggest mistake, I would say, not, implementing API authentication probably. Because if you look at last top ten security issues, I think Matt of the issues always happened with the blind security. So there is a very good, resource on the Internet API Leszek University where there are free courses and a lot of explanation.

And recently, we also talked to them. According to their data, it's always a problem with authentication. Probably not. There will, of course, other main problems, but it's just and the the third problem is not taking care about your end users. Because API is a technical product, you always care about your current users who are developers, which will great development experience is super important. But if you don't take care of your end users, you will build up to the company they really want.

Matt

You worked in up to your organizations, so you have seen a lot on the engineering perspective. And I recently had a interesting conversation with one of my, guests, and we were talking about the over engineering in Europe versus US while building, building the, you know, the product while working on an engineering side. And we were discussing that, in the US, they are even the engineers are really business driven, so this Gaus, his assumption. And and, I don't know, like, maybe in Europe, we are not so business driven, but we are really good engineers, so we focus so much on engineering. And we sometimes over engineer the things, overthinking the stuff. Have you experienced that in your career?

Alex Akimov

I I think yes. This is partially what I also observed a lot. Of course, now, luckily, with Imke work and everything, the engineering culture is also blending. So either I, like, engineer from, like, world working for small US based companies with different, like, approach to achieving value. I I think this is now also what we can observe more in European companies and also, like, in my organization, I have engineers from Europe, from US, from UK, from different region. So, it it it's all Matt about how you build things also from the product side, how the product, is, requiring your engineer to deliver. Do you have product teams in your organization?

How do you format? How do you work together? How do you involve your engineers, in meetings with customers? And maybe one of the reasons, by the way, can be the language barrier. Because if you're English speaker, you can Alex go and talk to your customers also, Matt likely, English speakers to international. Right? But if you're not comfortable speaking and you're still a very good engineer, you'll find your place in the organization, but you will be, like, blocked from any ability or, like, also yourself, not because somebody works you, but yourself.

You're not feeling comfortable going and talking and trying to figure out, and you focus more Matt technical things. This can be the case as well. Yeah. I and maybe one last example here. Sorry. Now now I remember. If you think about even the policies, international policies created by, like, US or by European Union, if you think about how complex GDPR is or, like, PSD 2 or everything, I think Matt be supposed to part of the, I don't know, natural national character trying to

Matt

achieve consensus. Because when you try to achieve consensus between so many countries and parties, you deal something very complex. And this is just part how you the of the process, how you achieve things. While in the US, it's all about speed, delivery, and value because it's either, like, go big or go home. Right? So it's always about that, and you do everything to to make it faster. Yeah. The the GDPR is a perfect example of comparing the cultures. Right? So I absolutely love it.

It's perfect comparison. And, Alex, I really like to, talk about the tough things and the hard things during the that you have got during your career Gaus, usually, during those times, we learn the most. Right? They are challenging. They are tough, but we have, things that change our approach to to what we do in the in the future, once, once in a lifetime. So I'm just wondering, could you describe me a time when you were a part maybe on of a controversial decision, leadership decision in engineering, department?

What what was it and maybe what you have learned from it?

Alex Akimov

Oh, yeah. Obviously, I I think there were multiple things in my career, that I felt, oh, it's very controversial. And with some of them, I can agree now that some of them, I I would not probably still agree. And, on the people side, quite often, it's about, I don't know, reorganization. Quite often, it's about, like, changing teams and people and their aspirations. Or even worse, it's about abandoning some of the products that your team was working on for a year, even more. So this always hit hard because we are creative people.

We like to do something that that we believe value. And, also, most of us because we are an organization, we get attached to to people we work with. We we like being together, and that's why all the changes, they're usually quite hard. I learned it, hard way, but, also, I understand that it's necessary. And, also, sometimes Matt one for us to even switch organizations to go to another place. I I did almost 2 years ago with Adient, for example. Yeah. Maybe it Gaus not easy, but it's inevitable.

Another thing was which was really controversial is about I don't know. On the technical side, I I can have my numerous examples. For example, do we build a monolith or do we use microservices? Or, like, okay, what do we now get a distributed monolith with a lot of microservices? How do we maintain it? How much we have here. Is Matt a good solution for this size of organization for this module?

Is it not? So this type of architectural decisions Matt also quite hard and also quite hard to recover. And and then, of course, sounds like, okay. We need to implement this functionality right now, like API buffering, but there is no good framework.

But what do we do right now? Do we want to build such a custom and invest in that, or do we want to build something as a worker out and deal with this forever? This is also one of the harder decision we have all made as an engineering group, and, I would say we could do better. I don't want to give any more Gaus of here in general. And this is something that strikes me. And, maybe the last point that I really learned how throughout my career is it is a skill which is often referred Gaus delegation, but I I recently heard a very good definition of that from one of my fellow CTOs who said, okay. You should always optimize for not being present, which basically means that everything that you do and every process you set up and how you empower people, you always optimize for a moment when you're not available for any reasons.

You can go on holidays or it can be another call or you can do and that's what I learned hard way in myself Gaus when you do something and you're good at it, you're always trying to be, like, doing this and you're doing this more and less if people rely on you, and then, obviously, you become a bot

Matt

so I have 2 2 more questions that I wanted to ask you. 1 is because you grew, from a head of API. You were VP of Technology, and now you're a CTO, for, like, a couple of, couple of months. And, it's a new role, and I'm just wondering what are the your current challenges, what are your current things that you are learning, what do you have on your play play this year, you know, to solve?

Alex Akimov

Yeah. I I I think one of the biggest challenges is is similar to what I had before, but it's still quite new because it's a lot about people, and it's a lot more about people than about technology, at least at this point of the organization and at least according to my point of view and my strategy. So where do I find Matt the right talent? Like, because we are remote first, we can hire from everywhere. Who are these people? How do we expand our teams? How do we enable people who are already on board?

How do we help them? And what are the right challenges? Then, of course, the second challenge is that how do we deliver everything for the business? Because when you focus on the tech part, it's already given, okay, we need to achieve them. How do we align business goals where I can have more influence now and the budget and and customer expectation and everything with what my team can deliver and more important, what my team wants to deliver. So this Gaus also kind kind of a challenge. Yeah. And then, of course, all the technical challenges, like scalability, performance, security, what I mentioned.

It's very interesting, when you build a startup and when you build a very big technological Matt platform. But, also, it's amazing when you're only in the very beginning still, so it's not like you cannot change a lot, but, also, every decision is

Matt

And the last question that I have, if you could mention one book that was, really influential on your career as a technical leader, do you recall, like, the title of the of the book that you could recommend?

Alex Akimov

I I think the most fundamental book for me was very early in my career. It was cybernetics from Norbert Wiener. It's a very old book, but I I don't know if anybody is reading this book these days. In general, I think team topologies is is a good one. Matt many people recommend it.

And, also, an elegant puzzle. It's one of the recent ones. I I rep actual I have it somewhere. Yeah. From Will Larson.

From Will Larson.

Matt

Oh, okay. Yeah. It's it's Imke. Awesome. Thank you very much, Alex, for, great talk today. Thank you.

Alex Akimov

Have a good day. Thank you for having me. Bye. Bye.

Matt

Follow Matt on LinkedIn and subscribe to the Better Tech Leadership newsletter.

‍