#527 Building for Tomorrow: Sebastian Gierlinger on Engineering Agility, AI, and the Composable Future

[00:00:00] 

Mehmet: Hello and welcome back to a new of the CT O Show with Mead today. I'm very pleased joining me, Sebastian Gierlinger. Sebastian, thank you very much for, you know, joining the, the show here today. Um, you know, the way I love to do it, as I was explaining to you, [00:01:00] is I keep it to my guest to introduce themselves, but, uh, before this I like to give teaser for, for the audience.

So, Sebastian is the VP of engineering as StoryBlok. And he gonna tell us, you know, some cool stuff about CMS and, uh, some, uh, some other, you know, topics maybe in DevOps and in AI and all what's happening. Uh, so without further ado, Sebastian Delo is you. So tell us more about you and you know, what you're currently doing.

Yeah. 

Sebastian: Well thank you for the invitation. Uh, as you already said, I'm here at StoryBlok, SVP of Engineering, uh, and, uh, most of the technical roles at StoryBlok report to me. So we have a product development, product management, product design. Uh, we have a separate team that deals with, uh, website and developer experience.

And we have an infrastructure team that is also among, uh. My reports, what is StoryBlok Doing? [00:02:00] StoryBlok, uh, is a headless content management system. That means that we only offer the backend services, so the user interface for adding content to the system and API layer. And, uh, the customers, the mo in the most cases, developers are free, uh, to implement front end.

Whatever they like. So, uh, we have, I would say about 80%, uh, websites that are being implemented using our account management system. But there's also, uh, a growing part of special applications like mobile applications, uh, applications. That feeds data into some iot systems. And nowadays, of course, you also have to have to accommodate for AI systems.

So this is also, uh, a growing, uh, sector where we are, where we are feeding content to. So you can imagine classic CMS, but without the [00:03:00] front end. So you can choose whatever you would like. And, uh, we build everything that makes it performant, easy to use and, uh, connected. 

Mehmet: Great. Uh, thank you again, Sebastian, for being here with me today.

The traditional question, you know, like, uh.

When you talk about, you know, kind of this, uh, shift, you know, from, from traditional ways to, uh, to, to modernize, uh, a new concept, what's like the biggest mindset shift? You know, as you know, engineering teams need also to make, uh, for moving from, from legacy to, to, to composable architectures. 

Sebastian: So, um, legacy systems are normally, um.

All the different, uh, things come from the same vendor. You buy it once, uh, you choose a certain technology, and then, uh, everything, um, [00:04:00] works in the same ways over a longer period of time. Uh, when you look more into the composable architecture, into the headless architecture, uh, it becomes, I would say, a little bit more complicated from an architectural perspective because, um, we are following a best of.

Breed approach. And, um, when you, for example, buy a headless CMS system, that also means that you need to find the perfect hosting solution for you. You need to find, uh, the perfect front-end solution for you. You need to find, um. Um, the perfect, uh, shop, uh, solution for you. So it's not everything out of, out of, uh, one, uh, piece anymore.

It's, uh, different systems and you have to run different, uh, vendor processes and, uh, therefore it becomes a little bit more complicated when you assemble everything. On the other hand, you have the great benefit of [00:05:00] getting the best systems. Uh, that you can, uh, find, you are able to choose whatever you would like.

And in my opinion, the biggest, um, the biggest benefit of this composable architecture is you are not locked in on the day when you sign the first contract. So. If there is a new front-end, um, technology that comes out in, for example, two years, um, you are not, you are free to choose this new technology and you are not locked in with the technology that you chose today.

And that's, in my opinion, a really big benefit. And it also makes Windows selection a lot easier. So you can say today, Hey, I'm choosing this headless system because I know that I can adapt to whatever, whatever is going to happen in the next years. 

Mehmet: Uh, great. It's, I, I like the way you, you, you explain in a very, uh, simple, uh, way.

