
CTO Series: The Anti-Scaling Paradox: Why and When a CTO Should Refuse to Grow His Team with Markus Hjort In this BONUS episode, we dive into a fascinating conversation with Markus Hjort, Co-founder and CTO of Bitmagic. With over 20 years of...
Loading summary
Host
Have you ever wondered what it really takes to make Agile work well? At the Global Agile Summit, we're bringing you real life first person stories of Agile succeeding out there in the real world that will inspire you to take action. Whether you're a leader, a product innovator, a developer, you'll hear practical insights from those who've done it. They'll be telling their own stories from the stage. I'll tell you more about this at the end of this episode. So stay back and listen to the full detailed description of what we have in store for you at the Global Agile Summit. But if you can't wait, you can go right now to globalagilesummit.com and check out our full schedule for now onto the episode. But I'll see you at the end of this episode with more details on the Global Agile Summit. Talk to you soon.
Interviewer
Hello everybody. Welcome to one more episode in this CTO series of interviews. With us today, we have Markus Kjort. Hey Markus, welcome to the show.
Markus Kjort
Thank you. Nice to be in here.
Interviewer
So Markus is the co founder and CTO of Bitmagic. Check it out. AI aided game development and has over 20 years of software development expertise starting with Commodore 64 game programming and his career of course spans gaming, fintech and more. As a programmer, consultant, agile coach and leader, Markus has successfully guided numerous tech startups from concept to launch. So Markus, that's a short intro. Tell us a little bit more about yourself and what was that pivotal moment that defined your approach to both leadership and technology.
Markus Kjort
Okay. Actually I think there are like two big things that have happened in my career that kind of still have a really big effect on how I think about technology and leading the technology. So one thing is that like my style of leading people, it's a lot about leading by example. So I still remember it was in beginning of my career, I think it was my first consultant job and I was switching jobs and then we had this kind of farewell party that I was going to leave and then my project manager gave me a speech and he said a lot of like positive things on, on me and said like for but one, one thing was very like important was that he was saying that okay, Marcus was, was really, really had a good attitude that he never complained with very hard tasks and that kind of stuff. And then like I, I was thinking about that like day after that and then week after that and I was thinking was this really a positive thing that like I should I complain more so but then later on in my career I've noticed That as a leader it is actually very important that you as a tech leader you have a certain kind of a positive attitude. So that like nowadays I got a lot of good feedback on this, that like even in very hard situations then when I as a leader say that, okay, now this is very bad situation, but we can handle this, let's just start doing one by one, like one task at a time. So no worries. And that I think helps team a lot. And then if, then about the second thing, of course, if it's just some stupid optimism, so if I'm just happy that okay, everything goes fine without knowing what to do, then I think another thing is the skill of making estimates. And I think Vasco, you are not fan of estimates, but I think the important part as a technology leader is the ballpark estimates. So I think I read this book, Programming Pearls. I think it's from 1980s or something like that where they talked a lot about the thing that a good developer should have this skill on making quick estimates. Not like that, exactly 4.7 hours, but that you understand that, okay, is this task about weeks, months or years? And again, I have a funny story in here from my career. This is also one of the consulting gigs I was working. We were hired in a project that was already really late and we were kind of firefighters that hey, you guys, you have to know to rescue the project. And then I was discussing with the client and client said, we are really in hurry, you have to implement everything right now. And then I just said, hey, let's go to this room and let's go together that what's this all about? And then I think we had one two hour session and he kind of listed everything that he thought that was important in this project. And then I did a quick estimate that okay, I think this is two years time, just like based on the number of the stories or whatever. And then the client was very, he was not happy about that. And he said that you have two months time. And then he left the room and like, okay. But anyway, the funny part is that like then we started doing the project and I think we launched the first version after one year. And after that then we kept on doing updates like two times a month. And then I left the project. So I think I left the project somewhere after one and a half years. But then I kept contact with the people in the project and I learned that they actually had a party four years after the beginning of the project where they kind of had all the features implemented. And I think like as a Learning, like, you can say that my estimate of two years, it was 50% off.
Interviewer
Like, it wasn't actually 100% off.
Markus Kjort
Yeah, yeah, yeah, you're right. Hundred percent off. But on the other hand, like, I think it was a very good that I was able to say to the client that this is years because, like, if it would have implemented in a way that, okay, we have only months, it would have been nightmare. That kind of helped us to create a different kind of a setup and a mood to the project. So I think that was very like it. I don't know if. About pivotal moment. I think the pivotal moment was this when. When my friend called me and said, like four years after it's now finished. I mean, I mean, like those features.
Interviewer
I think this, this is a great story for a couple of reasons. The first one is, of course, it shows how futile it is to rely on estimates, even when you are able to give estimates. But the other thing is kind of this, I think you would call it reality check.
Vasco
Right.
Interviewer
Like, is this days, weeks, months or years? Right. And that kind of reality check is really useful because as you said, it kind of changes the mood and it allows people to make decisions that might be very hard to make if we don't have that kind of. You called it ballpark. I would call it gut feel, or like something very quick and not supposed to inform in detail, but rather to give you where the goalposts are.
Vasco
Right.
Interviewer
Like it's a. If you expect us to deliver the whole thing in two months, you're delusional.
Vasco
Right.
Interviewer
This is two years of work. And then you can say, okay, but we need to release in two months. Fine. That's still fine. Let's figure out what we can release in two months.
Vasco
Right.
Interviewer
And I think that those two aspects are very important.
Markus Kjort
Yep. You're really right on the point. And nowadays when I work, for example, I work usually very. I have very good relationship with the CEO of the company. And we have like. So I think it's very important when, when there are some new, like, opportunities. Right. For example. Right. So that I, as a cto, can give like, okay, the thing that you are now discussing, this is probably weeks, or this is probably months or this is probably years, then we can. It's very easy to say that, okay, let's not do anything that will take years. Let's, you know, let's put it this in the bottom of the backlog in a way.
Interviewer
Of course, I would say to that, like, following up on the whole idea of creating that Ballpark estimate. I would say to that, that in the end what's important is to understand the opportunity. Because we as product developers, you know, not, not just coders, also coders, testers, product owners, product managers. As product developers, we can come up with many different possible solutions for a specific goal. And when it's clear for us what the goal is, then we can contribute that creativity, that imagination that allows us to deliver something in days rather than years.
Vasco
Right.
Interviewer
It's not the whole thing. It's never going to have all the features, but at least it tries to exploit that opportunity that has just come up.
Markus Kjort
Exactly, you're right. For example, if I give this first estimate, then the discussion actually starts. What if we do this differently? What if. And then, you know.
Interviewer
Yeah, yeah. And reaching those goals is very important. And of course, as cto, one of the things that you have to do is to make sure that your tech strategy is aligned with your business goals. And having worked in many startups, and we were talking in prep for this interview about a few examples, of course, it's kind of hard to keep all of those in line, right? Tech strategy on one side, business goals on the other, especially in startups, because business goals are popping up from everywhere. With every new investor, there's more business goals.
Markus Kjort
Exactly.
Interviewer
So Markus, in your own work as cto, how do you make sure that you keep this aligned, the tech strategy and the business goals?
Markus Kjort
I think one of the important things is that I have a constant as a cto, that I have a constant discussion ongoing with all the important stakeholders like CEO, like, and the leadership team and all, so that like nothing should come for me as a surprise so that I kind of understand like, even though if, like, so like lots of informal discussions, I think that's very important for me to have this kind of setup that I, I always know, even though we have a. Features that are not even in any backlog or anything that like I have heard about things, okay, this is something that we think about and this is something we think about. And then that, that I think that's like a very, for me has been very. And, and it also worked already in a consultation so that I understood that who are those stakeholders that are making the decisions that I will keep, Like I go to lunch with them and that kind of stuff so that I kind of understand like where, where things are going and then, then, then, then kind of this, this gives me a picture that we, what kind of features we might end up doing, doing. And then it helps with the technology strategy and Then of course this is a two way road. So I also try to be very open about the technology strategy and trying to of course like not just to other leaders but also like try to openly communicate it to the whole company. And then it's also trying to describe technology strategy not just with the technology words but like what kind of attributes it have. For example that like we are now doing using cloud services this and this because we want to go fast. And our strategy at the moment in like is that we want to go fast because we are startup or then we are like, I know like experience where we kind of in previous company in the beginning we were trying to go fast but then later on at the same some point like the reliability and security were more important things. So there were like, I was like trying to align the tech strategy and trying to communicate that now we are doing these and these things because this makes our platform more secure and reliable.
Interviewer
It's a little bit, if I understand you correctly, what you're describing is we need to keep good contact with the critical stakeholders, both to be aware of what's coming but also to be able to translate the tax strategy so that they can know first they can trust us.
Vasco
Right.
Interviewer
That we are aware of what they're doing and the tech strategies aligned. So that would be the first thing. But also that they know what they might be able to use when it comes to other opportunities that come to them, not to us.
Vasco
Right.
Interviewer
Because in the tech leadership role we are not necessarily having the same exposure to investors. In your case or in the end customers, like business development people are always in contact with customers and if they are aware of the tech strategy, they will be able to give us feedback based on what they discuss with customers. So it becomes kind of a two way street.
Markus Kjort
Yeah, you're right. I think that trust you mentioned trust, that's very important that you are able to create that trust. Then of course this is also like when I'm for example saying that my example here that we are using this cloud service here because of this and this, then for me it's also verification that hey, are we on the same page that we actually want to speed of development? That's the most important thing. And they're like, okay, yeah, people agree that yeah, that's a valid reason for this. And it's kind of also for me verifying when I'm putting this information out, verifying that okay, these are correct reasons for aligning the strategy.
Interviewer
So this is definitely a very interesting perspective. I really like that idea of Keeping up the conversation.
Vasco
Right.
Interviewer
Like a business philosopher. We both know Esko Kilpi here in Finland has been talking about value creation as a constant process of conversation and sense making. And this is very important, right? Like understanding where the business is going by talking to stakeholders, but also sharing the technology perspective by, you know, being able to link those. And that brings us to this crucial topic of tech and business collaboration. And of course you're on the tech side and you try yourself to keep that collaboration going, as you just said through that conversation. But otherwise, when you think about the different teams, right, like tech teams and then business side, how do you keep, you know, what are the key strategies, the practices that you have learned help to create that collaboration even when you're not in the room.
Vasco
Right.
Interviewer
Because ctos can't be aware of everything that is going on and there will be decisions made when we are not in the room.
Markus Kjort
Yeah, that's very important. I think it is not just like CTO's role to make this happen, but I think companies should have this kind of system or setup that people, for example, now we are talking about two different sized BIS and a dev, but that, that of course the company should have sessions where people meet. But I think it's even more important that those people can work together sometimes which kind of bonds them together. For example, let's say in previous company it was very common that we implement that features in this kind of small teams. So that there was typically like certain feature like when the implementation started, the spec wasn't really ready yet. We had always one business representative and then usually two developers or something like that. Or sometimes depending on a feature size, they were working together on making like they had a responsibility of making sure that this will happen and then, then next feature they might be different developers and different business people. And in the end, I think for example, in this example most of the business people had experience on working together with developers and I think this is one example that it's very important and then they trust each other and they kind of align better. So the key here is that like there should be these kind of situations where they work together in some cases. Yeah.
Interviewer
And I really like that working together in order to create both the alignment, which is one of the key aspects, but also the trust which will allow them to work better and faster later on. And I really like that approach. I mean it links up to something we've talked about many times, this focus that came from XP or extreme programming of having the customer in the room, right. Like that Yep. That the customer is not like a, you know, abstract entity that somehow we never have access to, but that the customer representative in this case is actually in the room with us, helping us to figure out the spec and develop the technology together.
Markus Kjort
Yeah, yeah. And like now working in a game development company, we have this kind of daily play test session. Like you don't have to participate, but we play. It's a multiplayer game anyway, so we play, you can join it and then like everybody in a company can join the session. And often in the session we play, but we also like you get feedback and then there are like business and development people there and you can have this very informal discussions and off often after the session, like for example, people can have continue these people and deaf people can continue the discussion that hey, okay, maybe this feature should be improved like this. And this is again creating a way for, I think this is just setting up a stage that there are these possibilities to people to interact so with the real product. I mean, in this case it's very important that we have the latest version that they are always playing together.
Interviewer
So it sounds to me that that particular. You called it playtest session. It sounds to me that that is a very, it's kind of an attractor that brings the people together so business and technology. But also that fosters unpredictable, serendipitous conversations that you would not be able to plan in advance.
Vasco
Right?
Markus Kjort
Yeah, yeah, you're right. And then like this is important for us because we are remote only company so we don't have even office at the moment. So like setting up these kind of virtual meetings where like people can hang out and like it's, it's very important. So but for me, like there's like two points. Like it's a very informal but at the same time like we are like using our own product and then you can have this context that like hey, let's just, you know, as you said, like some discussions just can start from that without any agenda or.
Interviewer
Exactly. And that's very important because of course as humans we are not necessarily structured when it comes to creative work.
Vasco
Right.
Interviewer
We need the opportunity, we need some level of structure like a regular playtest session. But then something needs to happen that triggers our interest and that's what brings up the creativity. Working in startups, I'm sure you have had to scale several engineering teams. What strategies have you employed to manage and nurture your teams through this transition?
Vasco
Right.
Interviewer
Like either growing fast or even sometimes descaling. Right, like regressing fast.
Markus Kjort
Yeah. To Be honest, I don't have experience on this really, really hyper growth scale stuff. But other than that this is a very familiar concept for me and for me I believe in small teams, so very talented teams. So in all of the scaling situations I've always still tried to increase the team size like in slow pace, I mean like that we can handle. And then, then it has been always this balance of, of getting the right people. So get, when, when you try to get the right people in then you have to spend more time on actually checking that the recruiting process which in short term means that it will take time. So I think this is like one thing is that you have to be very strategic on this that if you're going to take more developers it will slow us down for a while. So for me it's very important to pick that. Okay now it's okay to spend this time and sometimes I've even made these kind of decisions that let's not scale now. And just like for example if we have to hit a certain milestone then like thinking about the situation that it doesn't help adding people now we just have to figure out how to hit that milestone without new developers. So I think this is like that you have to really be careful on when to scale and when not to scale. And then another thing I, I think my agile approach this is that like I think there are two different kinds of people and I'm not people but like that you can, you can hire like permanently to their team or then, then you can hire consultants or freelancers. And this is also something that I always think about like if sometimes when you really want scale fast it's like and in a startup if you happen to have some money then just hiring contractors is way faster. You don't have to be so careful on the recruiting process because the deal with the contractors is that like hey, let's have this one month deal and it either works or not. But then with permanent hires I want them to be permanent and be part of my team. So then like it takes more time. So that's, that's like, that's in scaling. I, I think it's very important to, to use both of these kind of options in optimal way. And then at the same time this means like that like I've, I've, I've like it's very common that we have like ended the contracts with the contractors because that's, that's, that's how it goes. Then you can, and you have your.
Interviewer
Own personal experience as a contractor so you know from your past experience that that's part of the job.
Vasco
Right.
Interviewer
Like you get hired, you do a one or two or three or six or even 18 month deal and then it's over and that's fine. And everyone accepts that and it's part of it. And I really like the aspect that you said that sometimes when you really need to scale fast, it's better to start off with contractors first because typically they bring a lot more experience and diversity of experience, which might be important or in gaming they also might bring a lot more specialism in a particular area because the more specialist somebody is, the harder it is to find somebody else with that skill set.
Vasco
Right.
Interviewer
And I think that thinking deliberately about what those options are is really important.
Markus Kjort
Yeah, you're right. I think especially in the game you mentioned these specials we might have sometimes a need for certain, for example, we need certain kind of 3D models, for example. And then when think about, okay, we might not need these regularly but now we maybe need a few more. And then you're like it's, it's about that. It's, it's very. Makes sense to have a contractor for that kind of role. And then for permanent hires I usually look more for this kind of that. They are good generalists. They like that, that because like working in a startup you like, you can't say if you hire a person, you can't say like a year ahead that like what kind of tasks he or she is going to do. Because it's like I, I always say that, that in, in when I'm recruiting or having a discussion that like we can't like promise what kind of tasks that you will end up doing eventually. So.
Interviewer
Absolutely. And that's a great point as well. When you think about your career as a cto, what's the biggest challenge that you faced?
Markus Kjort
I think, of course, I think those are often being like this kind of discussions about having. If you're like usually in startups, startups, the money is one resource that we might not have. So for example, in previous company when we were building our first product and we had to hit a certain milestone, we provided okay. Of course the scope was variable and we were pushing the product forward. But then we were also very tight on the money. And then basically our CEO was able to sell kind of a side project for us. And then we had this discussion that, that the CEO said that hey, this is almost the same as the main product so it probably helps with the tech. And then I was a bit looking at like no, no, Actually, this is not going to help us technically at all. So this is like a totally a side project. And then, but then we just discussed that like the side project was paying so well, so we kind of what to do. And then I kind of made a decision that let's just split the team. So let's, let's just do this side project and then like split the team in a way that both one team, they had a full responsibility of doing the side project as fast as possible and trying to make the client happy. And then the other part, who left to this main product, which was like very important too. Okay, we have a smaller team now and we will continue this and then let's hope that those other people finish soon and then fell back. And I think this was like one of the hardest decisions to think because, you know, like from technical point of view, that was like, if you think about like half of the people went to some side projects, I was like, and we already had a tight schedule. Like, this is very bad. But that's something that you have to get used to in startups that sometimes you have to do this kind of things that don't make sense.
Interviewer
Yes. One would call it Solomonic decision.
Vasco
Right.
Interviewer
Like cut the baby in half. In this case, cut the team in half because you had to bring in money and you had to still deliver on the, on that milestone to continue the startup project. Of course, when you think about, like, I know you guys at bitmagic, you work with AI all the time, right? Like, AI is one of the core aspects. Yeah. So what's your perspective on the rise of AI and how it might affect not only the game that you're developing, but also the way in which you develop that game. Like from your experiences so far, what have you learned about that?
Markus Kjort
Yeah, we were doing this like a bit over two years. And I think one thing is for sure that things are changing fast. That's what I've learned. And I can't even predict all the changes, but it's already affecting a lot. For example, one of the reasons we haven't been expanding the team that much yet is that now when more and more AI is capable of doing more and more stuff, we have to be very careful on maybe thinking that, okay, is this something that, where this area, for example, is this something where the AI will actually be good enough on creating this specific things in specific features? So that's one thing. And then of course it has changed my workload. Like when I'm coding, I use a lot of code. Assistants and I have to be honest that I wouldn't code in the old fashioned way anymore because it has already changed my thinking and especially in this kind of that if you want to be a full stack engineer, it's very hard nowadays because you have to know so many things. But the AI helps a lot. In this case for example, for me I can do more things nowadays because I can like okay, because like okay, I like if I try to do something and ah, I don't know how this kind of technology works and then I can just start discussion with the, with the meta chat GPT and like and it actually proposes hey can you. This is how it usually, this is usually a good practice on doing this and then in a short time I have been able to implement like lots of things that I didn't knew even exist. So yeah, things are changing fast and I think we can't even predict how it will change.
Interviewer
I think the AI question would bring us into a completely different direction in this interview. So I'll stop there because I know that there's a lot more we could explore that especially for someone who's working with AI all the time like you guys at bitmagic are already at this point. One last question before we go to the end of the interview. When you think about your organization, I mean you have a small startup organization and of course that has an impact on what you're going to say next. But what are some of the key performance the KPIs that you always keep in mind as a CTO when you're reflecting on how your organization is developing?
Markus Kjort
Yeah, yeah, yeah. Because of my context I usually don't use a lot of hard metrics. For me one of the, especially when in early stages I think one of the most critical metrics is the like I think it came from the original Agile manifesto already like that the working software is like the most important and for me it's like how often we can release working software to end users. And that I think is the most critical factor that I look and check and then another one is more like it's very hard to quantize but it's this that I try to check the team's like energy and mood level because I think for the performance it's especially in a small startup teams it's crucial that everybody in the team actually have a very like of course sometimes you might. There are days you are not feeling that happy but in general that the team is feeling well and have that positive attitude. I like and they are Enjoying what they do.
Interviewer
How do you do that? Like do you, do you have one on ones? Do you have a regular check in with the team through a tool? Like how do you keep track on the energy level and the mood level of the team?
Markus Kjort
Last company when we had more developers, I had a very scheduled with 101s. That's a very good. And then. But then I think it's part that you have a gut feeling that you discuss with the people. You'll try to listen. Like for example now in our case we have display test session. You can hear when people are talking there and so on. And then you can notice that when you might see that hey, there was something that maybe this person wants to talk about. And then you can propose that hey, hey, what about this? And can we have a short chat about this? So it's more like that. I don't know that I'm always trying to be looking about signals that are the people happy. And sometimes the signals can be just like I'm reviewing. People are pushed comments to GitHub so I can check the comments and like and, and from between the lines I can also see, you know, just commit messages and like, you know, it's, it's not, you know, it's hard to tell. But I think with the experience I actually think that I have a pretty good way of like, you know, noticing that hey, this, there's something in here or then in a positive way that. Okay, now I'm sure that this, this person is really.
Interviewer
This commit messages just reminded me that a very simple use of an AI agent would be to go through the commit messages and do a sentiment analysis. Not to keep track on what people are doing, but rather to give us an early warning signal that might trigger a conversation with people about what's going on.
Vasco
Right?
Markus Kjort
Yeah, actually very good suggestion. Especially when the team size grows. It's not. It really helps if there's kind of an agent which kind of summarizes or tries to find those very signals. Basically.
Host
You'Re totally right and commit are.
Interviewer
A great example of that. And also, for example, code review comments are also a great source of that kind of information because sarcastic or snarky comments in a code review message might be oh, sign that there's something else going on.
Markus Kjort
Yeah, yeah, you're totally right exactly. Those are the examples of those kind of signals. You have to be like take care of, you know.
Interviewer
Absolutely. All right, so we're getting close to the end, Markus. But before we go, when you think about your career as a CTO and some of the most important lessons that you've learned. What was the book that most inspired you as you were developing your own approach to that role?
Markus Kjort
Yeah, I'm again picking, I usually like very old stuff. So I think this is a book that I already read like when I was like junior developer the rapid development by Steve McConnell and I think it was published I guess even before the first X PRIP programming book. So the agile wasn't even a thing then. And the book was about practical tips on how to make reliable software fast. And I think that's like especially one great tip that I still remember was this like it was more like anti pattern like that append and all planning under pressure. And I've seen this so many times in my career that with all the planning and what you have and then when you have a crisis situation, people too often go to a panic mode and start. For example, if your software and servers are down, you might end up in situations that everybody tries to fix things and you're like, and it's just, you can read some postmortems that often the things have failed more because people have made quick fixes. So for example, in those crisis situations, this abandoned planning under pressure, you should keep in mind that it might be good to just pause. Hey, let's pause here and let's figure out who is doing what. And I've been in many situations that let's decide that. Okay, half of the team is continuing with their normal work and we have only this like two person tech team working on this because for this kind of a problem it doesn't help that there are too many people involved. But that's the mental shift that you have to make that hey, that house is on a fire and you just stop there and start thinking, okay, what's what to do? And then you act.
Interviewer
Yeah, that, that's really great because that also speaks to this like natural human thing of wanting to take action immediately when things are on fire, as you said, to use the same metaphor. But actually it many times, especially in projects, what is the most useful is to stop and think deliberately about. Okay, so what do we know? What do we know will work or we think will and what we know will not work.
Vasco
Right.
Interviewer
And stopping the planning is something we know will not work most of the times.
Vasco
Right.
Interviewer
So like this ability to engage what Daniel Kahneman calls System 2 in the thinking fast thinking slow book. I think that's really important because that's when we are at the most attentive, at the most deliberate about taking action to make things better.
Markus Kjort
Yep.
Interviewer
Markus, it's been a pleasure. We're close to the end, but I didn't want to end here before allowing you to tell us where we can find out more about you, about Bitmagic, and of course also about the work that you're doing there.
Markus Kjort
Okay. Yeah, I think the best way to contact me is LinkedIn. I'm not that active in X anymore. And then of course the Bitmagic stuff. Stuff it, it, it is Bitmagic AI. So I recommend you to go there and there's a. Even there should be a link where you can join the playtest. So that's like. And then we have a blog in there too. And of course, if you happen to speak Finnish, like I'm also co hosting a technology podcast, Kodia Pinala, which is like unfortunately only in Finnish. But like, that's, that's one thing that if you want to listen to, we're doing it already quite well.
Host
Very good.
Interviewer
Well, I'm glad that your podcast is also going well. Happy podcasting from me. Markus, it's been a pleasure. Thank you very much for your generosity with your time and your knowledge.
Markus Kjort
Yeah, it was a pleasure.
Host
Hey friend, thank you for staying here. Is all you need to know about the Global Agile Summit. If you've ever suffered or know people who are suffering from agile fatigue, this event is for you. Agile fatigue is that feeling that settles in when we can't really see a light at the end of the tunnel. We get discouraged, especially when conversations revolve around the same old frameworks, the same old buzzwords and theories. We don't feel that energy anymore. Well, the Global Agile Summit is a different kind of event. We're bringing you real life first person stories of Agile succeeding out there in the real world that will inspire you.
Interviewer
To take action and transform the way you work.
Host
The Global Agile Summit will happen In Tallinn, Estonia, May 18th. That's the workshop day. And then 19th and 20th, the conference day. And Tallinn, Estonia is one of the most innovative tech hubs in Europe. The Global Agile Summit is hosted together with Latitude 59, which is kind of a citywide celebration of software startups and groundbreaking ideas. And we'll have a shared ticket for you to attend those events as well. So who will be speaking? Well, we've got an incredible lineup of thought leaders in software and agile. For example, Clinton Keith, the person who.
Interviewer
Wrote, literally wrote the book on game.
Host
Development with Scrum and is busy bringing Agile to the world of game development. You must check his session the very famous and well known Jurgen Apelo, author of Management 3.0, will be talking and exploring about AI's impact on leadership. We also have Goiko Adsic, who's taking an unconventional look at product growth with his Lizard Optimization keynote. Other speakers include, for example Sven Dietz, who's challenging everything we know about software development by ditching, literally ditching contracts and estimates. Can you imagine his teams deliver software before their competitors are even done with the contract negotiation? How agile is that? But there's more. We'll cover engineering practices in our developer track with talks on for example AI assisted test driven development, developing products in minutes with a different approach to how we develop, configure, deploy platforms and much more. We also have a product track where we cover cutting edge ideas around product discovery, delighting customers with product delight frameworks. We'll have a talk about that. And we also have an Agile Business track where we will talk about, for example Open strategy, a very agile approach to to managing organizations and delivering software faster to clients faster than you can.
Interviewer
Even write a contract. Literally.
Host
I mean, I already told you about Svendeet's story is amazing. It definitely is a must see. I'm sure you'll be inspired and get a lot of ideas for your own software projects and software delivery. Now, whether you're a business leader, a product innovator or a developer, you'll definitely find value in our three focused tracks. That's Agile Business for those working with businesses and organizations, Agile Product for product managers, product owners and innovators and Agile Developer for the builders making agile work in practice. The coders, the testers, the designers, the producers, the Scrum masters, you name it. If you join, you will meet over 200 agile professionals from all over the world. People who just like you, want to grow, want to share and want to learn by challenging the ideas that don't work anymore. At the Global Agile Summit, you'll get new connections, fresh ideas and the energy to take your own agile to the next level level. And who knows, maybe even find your next career opportunity. So don't miss out. Check out the full program and grab your ticket now at global agile summit.com I'm really looking forward to seeing you all in Tallinn, Estonia in May. I'll see you there.
Scrum Master Toolbox Podcast: Agile Storytelling from the Trenches Episode Summary: CTO Series – "The Anti-Scaling Paradox: Why and When a CTO Should Refuse to Grow His Team" with Markus Kjort
Host: Vasco Duarte
Guest: Markus Kjort, Co-founder and CTO of Bitmagic
Release Date: April 7, 2025
In this insightful episode of the Scrum Master Toolbox Podcast, host Vasco Duarte engages in a compelling conversation with Markus Kjort, the visionary CTO of Bitmagic, an AI-aided game development company. Drawing from over two decades of diverse experience in software development, gaming, fintech, and leadership, Markus delves into the nuanced challenges and strategies surrounding team scaling within tech startups. This episode, titled "The Anti-Scaling Paradox: Why and When a CTO Should Refuse to Grow His Team," offers invaluable perspectives for CTOs, Agile Coaches, and Scrum Masters navigating the complexities of team dynamics and organizational growth.
Leading by Example and Positive Attitude
Markus begins by reflecting on formative experiences that shaped his leadership style. He recounts an early career moment where his project manager praised his unwavering positive attitude during a farewell party (01:58). Initially questioning whether he should express concerns more openly, Markus eventually realized the profound impact of maintaining optimism as a leader. He emphasizes the importance of fostering a resilient team mindset, especially during challenging phases:
"Even in very hard situations, when I as a leader say that, okay, now this is a very bad situation, but we can handle this, let's just start doing one task at a time... that helps the team a lot." (07:00)
The Reality of Estimates
Markus also highlights the critical skill of making accurate estimates, referencing Steve McConnell's "Programming Pearls" (06:00). He shares a candid story about underestimating a project's timeline, which ultimately led to a more sustainable and realistic development pace:
"If I would have implemented in a way that we have only months, it would have been a nightmare. That helped us create a different kind of setup and a mood to the project." (07:14)
Continuous Stakeholder Engagement
A significant portion of the discussion focuses on the alignment between technology strategy and business objectives. Markus underscores the necessity of maintaining ongoing dialogues with key stakeholders, including CEOs and leadership teams, to ensure that tech initiatives are in sync with broader business aims (11:20). This proactive communication fosters trust and transparency, enabling informed decision-making that aligns development efforts with strategic goals.
"This gives me a picture of what kind of features we might end up doing, and then it helps with the technology strategy." (09:41)
Transparent Communication Across the Organization
Markus advocates for open communication of the tech strategy beyond the leadership level. By articulating the rationale behind technical decisions in non-technical terms, he ensures that the entire organization understands and supports the technology direction:
"We are using these cloud services because we want to go fast... or later shift to focus on reliability and security." (14:17)
Collaborative Team Structures
To bridge the gap between tech and business teams, Markus emphasizes the creation of collaborative environments where developers and business representatives work closely on features. This approach not only enhances alignment but also builds mutual trust and understanding:
"There should be these kinds of situations where they work together in some cases... that helps them trust each other and align better." (19:02)
Playtest Sessions as a Bridge
In his current role at Bitmagic, Markus introduces innovative practices like daily playtest sessions. These sessions serve as informal yet structured opportunities for team members to engage directly with the product, fostering spontaneous and meaningful interactions between business and development personnel:
"We have daily playtest sessions where everyone can join, play, and provide feedback, leading to informal discussions and continuous improvement." (20:47)
Strategic Team Scaling
Addressing the core theme of the episode, Markus discusses his philosophy on team scaling within startups. He advocates for deliberate and strategic growth, emphasizing the importance of maintaining small, highly skilled teams over rapid expansion. Markus highlights the balance between permanent hires and contractors, suggesting that while contractors can offer immediate expertise, permanent team members provide long-term stability and cohesion:
"It's very important to pick that it's okay to spend time on recruiting the right people... sometimes deciding not to scale immediately and instead finding ways to hit milestones without new developers." (22:25)
Balancing Growth with Team Cohesion
Markus shares his experiences of managing team splits during critical projects, illustrating the tough decisions involved in balancing financial necessities with project demands. He describes a pivotal moment where he had to divide his team to undertake a profitable side project without derailing the main product development:
"Splitting the team was one of the hardest decisions because, from a technical point of view, half the team leaving for side projects was detrimental, but it was necessary to secure funding." (30:24)
Adapting to Rapid Technological Changes
Although the conversation briefly touches on AI's influence, Markus underscores the transformative effect of AI on both product development and team operations. He notes how AI tools have augmented his coding capabilities, enabling him to handle more complex tasks and stay abreast of evolving technologies:
"AI assists me tremendously, allowing me to implement features I previously didn't know how to create." (31:01)
Future-Proofing Development Practices
Markus anticipates that AI will continue to reshape development workflows, urging teams to remain adaptable and continuously assess how emerging technologies can enhance their processes and products.
Prioritizing Working Software and Team Well-being
In reflecting on organizational performance, Markus emphasizes the paramount importance of delivering working software frequently as a measure of success, aligning with Agile principles:
"How often we can release working software to end users is the most critical factor." (34:05)
Beyond technical output, he highlights the significance of monitoring the team's energy and morale, recognizing that a motivated and happy team is essential for sustained performance:
"It's very hard to quantify, but the team's energy and mood level are crucial for performance in a small startup environment." (35:27)
Implementing Feedback Mechanisms
Markus discusses practical methods for gauging team sentiment, such as one-on-one meetings, attention to informal signals during playtest sessions, and even leveraging AI for sentiment analysis in commit messages:
"Using an AI agent to perform sentiment analysis on commit messages could provide early warning signals for potential issues." (37:10)
Embracing Deliberate Decision-Making in Crisis
One of the standout lessons Markus shares is the importance of deliberate decision-making during crisis situations. Drawing from "Rapid Development" by Steve McConnell, he advises against reacting impulsively under pressure, advocating instead for structured problem-solving:
"In crisis situations, instead of immediate action, it's better to pause, assess, and decide who does what effectively." (40:46)
Influential Literature
Markus credits "Rapid Development" by Steve McConnell as a pivotal book that influenced his approach to reliable and fast software development, particularly noting its insights on avoiding planning under pressure.
As the episode wraps up, Markus provides listeners with avenues to connect and learn more about his work:
Global Agile Summit Promotion
The episode concludes with a promotion for the Global Agile Summit in Tallinn, Estonia, highlighting an array of speakers and tracks focused on Agile Business, Agile Product, and Agile Developer practices. Markus encourages listeners to attend and engage with over 200 Agile professionals worldwide.
Markus Kjort on Leadership:
"Even in very hard situations, when I as a leader say that, okay, now this is a very bad situation, but we can handle this, let's just start doing one task at a time... that helps the team a lot."
(07:00)
On Estimates and Reality:
"If I would have implemented in a way that we have only months, it would have been a nightmare. That helped us create a different kind of setup and a mood to the project."
(07:14)
On Tech and Business Alignment:
"We are using these cloud services because we want to go fast... or later shift to focus on reliability and security."
(14:17)
On Team Scaling:
"It's very important to pick that it's okay to spend time on recruiting the right people... sometimes deciding not to scale immediately and instead finding ways to hit milestones without new developers."
(22:25)
On Crisis Management:
"In crisis situations, instead of immediate action, it's better to pause, assess, and decide who does what effectively."
(40:46)
Positive Leadership: Maintaining a positive attitude as a tech leader can significantly influence team morale and resilience.
Realistic Estimations: Providing ballpark estimates helps set realistic expectations and fosters honest communication with stakeholders.
Strategic Scaling: Deliberate and measured team growth, balancing permanent hires with contractors, ensures sustainable development and team cohesion.
Collaboration and Trust: Facilitating close collaboration between business and tech teams builds trust and enhances alignment with organizational goals.
AI Integration: Leveraging AI tools can augment development capabilities and streamline complex tasks, but requires continuous adaptation.
Performance Metrics: Focusing on frequent delivery of working software and monitoring team well-being are crucial for sustaining performance in startups.
Crisis Management: Adopting structured decision-making processes during crises can prevent panic-driven mistakes and ensure effective problem resolution.
This episode offers a rich blend of practical insights and strategic perspectives, making it an essential listen for Agile practitioners and technology leaders aiming to navigate the delicate balance between team growth and maintaining a cohesive, high-performing development environment.