B (5:39)

Yeah. So how do you think this, this experience with these different sizes influences your approach to the CTO role today?

C (5:49)

Yeah, that's, that's a very good question. That's a very good question because like many, many people, this is a step back where I'm currently in, in terms of how large is the organization and so on. And it reinforced to me that the leadership is contextual, not absolute. What works with 10 people breaks at 50.

B (6:21)

Can you give an example of something that you see is quite different now that you're working with a smaller team?

C (6:29)

The smaller team must be really, You don't need a lot of, you know, like operational overhead. You, you need to be very much straightforward. And what I focus on is, you know, ownership from end to end, making sure really that the ownership is there. You are, you are able then to move fast and the people grow much quicker. The thing is, in bigger orgs there is certain operational overhead, obviously and there are some organizational, maybe also regulation or maybe some power like guard, guardrail guardrails that, that limit what you can allow people to do, what you can let people to do here. Like I trust the people to do even hard tasks.

B (7:46)

Can you, can you give an example of how the processes and the approaches that you have change how they are in a bigger team and how they are in a smaller team? Just pick one that is very Different? I don't know. I'm just speculating here that for example in a much bigger team you might want to have a lot stricter code review guidelines and a lot stricter code review processes than in a smaller team. On the other hand, the risks are the same assuming you're serving the same amount of clients and so on. So like what are the things that you, that you specifically want to change when you go from a bigger team to a smaller team?

C (8:31)

When you go from a bigger team to a smaller team? There is in terms of performance management, for example, I move the ownership for performance management directly towards the people. Yeah. And in bigger teams it might be that the like people, managers or some tech elites are owning it more and like the person that is, you know, being developed, they are like a more passive consumers. So this is in terms of talent development. In terms of the quality we don't, there is no, no, You know, the code reviews everything. The quality overview and measurement of quality and delivery is the same. You don't want to even in startup, of course, but we are fintech, so, so we, we cannot be weaker on quality. So it's, it's very strict. For example, one principle in terms of quality specifically is that we don't have any QAs, any, any people, you know, because that would bring overhead. It means like each dev or engineer, he owns quality for the task, he delivers and he owns also the, the fact that it comes to production, you know, or if not, if there is something he signals that there is an issue. So I will say in general giving more shared responsibility to the people and direct ownership and looking at some certain roles and certain operational principles like quality, DevOps and this, all this goes to people. So we don't have people who do this. And bigger companies, you need to have people that focus on this. And so we create a team. And now the question is, do you make it a silo or is it within a cross functional team? Is that person's capacity shared or it's not? So this would be couple of principles, giving the people ownership, giving more responsibility. But of course you have to set up the system so they don't break it or if they break it, it's safe to break and then they are eager and happy to accept tough challenges.

B (11:38)

So when you think about this kind of transition, like we were just talking about what might be processes that you implement in larger teams but not in smaller teams and vice versa, the transition itself from being a smaller to a larger team is also quite important. So when you think about Scaling engineering teams during periods of rapid growth. What strategies have you used in the past to manage and nurture the team in these specific transitions? Scaling to a larger organization.

C (12:12)

Yeah, when growing and when you grow fast, what's important it's to stay aligned. You know that you don't lose the alignment or if you lose it, you find out early that the alignment is lost and you can recover it. So this is more to like HR processes or HR support. But of course you can do the HR support also like without HR support. But super good, super good onboarding lines, onboarding guides. Then you need to have, you know, the documentation very well done these days. This is very much easier with support of AI where with the documentation, you know, years ago the issue was like to maintain it so it stays up to date. This is much, much easier these days. It's super easy. You just have to make sure you use the right tools. You use the right like second brain for the company and then you're able to support the people body system. That helps a lot. And having a open culture in terms of, you know, like really high visibility on what the company is doing, why is it doing, how is this doing, apologies and where the company is now, where it wants to be in a week, in a month. You know, maybe you're describing a lot

B (14:11)

of practices that have to do with. You called it alignment. Right. Like, but we, we could probably talk about collaboration, communication and so on. And, and one of those that you mentioned was the body system. How have you used in practice the body system to help teams in a growing company? Right. When the engineering department is growing fast.

C (14:36)

Well, the buddy system, it's I guess one of the most easiest things you can do. Of course you need to have people that are engaged and people that they know what they do and they are really well trained in the, in being a buddy. And another lot of companies does use this although it's, it's quite straightforward. And you know, the principle is simple. One body for a newcomer for first one, three, six months. You know, the intensity is, is different how he treats but they often become friends and this is pretty much it, you know, it's nothing more and nothing less. It's to have a dedicated person that makes sure you're on your track, you understand what you are doing and if there are any, you know, issues, you find it out. Okay. The tech lead and the manager can do this also on one on ones but that's formal. You're new in the company, you know,