Yet it's important Now, Sebastian StoryBlok, you know, uh, [00:06:00] and you know, this, we hear this term. So as I was researching, uh. It you, it's so-called developer first platform. Yeah. So when we hear the word, you know, developer first, what exactly we mean? Because you know, the, I know, I know the answer of course, but I like to, to, to highlight this from an expert like yourself because, you know, sometime we hear founders.

Or, you know, engineer saying, Hey, like, I, I have this, uh, developer first in mind. And some people get confused, like, uh, are we targeting the developers? Are we targeting, you know, the who, who gonna use the product? So let us like, explain it. Uh, 

Sebastian: I, I think if I give, uh. I don't say, uh, I would say a raving, uh, uh, review of, uh, developer first.

Now, uh, my marketing would be very unhappy with me. Uh, but, uh, but uh, when you use a system like StoryBlok, um, I always say, um. You won't be, [00:07:00] uh, successful without the developer. So, uh, you can sign up for a headless, uh, content management system. You can maybe, uh, click together your first prototype, but as soon as you would like to change something, as soon as you would like to have a custom front end as soon as you would like, uh, to, um.

To make, uh, adaptions to the system, you need a developer for it. And therefore we need to think in a developer first, uh, kind of way where we, uh, try to create a very good developer experience to make it very, uh, easy for developers to work with the system. Afterwards. Uh, of course the system, in our case, uh, the, the admin interface also needs to be, um, easy to use for people who are not day-to-day developers.

For people who are, uh, on the content production side. For people who are on the. Des, [00:08:00] uh, on a, in a design team, um, we try, uh, to build a system that makes developers and, uh, marketers happy and, uh, try to combine, uh, both worlds into one system. So I would not really say that we are completely developer first, but we have a huge emphasis on creating a great developer experience.

Mehmet: Yeah, I, I like that. Uh, honestly, Sebastian, like, you know, it couldn't be explained in a better way. I, I'm, I'm, I'm really glad you, you did it once for all. Um, and, you know, no, I don't think even marketing will be upset with what you said. Absolutely. Um, yeah. It's always 

Sebastian: about the messaging, you know? 

Mehmet: Yeah, exactly.

Well, you know, I, I know where you're coming from, of course. So, Sebastian, in, in your experience, um, you know, um. We hear also something about, you know, an an [00:09:00] engineering, you know, leader who can create unfair advantages, right? So, uh, what is the secret sauce for really having a, a team with unfair advantages?

Uh, especially when, you know, innovating in, in the, in the developer workflows. 

Sebastian: Oh my God, that's complicated. Oh, I didn't have to do that. Uh, so what, what gives us unfair advantages? I think, um, in. Newer days or in the last uh, year, uh, everyone who gets acquainted with AI systems is gaining an unfair advantage.

So, um, I'm, I, I would say I would describe myself as someone who is, um, quite critical when it comes to, uh, AI systems to, uh. Vibe coating to, um, [00:10:00] having code automatically generated and so on. But I absolutely see the benefits of, uh, using these systems to become faster, uh, having more output, um, being less heavy on.

Writing code side and a little bit more on the, let's build a proper architecture, yet let's do proper reviews and so on side. So I think that's, uh, one thing where you can, uh, generate a really unfair advantage when it comes to, when it comes to company and company set up, um, giving your developers. Some time to play around with new developments I think is also a pretty good way of, uh, generating disadvantage.

Um. Trying out new things is not always on the agenda for many companies. And if you give time to to [00:11:00] do that, you will see really, really nice, uh, outcomes. And, uh, yeah, we are doing that, uh, at Storybrook, uh, on a regular basis. And, uh, the, the results are really, really interesting. 

Mehmet: Sebastian, you mentioned vibe coding.

It was very interesting. Yeah. 'cause my, my next question to you was about ai, right? So, mm-hmm. Um, so when, when do you think, you know, um, is the right, right time to, to, to adopt like these new technologies and decide like, okay, I can put it in my engineering workflow, and what are like some of the things which we should avoid also as well?

Um. 

Sebastian: From my experience, what we are seeing right now is, uh, vibe coding is really cool when building the first prototype. So, um, you have an idea, you would like to make it a little bit more tangible. You would like to show it, uh, to the developers who need to product. It, uh, you need to, I don't know, get buy in from, uh, [00:12:00] different, different teams.

Uh, maybe even have already something to show to your product marketing team that they can, uh, later, that they can later that they have easier time, uh, understanding the product or the feature that you're building. I think their wipe coding is, yeah. You can, you can use that today. And there are plenty of systems that will support you and that works.

Uh. Pretty, pretty well. We have also had really good, sorry, you want No, 

Mehmet: no, go ahead to say something. No, no, no. Go ahead. 

Sebastian: We have, we have also seen, uh, pretty good, uh, results, uh, in product development, but you need to be much more careful to not, uh, generate, uh, codes that you don't want to have in the product.

So then generation becomes pretty fast. You need to review, cut down, uh, change what has been generated and so on, uh, to make sure that only things that you really want to have in your product, get into your [00:13:00] product and to make sure that it also stays, uh, stays, uh, maintainable. Because otherwise, I. I would not that confident, uh, with, um, with having a stable product for, for a very long time.

And one thing that we are trying out at the moment, uh, it is also quite interesting, uh, feeding, feeding your, your coat into, uh, into a LLM. Mm-hmm. And then do, um. Bug hunting, uh, with it. So you can, you can, uh, you can feed a bug description into the system and it'll tell you at what point you need to look, uh, to find where, where something goes wrong.

And that's, that's also quite, quite nice and quite interesting, I would say. 

Mehmet: Yeah. And indeed it's interesting, you know, and I, I, I, I, um, my, of course, you can imagine I have a lot of VP GD CTOs [00:14:00] on the show. So, uh, uh, you know, everyone, uh, you know, talks about the first time about the bug hunting. This is a new term.

I think it should be copyrighted. Um, so there is something also because, you know, I, I don't come from that background, like I was techie guy at some point in my career. Mm-hmm. But I always like. You know, like to discuss the, the, the DevOps. Right. And you know, some people, you know, they, when I, they think that I am really into this and they start to tell me few words and jargons, and one of the things that always came is, you know, they say.

Oh, we have like, uh, this complexity creep, and I say, mm-hmm. I understand that. Yeah, yeah, yeah. I understand. Okay. Of course, I, I had to sit with them, you know, understand it one by one. Yeah. Because I have the infrastructure background, so, so I can relate to few things, but what is, what is the complexity creep?

And, you know, like how, how, how do we succeed as, as, uh, engineering leaders in [00:15:00] keeping the architecture both, uh, scalable and agile at the same time. 

Sebastian: Complicated questions. Oh, no, 

Mehmet: not again. 

Sebastian: I, I mean, I, I, I have to, I have to agree. I also, uh, really like, uh, DevOps and, uh, working on infrastructure. It's also the background that I'm, I'm coming from.

So, uh, in, yeah, in my past, I, I, I ran, uh, multiple, multiple, uh. I, I wouldn't say, uh, server farms, but, uh, products that had already, uh, quite some scale. And, um, I think what you say with complexity creep, uh, described very well what happens when, uh, when you would like to scale a system. And, uh, for me, uh, one really great example is, um, going from Docker, which is, uh, one container on one computer, um, to, uh.

[00:16:00] Systems where you want to run, uh, docker or containers on, uh, multiple computers to what Kubernetes is doing today. Kubernetes is a really, uh, great system, but it has become very, very complex to run and also very complex to understand when something's falling over. Mm-hmm. So, um, I am always very hesitant with, um, with using such a complex system for a.

Let's a simple application that only, that only needs. That only needs, I don't know, two or three servers. There is no Kubernetes needed, for example, when you run a huge system that has millions of requests per day, yes, of course it is, uh, it's okay to to use Kubernetes, but uh. Many of our colleagues are using, uh, very complex systems because they can, or because it is, uh, it is mentioned on [00:17:00] podcasts that Kubernetes is, is the, is the great, uh, thing.

Mm-hmm. Um, and, um. And run small workloads on such complex systems. And then yes, there is complexity creep and yes, it is super, super hard, uh, to, to run that. And then you spend more time on fixing your infrastructure, on keeping your infrastructure running, then time you spend on making your product better, and, uh, providing something meaningful to your customers.