B (16:01)

you might be and also doesn't Scale very well, right?

C (16:04)

Yeah. And that doesn't scale very well. And so this is, you know, the culture and collaboration aspect. And then, you know, if you grow fast for engineering teams, you have to provide a good platform. That means you have to make sure there is a lot of automation in terms of you scale with the people, you most likely scale with the customers, you most likely scale with failures. You have to make sure that the failures are not critical, that the, I don't know, like incident reporting doesn't kill your people. So when scaling, you have to make sure you're ready in terms of operational quality and observability.

B (17:03)

Observability is definitely a very important topic. I recently published a podcast exactly. On how observability can be used at an organizational level. Because it's not just the technology that needs to be observable, but also the teams and how they are interacting. But you also mentioned AI.

C (17:22)

I don't want to jump too much into the interview flow, but this is super important thing, what you said. And I mean in general you can look at the whole organization much more as a tech system or ecosystem because, you know, the departments are interfaces that communicate. They, they, they have certain like, agreements. So it's like organizational API, you know, like internal organizational APIs, external organizational APIs. There's a GitLab or GitHub, GitBook which has the ambition to describe, you know, how the, the whole company operates for internal purpose primarily. But what I'm saying is that when people start looking at the whole company, not just the engineering part, which is usually technical, and they, you know, utilize some technical principles, but you can utilize these principles also in the other parts of the company. And there might be huge gain if the people understand it, but you have to share the same language to create the understanding.

B (18:49)

Yeah, it's. And I do appreciate your comment there because we do need to have a language to talk about organizations. And what you just said reminds me, and that's a point I make in that podcast episode and I'll link to it in the show, notes that we can use technology as a metaphor for how we organize the organizations that we lead, but without spending too much there, because I'll put the link to the previous episode and people can go and listen to it. I did want to touch on the AI and the rise of AI, specifically in software development and in software development organizations. What's your perspective on that and how it might affect or is already affect affecting software and product development?

C (19:37)

Well, this is a very good question and very relevant. Obviously I run a meetup, a technical meetup in my hometown for developers and AI, you know, is almost within every single meetup occasion. It's somehow there in wage now where I am right now, the like head of technology. We started to go with the AI first organization. We've been inspired by Spotify, you know, and a couple of different companies who started to do this. We looked at principles, how they do that. We try to understand what can work for us and what else is there to introduce so we can leverage it. And it completely changed the way we worked.

B (20:41)

Okay, so before you go into explaining how it changed the way you work today, which we want to go into, tell us, when you talk about an AI first organization, what do you mean specifically?

C (20:57)

Yeah, AI first organization from my perspective is a organization where whatever you are going to do, you think whether the result of your work might be augmented with AI. That means like you either come with the output faster or better. Yeah. So you try to leverage AI tools, whether it's like the generative AI LLMs like cloth or ChatGPT or Gemini or things specifically for engineers like cloth, code, GitHub, co pilot and basically Gemini has the CLI as well. And there is different players but in Figma and the UX people have their tools and add ons, AI add ons within the tools. And this is the same probably for anything for any area in the company as it is for any area within life cycle of software development. So to cut it short, every person does use AI, every person has the capability to use AI. The company builds a second brain so the AI can build on top of that. That means you have to curate the data because you know, shit in, shit out. That that is very much, very much relevant in these days. The contents, the context is important and the people, they have to understand how to work with the tools and what gives them, you know, good output, what not. And they have to use it every day, every day because it's the AI ability is like a muscle, you have to train it. We don't have it because it was not here before, like two years, three years, five years. People who did like automation and certain machine learning stuff, they maybe have been a little bit close to what we have now, but now is accessible for anyone. So one more time, just to repeat, understanding how to use the tools, understanding what the tools are, you know, building the backbone, which is like the data backbone with the right tools and of course like making sure you're not breaking regulations and data privacy, things like this. Yeah, and sharing, Sharing what Works and what does not this specifically in vignow, it really started to, you know, like exponential use of AI in any part of what we do. You know, when people started sharing and they started sharing what works, what doesn't.

B (24:19)