Uh, but I have, I have similar, uh, problems with, uh, with development at some, uh, at some. Points because, for example, one recent example is authentication systems, right? So, uh, you have the authentication system you would like to, to authenticate, uh, API requests. You would like to support SSO, you would like to support hardware on use, for example.

And suddenly you have a really, really complex authentication system and [00:18:00] you need to somehow dissect it and yeah, make it work, uh, in ways. Um. That work for your product and that are also, um, in line with what your customers expect. Luckily there are many, uh, companies now, uh, that help with that. Uh, but yeah, it can become quite complex to run that.

Mehmet: Right now I gotta ask you something, which, you know, feel free to give me examples from what you're doing today at StoryBlok. So one thing I hear also from, uh, engineering leaders and, you know, tech leaders in general mm-hmm. Is about. Not only building for today, but building for also tomorrow, right?

Mm-hmm. Um, and make sure that, of course, the agile and all this, and keep, you know, taking the user experience, but how this is done in, in a real case scenario. And of course, like your current role, maybe you can explain like how we make sure that what we are building [00:19:00] for today is also buildable for tomorrow.

Are they gonna still apply for tomorrow? Hmm. 

Sebastian: Uh, that's, that, that's a, that's a topic about balance, I would say. Mm-hmm. So, uh, there are many, many things, uh, that, um, that can be built in ways, uh, that work today and work for today's, uh, workload and for today's requirement, and don't necessarily need. To scale to tomorrow's problems because you don't know if tomorrow's problems will pro, will really, uh, become a reality.

So that's, for example, the case when you, when you build a small application that has a few hundred users and you already, uh, run it on, uh, a huge cluster and uh, you're ready to scale it to a hundred thousand users, but you never get to a hundred thousand users, so. I, I would say be very cautious. Uh, with, with doing that.

The [00:20:00] other topic is, um, having tomorrow in mind when it really matters. So for example, and now we are back to the, back to the headless, uh, CMS world. Um. Leave options open, uh mm-hmm. To, um, make decisions when they are, when they are needed. What I mean with that, what I said before, uh, headless systems allow you to make a decision.

In two years time when there is, for example, a new front-end framework, um, don't, uh, over optimize your APIs already on day one, but maybe have in mind, uh, to run it on. Systems like AWS where you can, uh, add a caching layer in front of it where you have, uh, support in form of, uh, API gateways through route traffic to, [00:21:00] uh, to a different system that maybe is able to process more of the requests, stuff like that.

So I, I would, I would, I would say, when thinking about tomorrow. Then I would, uh, go with, yeah, leave dec decisions open. Leave your path open so that you can, that you can decide, uh, decide tomorrow, next week, or maybe in a year what you, how you would like to solve the problem. 

Mehmet: Great. Now, one of the things that I always ask my guests on the podcast, Sebastian, is to give us like some real world examples, uh, of, of, you know, how they affected, you know, their, their customers.

So any stories you can share, you know, from, you know, the, you know, from, from customer success you had, uh, with, uh, with the StoryBlok. 

Sebastian: Um, we had yesterday a webinar, uh, with, uh, diamond Shipyards. And Diamond shipyards. Is, uh, is, uh, is [00:22:00] uh. Ship construction company that is now over 90 years old. And, um, they were running for a long time on a monolithic system, um, and decided at some point to bring in a partner, a partner agency.

And with this partner agency, they moved to a headless uh, system. So what they did is they completely replaced the monolithic CMS with. StoryBlok, um, a headless search system. Um, I think the front end was at the end hosted on, uh, Asia Cloud. Um, it was implemented using, um, uh. Angular and, uh, and they were, they were using all the new technology that is out there.

And, uh, one of the coolest, uh, findings of all of that was, uh, they not only, uh, spent a lot less on licenses, but they also [00:23:00] saved 75% on hosting costs. And, um, the. Person from the agency mentioned, um, they did not increase the budget because they were not so lucky to get a bigger budget, but they were able to work more on, uh, customer experience on the website, on features because they had the money available from less cost from hosting and less cost from licenses.

And I think this is something that was. In my opinion, a very nice, uh, nice impact that, uh, StoryBlok headless system, uh, had because at the end of the day, uh, diamond Shipyards probably has now, uh, more customers or a better customer experience because they don't spend so much money on legacy systems.

And I think that, love to hear that. That's a good imp impact. Love, 

Mehmet: love, love to hear these stories. You know, I work as a, uh, they used, they still [00:24:00] call them this way, sales engineers or pre-sales consultants. Mm-hmm. You know, a and this is the dream, right? So you go and, uh, of course a sales guy. I work as sales rep also as well.

Mm-hmm. But I mean, still. You know, like the, the dream is to go and be able to present, like, you know, these numbers, like saving money, saving time. Yes. Uh, one of the, I believe underrated, especially, I mean, if it, if they have to deal with, uh, other businesses or consumers, is the user experience. Like, for example.

Uh, like instead of doing a signup form in eight steps, now we can do it in two steps. Right? So, uh, at saving time. I know, but again, so these experience will say, wow, like these guys, they really know what they're doing. So I love hearing these for, if you 

Sebastian: get the signup, uh, flow from eight steps down to two, two steps, I promise you that you will have, I don't know, a lot more customers who really finish to the end.

So that's, that's also very positive business impact Then. Absolutely. 

Mehmet: [00:25:00] Absolutely. Now, uh, do you see AI and automation also shaping the way developers build and manage, like, uh, the content workflows, uh, Sebastian? 

Sebastian: Oh, absolutely. Absolutely. That's, um, I don't know when this, when this, uh, when this podcast is going to air.

Uh, but we have, uh, a lot in this year, first week of October. 

Mehmet: Yeah. 

Sebastian: Perfect. Then we have a lot, uh, of, uh, of topics, uh, lined up on October 14, uh, when our conference is going to happen in Amsterdam. And Nice. Uh, we are going to launch, uh. Topic, uh, products around, uh, that area, uh, around ai, around automation and so on.

So yes, I am convinced that automation and AI will shape, uh, the content, uh, production. Um, uh. Topic a lot, and, uh, we will be at the forefront of these, uh, developments. 

Mehmet: [00:26:00] Cool. Uh, again, you know, I asked VP of engineering, you know, these questions. Uh, so there are two teams, which, well, I was on, you know, on the other side of the table.

Yeah. So I had, I had two favorite teams. You, you, which are not like a pretty much, I would say a customer facing mm-hmm. One is the engineering team and the other one is the product team. Right. So, uh. I used to give them hard, uh, because yeah, I, I'm in the field that I'm, I'm, I'm taking what's, what's there.

But, uh, I, that's, 

Sebastian: that's, that's, that's absolutely fine. Uh, as, uh, solution engineers is more customer facing to give them a hard time because they need to understand what the customer really wants. I know that, uh. Sometimes there's, there's a very, um, how to say that isolated, uh, perception mm-hmm. Of what is needed.

Mm-hmm. And, uh, it's super important to have, uh, solution engineers who, who come back from the field and tell you, Hey, it's great what you're planning, [00:27:00] but no one out there is asking for it. We need something completely different. 

Mehmet: Yeah. And there was a saying among us, like we used to say, like, once you are an se you are always an se, even if you change, you know, so, so for, you can see even till now, I'm, I'm, I'm passionate about that.

Um, yeah. But you know, the, the reason I I came to this is because this puts also developers under pressure, right? Mm-hmm. Uh, and always, especially now, competition is fierce. So we need to deliver faster with fewer resources. How do you. Keep the motivation in the team and, you know, manage this pressure, uh, in a way that it doesn't become like something toxic on your team.

Sebastian: Um, yeah, I think that's a really good question and it's, uh, not always easy to keep everything, uh, positive, especially when you have promised a delivery date and, uh, you are already behind and yeah, it's, it's, it's not always [00:28:00] easy. Uh, we at StoryBlok have adopted, uh, the Shape Up, uh, methodology for, uh, running, uh, our development cycles.