Yeah, absolutely. And that part of sharing is very important. We did a series of interviews about AI assisted coding with 10 different people. And one thing that really came out of those interviews is the realization that we as an industry are still learning. And of course, within companies, we are still learning and it's important to share. And actually this makes me curious of getting you and maybe another person from your team at WAGE now and have a discussion on how you organize around that concept of AI first organization. So let's put that on our agenda, Daniel, and make sure we get back to it. Another topic that I wanted to touch now that we're getting close to the end is of course you've had many years as a tech lead and as a developer and now as a cto. When you look back at your career and specifically from the leadership perspective, what was the biggest challenge that you faced and how did you overcome that?

C (25:24)

Yeah, well, we'll go straight to that right now. Just wanted to ask if I have a couple of thoughts or maybe like, practical, you know, takeaways to the question we just finished. May I share it? It's okay. And then, then I come to this question. Yeah. So just to, You know, underline the thing that the whole organization should use and should get able to leverage AI, this is, I believe, like most people these days, they are looking at engineering teams. Okay. This is obviously the area that can be very much augmented. It is very visible, it is very loud outside. Yeah. But I guess like the, the hidden productivity increases, they lie in the. All the other areas of operations, be it accounting, hr, whatever. So now what I would do and what basically I do in ways now is like I want to hire people that have like digital. Awareness in terms of automation tools and AI. That means like ideally be the HR guy or girl, whatever, or accountant girl or UX guy. I want him to know nadan or make. Com or something like this automation system and then AI. And now when these people know how to use these tools, they can improve their work, streamline their work, and they can help you to build the whole company scalable or like, if they don't know it, they must be eager to learn it. So this is very important. I believe, like the teams and like what we call knowledge economy. It's like all people should be tech people in a way. Back to the challenges.

B (27:51)

Yeah, so thank you for sharing that. So let me just quickly reiterate the question again. So when you think about your career specifically from the perspective of leadership and you growing as a leader, what would you say was the biggest challenge that you had to face and how did you solve it?

C (28:11)

Yeah. So in the ringer Axel Springer I came with the idea or not the idea with the proposal of Agile transformation because the company was at the stage when we've been quite improving in terms of how we operate in engineering. But to make those changes to translate in the whole company, you know, the product and the marketing eventually and the cells eventually had to change how they operate as well. You know, because you can have a. So to say, you can have the best tool, but if you use it wrong, it doesn't work. And in this case the tool is the engineering. Yeah. And the user is the product. So it was, you know, four product verticals that I had to make the people believe and understand what's the agile transformation about, you know, how to change the operation, how to change the collaboration. Also to break the silos in between those lines in between of our engineering and their product because they've been silos. So the people are managed in lines so they keep focus. But you know, once you have the one backlog which is agreed with all the stakeholders, you don't need to worry about that a guy comes to your developer or to your dev team and you know, does a redshift of what they focus on. So this, this was quite big challenge. But I had the support from, from the like a CEO. Of course I had to again like, you know, make him understand what does it mean, what will it bring and how to, how to enable it. You know, what would be the steps, what are the risks? Obviously it didn't work everywhere the same way. Well, you know, somewhere faster, better somewhere.

B (30:50)

So you got, you got kind of buy in from the stakeholders. Yeah, right.

C (30:56)

Like and I had to, I had to buy the buy in.

B (31:01)

So what do you mean by that?

C (31:04)

To get it, you know, it wasn't like I can dire and okay. And so what's the reason why you wanted it? This is a huge thing. You know, you are now going to, to put the things heads up. Yeah. So I had to convince the CEO that such a big operation because it was like it took a year or two years training all the people and everything. Maybe you can do it faster these days, but it really depends on the organization and on the way how old it's in terms of Mindset the company and that's nothing bad. You know, this doesn't, doesn't tell anything about the people. Simply they been learned to operate a certain way and that's it. These days, you know, I would, I would look for people when building a team and not only would I look for people with high agency, what means like they're, they're able to reinvent and change themselves from inside, not only from waiting for a change agent from outside.

B (32:15)

Yeah. And of course that becomes critical when working with a smaller team. But going back to that original challenge, you had different layers of, I guess, obstacles, challenges in terms of bringing people along. First, of course you had to get sponsorship and that's a certain kind of people like the leaders in the organization. And then you needed to get the approach deployed and that means the people doing the work. What were some of the tips that you could share from that experience about getting the buy in from these two different types of stakeholders? Right. Like the people doing the work as well as the people leading the organization.

C (32:59)

Yeah. So this is, you know, this is not that much like technical thing. It's more like a change manager change managerial thing or transformational thing. But in a sense it, it boils down to, you know, what is the, what is the budget or the cost of the engineering? Yeah. How does the work of this money spent translate into, you know, revenues, into business outcomes and how this might change. You know, you either need less people or you ideally produce, you know, more revenue with the same amount of people because they're more relevant, more everything. And then also this is very good for, you know, engagement of people in terms of being loyal to the company. Because with these kind of things you make them grow.