Mm-hmm. Um. That, uh, was introduced by 37 signals and, um, in fact it, uh, it's about, um, working, uh, six weeks, um, on implementation and then a two week cool down period. And in this, uh, six weeks at the beginning, there is, uh, a specification. Uh, that is being, um, that is being, um, shaped, uh, beforehand. And then, uh, the team is, uh.

Evaluating and trying out to implement as much as possible from this specification. So if it, I mean, it can be that the whole, uh, feature is implemented in this, uh, cycle. It can also be that, um, that multiple features are [00:29:00] implemented in the cycle or that, um. That it's only a super part of a feature that can be implemented in the cycle.

And, uh, with that we have a little bit, uh, I would say less stress than with the, uh, traditional, um, scrum, uh, methodology. We have a little bit less meetings. Um. The teams need to be more self organizing, in my opinion, because, um, a six week period managing a six week period is not as easy as managing two or three weeks.

Um, but on the other hand, you have the benefit of the cool down period where you also, um, can, um. Step back, uh, look into bug fixes, maybe finish the security training that you, that you, that you're, that you're supposed to finish. Uh, do a little bit of, uh, e-learning trainings and so on. And, uh, with that we try to, [00:30:00] um, keep the teams.

Stable and not completely overwhelm them with, uh, all the things that are coming in, in terms of bugs, feature requests, uh, customers asking for something. And at the same time, we need to introduce ai, uh, to everyone. 

Mehmet: That's that. That's, that's great. Uh, Sebastian and, you know, um, one, one, um, also question that I always ask our VP of Engineerings, uh. How engineers can develop their skills to, to become leaders in that space. 

Sebastian: Uh, co complicated. I, I would say, uh, everyone should, uh, should be, should be good at their craft.

So, um. Programming is a craft, and you need to be good at that. And then you have different, uh, angles where you, where you can, uh, add, uh, add more. So you can either go, uh, [00:31:00] in the deeper in the. In the area of, um, infrastructure, uh, DevOps and learn more in that area. You can, uh, go more into, uh, management. So getting better at running projects, uh, handling projects, uh.

Petitioning projects into smaller PA pieces and then, uh, and then help the team, uh, executing faster. I think these are the, these are the more, these are the obvious, uh, things that, uh, people can do to become better. I also highly recommend looking from time to time into new stuff. Mm-hmm. So, um, rust. Right now is a really hot topic for, for everyone.

So I, I enjoy, uh, reading about that a lot. And it's super interesting because it's a high performance, uh, uh. Environment, uh, that you can, for example, also [00:32:00] use, uh, for, for infrastructure, uh, implementation. So it's, uh, part of, for Golan. Mm-hmm. So something that, uh, is really fast and can help you, um, serve many requests in a really short amount of time.

So yeah, there are, there are always things to discover and I think everyone who is, who is. Grown up with a technical mindset will find something that is of interest, uh, to look into 

Mehmet: ab. Absolutely. You know, uh, I always tell people, maybe it's not a secret, but whatever you want to become. Uh, especially in our domain, which is the tech space.

You, you need to keep learning and keep eye on, you know, the latest trends. I know it's not easy, you know, sometimes, uh, maybe you would agree with me, Sebastian, like, especially in the past two years or so, uh, every day we have something new. Especially I know cps like, uh, I don't know, like web coding and Yeah.

You know, so, so I know it's hard. [00:33:00] 

Sebastian: It's, it's quite interesting because, uh, we had this joke, I would say five years ago, uh, that there is a new JavaScript, uh, framework every, every other day. Oh, yeah, yeah, yeah. And you need to learn the latest framework and so on. And it was, it was really fast. Paste when you built websites or when you were working on, on web applications.

So you always had to be up to date with the, with the latest and greatest. And I think that has changed a little bit because the, the number of new JavaScript frameworks has, has declined in my opinion. So it's, it's stable now with next Chase. Next Chase. Also the hosting providers are, are quite, uh, settled, I would say.

But now you have this new, uh, challenge of keeping up with all the new terms in ai. So what is an MCP? Do I need to build A MCP to, to be up to date? Can I just plug in somewhere? Uh, and everything, uh, works out of the box and there are seven new companies who are providing [00:34:00] me with MCP services now. So it's yeah, super, super interesting and very fast paced.

Very fast paced. 

Mehmet: Yeah. Interesting. You know, to your point, just you, you reminded me because, uh, uh, at some stage I, you know, I, I, I haven't been a developer, you know, but I was like to, to learn, right? So anything I can put my hands on, uh, yeah, let me try to do it. And one of the things that let me really not like to be in this space is the amount of frameworks that they used to come, uh, especially because everyone was telling me, you should learn JavaScript.

Of course, I know them. Basic things. Yeah. Yeah. You need to use a framework. And then I go to the internet and I look, oh my God, like there are like hundreds and hundreds of these and which one is good? And you know, like, I think this is something in tech. I'm not sure. What's your point of view, Sebastian?

It's a good question that came now to my mind. Um, we see this kind of. And it's, I think it's a human nature, but you know, like, uh, let's say, let's take [00:35:00] JavaScript and I hope I will not get someone angry. Now, you know, as someone 

Sebastian: is definitely offended. No worries. Yeah. 

Mehmet: Uh, because if I, if I do the programming language, that will be more fierce, you know, at least.

But, you know, yeah. Like you should use Angular and someone would tell me, no, you should go and use the View. And I try to understand guys, like, you know, for me as. Of course I understand coding because I learned it at school. Uh, and I do some scripting, you know, for my, uh, service and this in Python and all this.

So I can relate, but why it matters and everyone's saying me, yeah, because they did this, this, and, you know, I said, you're not convincing me, you're just talking too much, uh, jargon. And of course I have people use, but really Sebastian, um, how. To be agnostic, you know, really, especially when you are a leader, I believe this becomes a mandate kind of you to, you know, to keep changing.

And we talk about like building for tomorrow, so how to, to disattach, you know, the, what you call it, [00:36:00] uh, the actual, you know, what I like from what is good for the business or good for the use case that I'm using. 

Sebastian: Uh, that's a excellent question. Thank you. And really hard to answer. Um. I, I think, uh, it's, it's again about, uh.

Balance. So, um, I mean, from my point of view, uh, it's also very complicated because when the team comes to me and says, Hey, we need to, to use this new framework, I need to make sure that this framework is going to stay for a longer period of time. So the, the, the normal reaction is, um, choose something that is well established and already used by.

Big group so that, uh, it'll stay, uh, relevant for a long amount of time so that we are not fighting with outdated, uh, libraries, for example, in, in a year. Or that we have to rewrite the whole product because [00:37:00] we, we, our bet was on the wrong framework. Uh, and that, that's, that's, that's a real topic. So at Storybrook, for example, we have chosen, uh, in the backend, uh, Ruby.

Mm-hmm. Um. I, I'm, I'm quite okay with that, with that choice, that that works quite well for us. And in the front end, uh, we use es, um, because it's not as strict, uh, and allows us, uh, to. Um, to, to build, um, hmm, how to say that? A mo, a modular, uh, front end. Now a hundred people will tell me, Hey, you can do that also with this and this and this.

It is our choice and it was our choice and I'm quite okay with it because, uh, both, um, both technologies are still relevant and I'm not fighting with outdated, uh, libraries. We could have probably also built it with, uh, different tooling and it would also [00:38:00] be, uh, successful. At the end of the day, you need to build features that your customers want to buy, and most of them don't care about underlying technology.

You have, the technology should just not get into your way. So if you need to bend. Your technology, uh, in weird ways, uh, to make something happen. You know that something is probably wrong and you need to, you need to change, uh, technology somewhere. 

Mehmet: Absolutely. I, I like this approach, uh, you know, uh, Sebastian, um, yeah, because again, I relate to, to people I met, I relate to, to myself also as well, by the way, it doesn't, it's not only for choosing the.