B (34:07)

Okay, so I understand. So you're building kind of a financial argument for the change. Right. Like this will bring this kind of financial benefits. Doing more with the same people would be one. But of course that works with the leaders. Right. But that doesn't work with the people doing the work because that's not going to give them anything. Right?

C (34:31)

Yeah, yeah, yeah. So, so for the leaders and for the, I don't know, like top and mid management, it would be, it would be what you said, the, the financial thing, the cultural thing, which is important and building a better system. Because when you have a better system, you, it's much easier to see inside, you know, and this is very much interesting for everyone also for the people executing the work, you know, because you're creating, you're creating transparency and for people building the work when doing this Kind of transformation. Usually they have more ownership, you know, which is very much, very much motivating for everyone to be a part of a sad change. Yeah. And there are obviously people who don't want the ownership, but maybe you don't want, you know, the people. It's simply not the best fit for, for both sides. So for the people who do the work, I would see, I would say again, like their personal development, having more control, having more ownership, you know, growing and seeing. Making the whole organization more transparent.

B (35:54)

Yeah, absolutely. And you said something at the start of this answer, which is really important. I want to emphasize this idea that as leaders within organizations, we are always acting as change agents as well, not just as the leaders. One last question before we go, Daniel. As a cto, what was the book that most important influenced your approach to that role?

C (36:19)

Yeah, I read a lot of books, but if I would have to pick a book from recent, like five years, it was the site Reliability Engineering Series from Google. It's three books. It's. I don't know the exact names, but if, if you Google like sre Google Books, you will find it. And I guess it's. It's great, the books. I, I did a lot of things they say there, but it helped me to understand the quality as a feature or. Because the quality, it's basically how reliable you are for your customers. Right. And then I would also recommend a lean startup, because what I believe from Edge Grice, because what I believe that all the tech people should have a sense of, you know, business understanding, a sense of customer understanding. I like to put, you know, the engineers very close to the customers be in different ways. We can discuss that maybe on another time. And these books together, the three SRE books and the Lean Startup, they guide you how to balance, you know, rapid experimentation with operational excellence as the organization scales.

B (37:55)

Well, thank you for sharing that, Daniel. It's been a pleasure to have you. Before we go, where can people find out more about you and the work that you're doing?

C (38:03)

Yeah, I would say, like this would be LinkedIn. I'm sharing occasionally there, you know, what I learn, what I do and what I think is important. And then if you are in Slovakia, I run the, I run the web app meetup in Julina and you can find me on, you know, by accident on different conferences in Slovakia, Czech Republic or Austria or maybe somewhere else sometimes where I, you know, speak or I'm a part of panel discussions, you know, from time to time. Couple, couple of times in a. In a year.

B (38:58)

Absolutely. We'll put the link to all of those in the show notes so people can easily find Daniel either in his home grounds of Jelena or anywhere else. Daniel, it's been a pleasure. Thank you very much for sharing all of that with us, for your generosity with your time and your knowledge.

C (39:16)

Oscar, thank you very much. It was a pleasure. And you know the discussion was very inspirational. You're a very good host.

A (39:27)

All right, I hope you liked this episode, but before you hit next episode, here's the deal. This podcast is powered by people like you, the members who wanted more than just inspiration. They wanted real tools and real connection to people who are practicing Agile. Every day we're talking access to over 700 hours of agile Gold, CTO level Strategy talks, Summit keynotes, live workshops, E courses, Deep Dive interviews, books, and if you're into no Estimates, we got the pioneers of no Estimates in those Deep Dive interviews as well. Agile Business Intelligence, creating Product visions, coaching your product owner courses, you name it. You'll get invites to monthly live Q&As with agile pioneers and practitioners, plus a private Slack community which is free of

B (40:27)

all of that AI slop you see everywhere.

A (40:30)

And of course, without the flame wars. It's a community of practitioners that want to learn and thrive together. It's the best place. Connect with community and learn together. So if this podcast has helped you before, imagine what you will get from this podcast membership. So head on over to scrummastertoolbox.org membership and join the community that's shaping the future of Agile. We have so much for you, so check out all the details@scrummastertoolbox.org because listening is great. It's important. But doing it together? That's next level. I'll see you in the community.

B (41:17)

Slack we really hope you liked our show. And if you did, why not rate this podcast on Stitcher or itunes. Share this podcast and let other Scrum masters know about this valuable resource for their work. Remember that sharing is caring.