Libraries or the language, uh, or even the frameworks, it applies, you know, like even 'cause I was more into the infra space, you know, also people get sometimes like, um, biased by special brands or Yeah. You know, you know how it 

Sebastian: does. It's, it's absolutely fine [00:39:00] when you understand, uh, for example, uh, that using a certain brand for hosting, um, has certain caveats, uh, has right.

Certain, uh, logins that you need to overcome when you would like to change. And everything is fine when it's a big problem when you, when you build on top. Uh. Uh, of services of a certain brand, and then you realize you can't move to a different service anymore because that just doesn't exist there. And then it becomes a little bit problematic, I would say.

Mehmet: And I think this relates to what you mentioned couple of minutes ago about, you know, keep, keep up to date with what's going on because you know you need, when, when you design your systems, like yeah, see what's where, where people are going, how trends might. Shift or, uh, change directions, right? So, uh, it's absolutely something very, very important in my humble, humble opinion.

I'm not, I'm not anywhere expert like you, Sebastian, but I, I mean from logical perspective 

Sebastian: and, uh, [00:40:00] and I'm. I'm repeating the, the outdated libraries, uh, because that's, that's a real topic. So, uh, when you, when you get into a certain size and you need to, for example, have a security certification, uh, for example, we have, uh, ISO 2 7 0 0 1, um, certification.

Um, you need to prove that you, your libraries are up to date, that you have, uh. Process in place that will check on a regular basis that your libraries are updated. And when you find an outdated library, what you do about it. And, uh, these are then the things, uh, that become, uh, really time consuming when you need to, uh, change or rebuild your system because you can't comply with your security framework anymore.

And. There, it, there, it becomes really, really costly when you choose something exotic that seems great today, but is not maintained, uh, in three weeks time. Absolutely. And I'm [00:41:00] exaggerating. 

Mehmet: Absolutely. Uh, well, Sebastian, you know, the time flew and, you know, I could continue this for hours and hours with you.

Really, I'm enjoying the conversation. Um, so as you're coming to an end, any final, you know, maybe. Advice, words you want to share with the audience, and of course, where people can get in touch and know more about you and about story blogs. 

Sebastian: So, yeah, StoryBlok you can find on StoryBlok.com. Uh, you can, uh, send me an email at sg@storyblock.com.

Uh, or connect on LinkedIn and, uh, yeah, other services. Uh, final word. I would say stake curious and, uh, yeah, try out what, uh, what is, what is out there. But, uh, when you're responsible for building, uh. Bigger system that should be, uh, that should be running for a longer period of time. Uh, maybe be a little bit more on the conservative side and don't pick [00:42:00] the new and shiny, uh, but uh, build it in a way, uh, that is sustainable.

Uh, that can also, uh. They can also be used in, in the future. And always leave yourself, uh, the path open to change and to adapt, uh, so that, uh, so that, um, you are not building yourself into a corner. 

Mehmet: Great advice. And again, Sebastian, thank you very, very much. I know as. A, a leader for an engineering, uh, team, how busy it can get.

So thank you for giving me the time today. Uh, appreciate, you know, uh, also all the information you shared with us, especially, you know, the tips and hints you gave, these are like priceless I call them. So thank you for that. Uh, and you know, I tell the audience you can find. Uh, every single link or like reference that Sebastian mentioned in the show notes.

So you don't need to go and look for that. Uh, they will be available in the show notes if you're listening on your favorite podcasting app. If you're watching this on, on YouTube, you'll find them in description. And this is how I end [00:43:00] my episode usually. This is for the audience. If you just discover this podcast by luck, thank you for passing by.

Give me a favor, subscribe and share with your friends and colleagues. And if you're one of the people who keeps coming again and again, thank you for all the support for the feedback. Thank you for making the podcast trending. You know, week after week after week in different countries in the top 200 Apple Podcast chart.

I really appreciate this. Thank you for the, the support also on, on the launch of the book on Amazon, uh, from nowhere to next, which is now available. Uh, I couldn't thank you, uh, enough. And as I say, always stay tuned for any episode very soon. Thank you. Bye-bye.