But a lot of CT OS they usually do not struggle with technical issues. When I struggle otherwise is sometimes holding people accountable, leadership and strategy and vision and also being executive. Most of the CT OS I work with are swamped with work from their day-to-day job. The CEO wants them saying marketing on something, product wants new features, sales wants new features. There has been an incident and too many CT OS, in my opinion, are just reactive and they are
not proactive. They don't build a vision and a strategy, and the leadership strategy helps people make decisions. If a tech strategy does not help people in your department make the right decisions, then the strategy is not useful. A lot of CT OS I meet are not thinking about scaling. And then when there's some money
on your customers, they fail. And the other part, the other type of CTO, they scale by a million times, you know, they have 10 customers, but they build infrastructure that could be used for 100 million customers. Hello everyone, welcome back to another new episode of the Tech Regional Podcast. Today I have with me Stefan Schmidt. So he's the author of this book titled Amazing CTO. This book is actually in the top best selling book in the Lean pub.
So if you want to check it out, go to Lean Pub. So today we'll be talking about what does it take to actually become an amazing CTO, right? So I think the title itself might intrigue some of us. So welcome to the show, Stefan. Hi, Henry, welcome. Happy to be here. Right, Stefan, in the beginning, I always love to invite my guests, maybe to talk more about yourself, right? Sharing any highlights or turning points that you think we
can learn from that? Well above my career started 40 years ago as a kid playing video games. Wanted to write some code, wanted to write some video games, wrote some video games. So that was a turning point getting into all of this. And sometimes later, I'm at my first job in a start up in the 1990s doing Internet stuff, HTML and and web database things. I became the head of development because my boss told me to choose a title for myself.
So I thought, oh, why not become head of development? I would have become ACTO back then, but I didn't know what CTO means. So that was the last opportunity kind of. So yeah, that was the second, I think second turning point. My third turning point of career highlight is I think when I was working for eBay because the start up I worked for was bought by eBay.
And so I worked for some years at eBay as the CTO of eBay subsidiary in Germany and I learned a lot about professional management and engineering management there. So that I think made me a a different manager. I've been on a long journey at that point already and made a lot of changes. But I think the final thing was it eBay to become a good manager, perhaps a very good manager, I don't know, but at least a good manager.
And the last turning point was when my wife sold her startup and I decided to become a CTO coach. So that was the last one I think career wise. And so for some years now, I've been a CTO coach, helping others with the problems that I had on my own. Well, 40 years of career, I think that's pretty long. So I myself probably not half of that, right? So I think we can learn a lot of things from you, right, Being there in the industry and I think it's very interesting.
Many of us actually started our computer science kind of thing from video games, right? I think in your book you also mentioned your story, you know, playing the computer at the computer store or some video game store, right? And then it pick, you know, interest, yeah, yeah, department store and that's what brought you here now becoming ACTO coach. So your subtitle of the book is called the missing manual for managing.
So CTO itself, right? I think depending on which companies or which part of the world may have different responsibilities, right. So maybe in the first set here, let's maybe elaborate, what do you think is the CTO role and how does it differ with, I don't know, CIO and maybe other type of CXO kind of role? I think one of the challenges especially that my clients have is that there is no clear understanding what the CTO role means. And it's can be everything and that's something I tell my
clients. You need to make up essentially what the role means and you need to come up with a definition of what the role means with covering everything that the people in your department need, the CEO needs, the company needs, product needs. And that is essentially defining what the CTO role in this company for this person looks like. And it's very different. My coaches are from I'd say from 5 engineers to 100 engineers and that is a very different, the role is very different.
It's very hands on and I think that's what's also defining for the CTO role, at least where I have some expertise in which is fast growing startup. So I don't have a lot of expertise in large enterprises or something, but in fast growing startups. And what's defines the CT role there is that it changes so much. So you're the might be the first coder, then you you need to hire other coders, then you need to manage them.
You need to become a people manager, tech leader, then you manage other managers, you're a manager of managers, and then you come become ACTO with more strategic focus, enabling business to do their thing and to support business. And this is over this amount of some years, you have a very rapid change in the role. And that's also sometimes where people struggle with. For me personally, I have two defining characteristics of the CTO role and he does not have to
add to anything with the title. The one first characteristic is if you can't bubble up tech problems, then you're the CTO. So if your boss is not interested in tech problems, then you're the CTO. If you're a senior developer and your boss has no clue about tech, essentially you're the CTO. And the other thing is that the CTO is the person or the role or the person standing between
business and tech. So the CTO explains tech to business, and so why is tech working the way they are working, why it takes some time or why this needs to be done, or why developers do some things? And on the other hand, explain business to technology, which means why marketing is doing the things they're doing, why it's a good idea what the CEO is going
to do, and all of that. So you're between business and tech, you're connecting these two parts a foot in each of the parts, and you need to explain the other ones to each other. I like your first definition, right? If you can't bubble up tech kind of issues, problems, right? So you're the CTO. So I think in many of the start-ups we can see it could be the Co founders, right? So the one who handles most of the technology or even IT part,
right, ended up becoming ACTO. So you mentioned in the book it's about the missing manual. I think maybe some of us actually do get it, especially if some of us are the CTO, right? So why do you think you need to come up with this manual for the CTOS? So the menu is from my experience or the book is from my experience and from the experience of my clients.
What they struggle with is they read a lot of tech books and they are usually very good at coding, architecture, processes, all of the technical things because that's what brought them into the position. Like they are probably the best in the group. They might have been promoted or they might have been chosen as a Co founder and stayed on through changes. And their only way to do this is by being excellent in the technology field.
So this is what they can do where they're good at when they come into the CTO role. But then there's a lot of other stuff that they're not good at because perhaps their boss has mentored them or because they're they had trainings. And that is the day-to-day operations like holding people accountable, but having a vision, leadership, laying off people, firing people, promoting people.
So all of these things or how to do proper meetings and all of this stuff that no one talks about, but that's essential to being a good or an excellent CTO or an excellent manager. Yeah. So I think in your book you also mentioned the hard skills get you the position or at least the kind of role. So you know IT better than maybe most of the people in the companies, right? So you become CTO. So I think the hard skills bring you there, but also actually the soft skills that make you
succeed in this role. So I myself personally have assumed like head of engineering, VP of engineering, things like that. And I could definitely relate to what you're saying, right? So nobody gives us a manual, especially in the startups. If you're working in a big corporates, probably you can see so many other peers or mentors that you can actually learn from simply because they have seniority. But in the startups, especially
fast growing one, right? So you probably need to catch up yourself or maybe find other mentors externally. But most of the times it's a luxury to find a good mentors. So I think I get the sense like we need this missing manual. But in your book you have 140 kind of like advice or roles. That seems quite a lot. How did you come up with all these rules actually? So why is the book structured
the way it is structured? I see too many people buying a book, starting the book and then dropping the book and not finishing it. I myself have too many books that I haven't started. So what I wanted to do is have a book that's snackable, that's easy to digest, that you can open, read something and then read a page and then close it again, or read 5 pages and close it again. And you don't feel any regret, any pressure to read the book.
Or you don't get bad feelings because you're not reading the book. So the book should be something that's easy to scan and easy to get into and easy to get out of. And so that was for that reason I chose the format of these 140 rules. So you can read one and then stop, or read two and then stop. So that's how the format came. And then I started with a lot less. But then when writing about it, I thought, well, that's also important. It's also important.
And in the end I dropped some but stayed in the book. Right, So I think I agree, I like reading your book, right? It's very concise bite size, right? You can even like spend just a few seconds to read just one chapter, right? Or one rule, so to speak, right? And I think it's really kind of like insightful and dense. Obviously there will be a lot of details if you want to pursue
much further, right? But I think those rules itself is kind of like useful especially if you want to know some particular the topic, right? So one thing also you mentioned you have become ACTO coach. Maybe throughout your coaching experience if you can maybe summarize what areas typically many CT OS are struggling with. I think what a lot of CT OS struggle with is is there some areas they usually do not struggle with technical issues.
The one thing they might struggle with technical issues is it is not technical by definition. But when they have too much technology, like for some time developers, every developer brings in a framework, every developer brings in some technology. And then after some years you have a a big tech zoo. And then it gets, sometimes it gets difficult to manage the tech zoo because all of these things need to maintained. If you want to hire new developers, they need to know
about the stuff. So it gets hiring, it's more complicated, maintaining, it's more complicated. So this is where a lot of CTOS struggle, especially then if they want to reduce the tech stack to something manageable, they get a lot of resistance from developers. And so that's the most technical thing.
I think where they struggle, where they struggle otherwise is sometimes holding people accountable because a lot of where they come from, from the engineering culture, a lot of things are discussed and then people do the things, you know, And so they are not used to tell people what to do and hold them accountable for the results, like because that's not a thing I think in the engineering culture. So when they become a manager and the CTO, that's sometimes
where they struggle. And I think the third thing where CTO struggle is leadership and strategy and vision and also being executive, which ties I think into the theme. Most of the CT OS I worked with are swamped with work from their day-to-day job. The CEO wants them saying marketing on something, product wants new features, sales wants new features. There has been an incident. So there's a lot of pressure on CT OS. And too many CT OS in my opinion are just reactive.
They react to everything that's happening and they are not proactive. They don't build a vision and a strategy. And the leadership for me, vision is very simple. It's like being as at an office of a company off site hiking and then the vision is having BBQ at the lake in the evening. So that's the vision. Everyone wants to go there. The vision is self-evident. The vision is golden. So that's the vision. And the strategy is how to get there.
Left of the mountain, right of the mountain or at the river. And you as a leader with input from everyone, you choose a strategy to get there. And leadership essentially is then leading people there will often it's talk about leadership. And I think it's very complicated. People make it much more complicated than it is. I think a leader is saying this is where we need to go there and where we need to go to. And I will help you there getting there.
So I think that's leadership. And because in the engineering culture, people are more accustomed to deciding by merit or by facts and then executing on this agreed upon decision, I think they struggle when becoming a leader, becoming ACTO, to say, OK, this is my vision, this is my strategy with input from everyone and this is where we go to. Right. I like the trifecta that you
just mentioned, right? The vision, the strategy, and also the leadership, especially if you're a young CTO, right? Definitely you are not exposed to all these problems, right? So you definitely have to learn by doing. Maybe again, finding a coach, right, like yourself. But I think setting a vision and setting strategy and leading people is not something that is easy, right? Especially if you have so many things like you mentioned, right? So many things to take care of.
So incidents, for example, or even sometimes like a big hiring, promoting. And when you grow fast, right? You seem to have plenty of things. I think the struggle is real. So in the 1st place, maybe we can learn from you yourself in your career as ACTO before back then, right? Is there any kind of like failure story that you think is very, very good for us to learn from? And maybe if you can share that personal anecdote, that will be great.
Yeah, I had several failures. One failure essentially was at the company when there was a lot of pressure to deliver some feature. It was labeled as the company saving feature. It was very important for the strategy of the company. So there was a lot of pressure put on me. I was not the CTO, but I was an engineering leader responsible for one area of the company essentially. And a lot of pressure was put on on me and the team. And my mistake obviously was not
giving enough push back. I should have given much more push back to that pressure. I didn't. So team was sitting around at night writing code and I thought, well, I could do something too. Like I want to help. I'm not just sitting here at 11:00 PM, I want to do something too. And so someone suggested, OK, you can write some JavaScript code here to see senior developer thought, well, if we have some simple JavaScript, Stefan will not screw up. And well, what happened is I screwed up.
I wrote some JavaScript code which after release brought the website down. And it was a large website, lot of customers. And I brought the website down because on one hand I might have been the best programmer in the room, the most experienced at least. But on the other hand, I didn't know about the all the intricate details of the domain and the side effects and what you need to be be aware of. So I wasn't aware of some subtleties of the custom web framework and that brought
essentially the website down. So I think just because you're the most experienced developer does not mean you should write code as ACTO. And if you fall below some percentage of your time, like let's say if you fall below 50% of your time coding, you will miss too many things that are going on in the code, even if when you're the most experienced one in the context of the company and the features, you're
not a very good coder. So if you're actoi encourage you to code, but more of the harder problems, spikes, prototype research, things that you might want to pitch to the CEO more that kind of stuff, then day-to-day deep in the woods feature stuff. So that was my one of my failures. Thanks for sharing that. I think coming from the engineering background, right, sometimes we feel itchy, you know, like we want to code, especially if you dealt a lot with people problems, right?
Sometimes it gets really stressful. So you just want to work with the code. But sometimes it's not wise to actually work on like features, right? Deliver features, just like what you mentioned. Maybe you missed the context, maybe you cannot keep up with the pace or sometimes you become a bottleneck simply because maybe you have too many meetings and other things to take care about.
So yeah, so I think scoping it down to like what you say, maybe a spike or maybe POC, the research will be something that is more relevant and useful so that you can give guidance to people. So coding definitely is 1 aspect, right? So there could be other plenty of areas that you need to think of. You just mentioned just now like efficient strategy, leadership. I also think that you can, you should also think about the people, definitely the execution, right?
Maybe also thinking about the external branding, right? And also yourself. So we'll try to cover all these various different aspects, not to mention also the process that you need to set up, right? So maybe if we can start the first thing about strategy. I think you mentioned about strategy. Sometimes when you're dealing with too many things, you seem to lose focus and do not have a clear strategy. And you mentioned in your book that strategy is actually for the people.
So tell us why we should think strategy in that particular perspective? Strategy helps people make decisions. So from my former example of the hiking and the strategy is to go left of the mountain. What can people make from that? So that's a strategy. Someone comes to a fork in the road, right or left because we want to go left of the mountain. The person goes left. The person will also bring with them some hiking shoes because it's a hike and because it's going into the mountains.
So what does it mean for your day-to-day job? The strategy helps people make decisions whatever they decide about a feature or should we do this or should we do that? They should be able to look at the strategy and the strategy helps them make a decision, a right decision that fits with the future of the company explained in the strategy. And if the strategy does not help.
On the other hand, if a tech strategy does not help people in your department make the right decisions, then the strategy is not It's useful. The strategy is not for you. The strategy is for everyone else to support them in their decisions, essentially. Yeah. So I find what you mentioned just now, right, strategy is to help people make decision, right?
Because I think in technology, especially with the current rapid pace, there are simply too many alternatives that you can choose to actually execute something, right? And also not to mention there are so many tech stack programming language or maybe even cloud providers and things like that. So definitely we can't leave it
up to people to decide, right? And hence probably the the the CEO will decide for the business, but for the tech, maybe the CTO will be the one who set up the strategy. So setting up the direction, right? So how to help people making decision is one thing, but you also say that we need to set up people for success. So how can ACTO do that to set up people for success?
I have quite some code, had some coaches in the past that hired persons for a role and then after some time came to me and said, oh, I hired the person, but that's a failure. I need to let the person go. And we talked about that and I said, well, from my perspective, the person is not a failure. You made a mistake. And the mistake you made is you didn't set up the person for success, but you set up the
person for failure. And I think that's a very important concept of if you delegate something or you hire someone, or you give a project to someone, or you make someone responsible for something, then you need to make sure that the person will be successful. So instead of doing the minimal work to get the person started on your side, you should do the maximum of work that you can do to support the person.
It's often the case that perhaps you have a project, you don't have enough time, you're under time pressure, you give this project to someone and you're happy that you don't need to work on it anymore because you don't have time. So you also do not invest in the person and you set up the person to fail because setting up them for success takes time and that's something people don't do because they don't have time.
But you need to really take your time to make a person successful and think what does a person need? Do I need to person connect to other person? Do I need to give the person a budget? What can I do to make that person successful when hiring someone? For example, people often make the mistake when they hire someone for security. They hire a hacker. That happened several times and then the challenge. But the challenge is not for the person. It's not to find the security
problems in your code. The challenge is to convince all the other developers to follow security guidelines or to follow a security model, or to write good code, or to do security check UPS during code reviews. That's the hard part. And for that, you need to be a good manager to convince them. And if you're just a good hacker, you might not be able that. Obviously very good managers are
there also very good hackers. But there's a probability that if you're just a good hacker, then you can't convince the people. So you as a boss, as a CTO, hiring this person and setting them up for failure because you hired them with a skill set that will not make them succeed in that job, and then it's your mistake. It isn't a mistake of the person you hired. I think it typically happens a lot, right?
So when you hire people, you think that you have set the bar high or maybe you have seen this person can do a certain skills, right? But then don't forget the context when they join your company, right? Your company is probably one-of-a-kind with all this culture, the set of people and process inside. And sometimes we just think that they can be independent and solve the things by themselves. So you mentioned in your book you advocate a lot about one on ones.
So probably this is one area where we can give support and set up the person for success, right? So tell us why one-on-one is actually very important important as ACTO role? I think one on ones are one of the most important things, perhaps the most important thing overall, for me at least as a manager, I use one on ones for many things. The main focus of one on ones for me is people development. How can I support my direct report? Where do they want to go?
How do they want to develop? What do they want to do in the future and how can I support them doing this? How can I grow them or how can I help them grow? How can I support them grow? That's the most important thing. And if you do this and everyone in your department does this, then that's the biggest level you have because everyone in the department will become better and better and everything will
get easier and easier. Because if you have 50 people and everyone is developed at the same time by their manager or help to develop themselves by their manager, that that's the biggest lever I think that you have. So that's important. It's also important if you do people develop people that people can see themselves in the future in the company. If they can see themselves in a year in the company, then they will stay. And if they can't see themselves in a year in the company, they
will leave. So this is part of my one-on-one. What I don't do in one-on-one is status updates only if the person really wants to do this, but usually no, they can send me an e-mail and it's best. I don't know about status because everything should work and if something fails and I can help, yeah, send me an e-mail. But I don't need a status every week. This is fine, this is fine. I'm doing this, I'm doing this, I'm doing this. I don't need to watch people
working. I assume they're doing their best. They don't need to tell me every week to do their best. So a big anti pattern is status in one-on-one and the other half of the one-on-one is my half. And I use it to align people. I explain what's going on, why this is relevant, why this makes sense. Like in the last 50,000 years in human history, there was always some people who explained the world to explain why the sun is rising and the moon is going down.
And then people said, Oh yeah, that makes sense. So I'm no longer frightened because the sun is going up because of the sun goddess or whatever is behind is an explanation for the sun rising and the moon going down. And that's also something I think that's important for today for a manager to do to explain the world. So in one on once I explained the world why, what's the vision of the CEO means for tech, what this new customer means and all
of these things. And lastly, in one on ones, I also prepare decisions and discuss decisions after they have been announced. So if I want to do something or this, I know the CEO wants to do something. I talked to the person, the one-on-one say the CEO wants to do, go to a new market. What are you thinking about this? And then people tell me what
they are thinking about. It's a good idea, it's a bad idea, but people are not surprised when two weeks later the CEO announces this in an old hand. If it can be talked about before, sometimes you can't talk about things before. But if you're allowed to talk things, then I talk about these things before and after. The CEO explained to everyone, we're going to a new market. And when, when I ask people, so you heard the CEO, does this make sense to you? This is a good idea.
And then say, no, I didn't understand what he said. And then then explain why it's happening. So for alignment and for making sense and giving context and all of these things, I think it's very, very important. And this also last point ties into my idea of automatic management. What do I mean with automatic management? Automatic management is management where I don't have to do anything As a manager. If I explain things to people, they make the right decisions.
So I don't need to make the decisions or they don't need. If they come to me, for example, and say, Stephan, what would you do? The first thing I asked them, yeah, what would you do? I try to always empower people and give ownership and explaining things in the one-on-one does this, as does the strategy and division. Strategy and division is also automatic management. People make the right decisions on their own. I don't need to make them or help them with their decision.
And the last thing is culture, for example is also. I consider also automatic management. Yeah. So I like the automatic management, right? Definitely if you can let people be independent as much as possible, definitely that that will be great. But that also relies a lot with your strategy, right, to help people make decision, maybe setting up the right culture as well. And also maybe encourage people to take responsibility, right? So you mentioned it's one chapter of the book as well.
Encourage people to take responsibility. Not everything has to go through you, right? So enhance the automatic management. And I think you also advocate a lot about delegating stuff, right? In fact, delegate everything you mentioned in your book, delegate everything and also trust your people. Why is it so important to
delegate everything for a CTO? Because I think most of the CT OS, especially the one who comes from a very strong technical background, they want to have a say in many, many things, especially if it's a tech decision, right? So why we need to delegate more? So the first thing why to delegate more is just a practical thing. All the Ctos I meet have not enough time and from those I meet are working in growing startups.
So they have some set of responsibility and then the company grows and the responsibilities they have are also growing to a point that it's just too much. Like it might be possible with 10 people, but it's no longer possible with 20 people. So you need to start delegating things that could be your job when the company was small, but can no longer be your job when the company grows. And at that point, a lot of CTOS struggle because they do not
delegate early enough. And then they end up with a calendar that's totally full. They are totally reactive. They can't do the things they want to do. So from a very practical point of view, you should delegate everything that you can delegate and it make just a conscious decision, say, OK, this is something I can't delegate, but everything else is up for delegation. And then there's also the point that you mentioned that was me 20 years ago. So I thought, well, I need to
make the technical decisions. You know, I'm the most experienced developer in the room, so I need to make the decisions. But after some years, looking back at these decisions, I thought they were not as great as I thought they would be. They were not bad. So most of my decisions were good. I made some bad ones, but most of them are good. But I thought someone else could make them too.
And so I changed myself. I pushed technical decisions to people who are very competent and could make decisions on their own. And I no longer became a bottleneck. And also people owned those decisions like they owned the architecture decision. It's not something that Stephen says. It's not something you do this and then people don't own it, but they make a decision that they own the decision down the
road. It's makes things a lot easier if people own the stuff or own the decisions they're making instead of me making decisions. So I find that delegation probably is also an art, right? Especially there's so many different variables, like for example, you delegate something to a person, right? Whether that person also has the skill set, that's the best thing, skill set and experience and they want to take responsibility to actually own
the thing. The other thing is, of course, when you are small startup, maybe there are only a few people, right? As you grow and grow more responsibility, you also need to hire fast, right? So hiring also takes a different set of challenge and also hiring will take some time for the new people to get themselves on boarded, right? Is there any trick from you? How can we actually delegate better, right?
You can't just, for example, a new person joined, you just delegate everything to the person. Is there a way, maybe some kind of strategy, for you to actually delegate smoothly so that people can also succeed with the task that you're given to them? So everything I said about setting up a success applies here and I think there are some mistakes that people make when delegating. So I think a lot of success in delegation is by not making a mistakes. And one mistake is that people
delegate the wrong level. Like if the person is senior, you should delegate goals and numbers, When the person is not so senior, you delegate projects or features. And if the person is even less experienced, you're delegating tasks. And my mistake was I wanted to be delegated by goals or something like Stefan Solstice code coverage or quality or, you know, so I wanted to be managed by goals. And then this is how I managed people in the past and like 20 years ago.
That's how I delegated things. But like, if a person very junior, you need to tell the person do this, then do this, then do that and come to me like every day. But if the person senior, that's also a mistake. They're telling people where some very senior do this, then do that and then do this again. They get annoyed by you being to
be being a micromanager. So you need to delegate according not how you want to be managed, but how about the person needs to be managed and have the right level of what you're delegating to the person and to the experience in seniority level. I think that's very important. And the other thing, the biggest mistake I think is in delegation is I would have found it differently. So you delegate something, someone comes back and you say I would have done it differently and therefore it's bad.
You need to really judge what people are doing. If you delegate something, you need to judge what they have been the result of the work by the success criteria and that not by the solution that you have in your head. And a lot of people make the mistake of judging the result of the delegation by comparing it to their ideal solution they had in their head, and then they're unhappy. But don't do that. Yeah. So I think you brought up a very good point, right?
So because CTO mostly are very experienced in the technology, right? They have a very strong opinion about something, right? So I think setting up a delegation with the success criteria is really important, right? And the success criteria should not be probably the how, but it's like the why or the what metrics that people have to achieve, right? Not necessarily how the things are done. So I think, yeah, not criticizing the way people that
you delegate to, right? Like not criticizing the way they do stuff. I think it's really important. So I think the other thing when we talk about delegation and building the team, right, So you mentioned in your book that a CTO needs to be able to scale the team 10X and also scale the systems 10X. When we talk about 10X, right, it's something like the big multipliers. So how can ACTO always think ahead thinking about the 10X capacity? 1010 X needs 10X, maybe speed or
whatever that is, right? The 10X scaling is just a number, it could be 8 or 12 or 50 years. The main point is that I think a lot of CT OS fall into two camps and they don't camp which is not thinking about scaling. And then the companies gets more customers and they fail because they have not invested in scaling. And it doesn't only mean systems, but it also means like people and processes organization. You might get an investment of 10 million, how do I spend it?
And you should have some plan on how you're scaling your department by 10 or at least by 5, you know. So do I need AVP of engineering? Don't I need AVP of engineering? Do I have development? Do I have self organized teams or how are this team structured and this kind of things? And also does your current tech setup, your cloud setup, does this scale easily scale to 10 times the customers? So a lot of CT OS I meet, I'm not thinking about scaling.
And then when there's some money on your customers, they fail. And the other part, the other type of CTO, they scale by a million times. You know, they have 10 customers, but they build infrastructure that could be used for 100 million customers. So they look into a future that will probably never come and scale their team. They hire AVP of engineering too early or they have too complicated processes or they have a cloud set up that's very complicated. That includes Kafka and that
includes a lot of things. And then they're proud of saying, yeah, we could scale a million times. But I, I think, well, then if you scale a million time you that's not happening and you build something that's more complicated for future that will not come. So don't proud of that. So the 10X is more about a scaling amount that makes sense. It's not too less, but it's also not like don't think about scaling, but it's also not
scaling a million times. Yeah. So I think many people would have this linear thinking, right? So as the time progressed, they just think of maybe what's the next feature, what's the next set of customers, right? But they forgot to think about what happened if let's say suddenly you become viral or so many traffic suddenly comes, right.
And that's where probably a lot of maybe service disruption or maybe challenges in terms of people, number of people that you need to hire suddenly, right? So I think thinking tenets for me, definitely it's quite a challenge to always think ahead in terms of techniques. But definitely as a CTO you need to always think far beyond right. Far beyond what is really required. But not too far. You will not get a million times customers next year.
That's not going to happen. You can't go that viral. Yeah, I was about to add on on this point, right. So you mentioned also we should not think too far ahead. And in your chapter, one of your chapter, you promotes radical simplicity. So I think this is also probably something that we need to always reflect, right? Because there are so many architecture patterns or maybe fancy technologies that people want to use, right? But you advise us to actually choose simplicity, like even be
radically simple. So why is that important? It's important for two reasons. The first reason is that it's much easier to operate. Something simple is much easier to operate than something complicated. If you have too much of A tech stack, too much different frameworks, you need to update them to stay secure. You need to it's, it's difficult if you have a lot of stuff, it's difficult to manage. So it's difficult for people to get in and during on boarding. So that's one, one reason.
The other reason is if developer think too much where I'm coming from, I'm coming from the 1980s, so I'm not back to the future, back from the past. So I'm from the 1980s and there were a lot of single developers like today in the, in the, the group of indie developers in the games, in the App Store with games. And it was in the 80s and a lot of people did great things on their own.
And I want, I think developers should become more creative again instead of developing features for product, but do creative stuff themselves and create deep technical features that are challenging by themselves and not develop shallow features that are only get interesting if you do them in Angular or React or something, you know. So a lot of developers I think are bored by the features they need to create because they are not intellectually stimulated
enough. And that's the reason they add so many frameworks or want to go from, I don't know, from JavaScript to M or from M to Odin or from switching some of the stuff around with programming languages. A very simple example would be, and that's something a feature I have seen in the past and I think I put it in my newsletter also. You go by bus or you go by train from one city to another city. And the feature this, the website asks you, do you want to sit in the sun or not in the
sun? And then you say, OK, I don't want to sit in the sun. And then the code, the application looks at how the train will go and how the sun will move and then decide if you should sit on the right side or of the left side of the train, you know, and if this feature is something that that's not easy to write code for, you need to think a little about it. And that's, I think it's
intellectually stimulating. So if you have a search, suppose you can book tickets and this feature would make it interesting for a developer adding such things like this, then ticket. And then you can have a check box want to sit in the sun or don't want to sit as our two radio buttons. And that would be interesting and that would keep people interested.
I think the most interesting feature I ever did was as a kid, there is this, I don't know how it's really no, but there is this puzzle kind of that it's called Towers of Hanoi. It's a little bit of a puzzle where you need to move items or pieces around. And I came up as a kid, I came up with an algorithm how to solve this, like you have whatever situation you had. And then it's very simple. But I mean, I was AI don't know, 11 year old old old kid.
And that made me proud, coming up with this solution to this problem, to this puzzle. You know, I've found that one of the most intriguing and most satisfying things, and this is I think what people, what developers need to do, focus on deep features that are intellectual stimulating. And Long story short, if you practice radical simplicity, you have a minimal text stack and you are enabled to focus on deep
features. Otherwise, most of your effort just goes into how do I make React Native work with a polygraph, QL and all of these stuff. You know, that's where the effort goes. We're not into how do I find out if the person should sit on the right or the left side? Where's the sun on this trip? Yeah, I think simplicity, definitely many techies would probably fall into the trap, right? So they first probably think, oh, this is simple, but turns out it's not. And I think you brought up the
main gist, right? So easy to operate. So it's not necessarily easy to develop. Easy to operate is something also that is definitely important, right? So you don't want to have to spend so many resources, skill set to actually operate the things that you do, right? And I think focusing on the core things like the core aspects of your business, building deeply intellectual solutions, that that is probably OK, right? But the rest of that should be radically simple.
So one aspect that I find when I used to be a engineering leader as well is actually to manage yourself. This position can be really stressful, right? So many people challenges, not to mention you also on the hook, right? So you are responsible for many, many different things, including maybe incidents or maybe wrong box, things like that, right? So definitely managing yourself is something that a lot of us can learn from. So maybe from you, what are some of the tips that you?
I think it's very important for ACTO role because sometimes the job can be very lonely. You are at the top, but you cannot trust too much of the people, right? To tell all the challenges. But you also don't have PS to talk to. So maybe some of your tips how we can actually be mentally healthy kind of ACTO. What do we talk about, Delegate? I think it's very important to get to a sustainable work level, so that's important. Second, you might want to get a coach.
A lot of the stuff sometimes I'm, I'm, I feel a little bit like a therapist. I'm not in any way qualified. But a lot of the stuff we're talking about is how people feel and the opportunity to vent off. And so a lot of stuff in coaching is going beyond technical details. I think it's important to network more. I feel other executives in the company are better at networking. You know the head of sales might or the VPF sales might go to lunch with the VPF marketing
every week or something. You know that's what they are doing and in no way derogatory when I say they. But CT OS don't do this enough. They stay too much in their tech bubble and do not connect to other people enough to other people in the company. So I would urge everyone to have a one-on-one lunch. One-on-one with AVPF marketing or with the VPF sale or the VPF customer support of customer
success, that makes it easier. You talk about what you want to achieve and you learn about them and you build a relationship. And that makes a lot of meetings and lot of things less stressful and also often puts a lot of pressure into context into more context. So that makes it easier. And the last thing I, I think it's what a lot of stress comes from, I feel is like the CTO does not talk enough about expectations with the CEO. So I urge every CTO to talk to
the CEO about expectations. What are their expectations to the CEO and what are the CEO's expectations towards them. And talking about expectations and clearing them up also makes everything much clearer. And you might feel pressure where it's unnecessary. You know, it's the CEO thinks it's not that important, but you put the pressure on yourself. So a lot of pressure that comes your way is something you put on yourself. And by clearing expectation,
this can go away. That's actually a very golden tip, right? So manage the expectation from the CEO. First of all, understand the expectation and manage it properly, right? And I saw sometimes I think the CTO because they are like the main person who are responsible for tech and many of the start-ups actually, it's a tech driven kind of a company, right?
Sometimes they take failures too seriously, you know, like if something that's a bug or service is down, maybe because of a good heart of an engineer, right? They take failures really seriously. And the other aspect which is quite common for any engineers in poster syndrome, right? Simply because there are so many things that they cannot keep up, so they feel that they are not the right person for this. Any kind of tips about handling failures and imposter syndrome? Probably.
I think the best thing about imposter syndrome, I think is just talking to other people and accepting their few. And I think you might be Whenever people talk to other people in the company, they are often surprised how positively people are seeing them. And then you should just, you just accept what they are saying and not doubting what they say. And they, well, they don't have a clue. I don't know anything. So they have the wrong image.
No, if they have this image, look more into what people think of you in a positive way, not a negative way, but in a positive way and take this positivity away from it. So I think that's important to for this imposter syndrome. So talking is very important. And the second thing, I think the most important thing about failure is be transparent. Yeah, I see too many CT OS, and this goes down to the senior developer, probably to the junior developer.
They want to keep keep failures a secret. And that also feeds into the imposter syndrome. If you keep failures a secret, it always is like, OK, if they would really know how often I make mistakes, that they would not like me that much. So I'm kind of an imposter. So if you transparent around your failure, especially as the CTO, that's a good thing. I mean, if you have too many failure, you might get fired. But usually being transparent is a good thing. And I made the mistake myself.
I tried to keep everything in tech, not talk about failures, and that became became very difficult and unmanageable. Hopefully no one sees the website has a problem. This kind of things, if you can fix it in a minute, maybe no one has seen it and stuff like that. That was a huge mistake. And when I became more transparent, for example, in the company where I was CTO and I came in to fix all the problems
because they had huge problems. I set up a mailing list with the head of marketing and the CEO and the CFO and the head of sales and everyone. And whenever we had a problem, I sent to the e-mail. We have currently have a problem, we're working on it. And then when the problem was solved, sent out an e-mail and said it's solved. So being transparent about incidents, about failures, like there was this critical back, we lost €50,000 or $100,000 or something. Be transparent about it.
That will help you be more relaxed because you don't need to keep things everything under lid. On one hand, it also helps with the imposter syndrome and it builds trust with people. If you're transparent about your failure, it builds trust with the CEO and everyone else in the company. Yeah, that's a good point, right. So if you are more transparent and you just share as it is, right? So I think the trust can be built, especially if you are
reliable, right? So you understand that there's a failure or there's a mistake, but you take responsibility to actually solve it. I think that also builds a lot of trust with other people. So the last few chapters in your book, you mentioned about the future of this CTO role. I think one thing that I find really interesting, you touch on also about AI and how it can become an opportunity as the
next evolution for the CTO role. So maybe if you can elaborate a little bit of your thought process here, how can AI actually help the CTO role evolves? I think the main thing would be what I think is very important, at least what's very important to me is what I mentioned before is getting techies back into a more of a creative driver's seat. Because a lot of people I know who came to the tech world came to the tech world because of
creativity. You mentioned video games before and people wanting to write video games perhaps. And because of the creative energy there is in creating something out of nothing. There is nothing in the computer and then you do something and then there is something. And I feel like CT OS have been coming very good at executing
other people ideas. And so on one hand, I see AI as an opportunity to become, to get again to connect with the creative inside you, the creativity inside you and become more creative again and own creativity in the company more. So that's what I see as a very positive thing. The challenging thing is that I think currently no one knows how AI will affect software development. Will this replace all developers? Will this replace product management?
Will there be software? Will there only be AI? How this is all like? We're currently in uncharted water, uncharted territory. It's unclear what the future will bring. Everything is possible I think. Which means again, if everything is possible, I urge CT OS to grab AI to see how AI can positively impact their business. Own it and drive it. If you don't drive it as ACTO, someone else in the company will drive it. So don't fall in that trap.
Yeah. So I think you also mentioned in one of the chapters that CTO needs to think about the future of the software development, right. So always knows where the future kind of like you know the direction, right, so that you can bring people along maybe with the vision and the prediction, right. And I think you brought up a good point to become a creator
again. Many CTO probably have become less hands on and maybe they are afraid of learning new technologies as well because the pace is really so fast. And just by having AI probably is also a good companion, right for you to, I don't know, like maybe learn new technology, try to understand existing codebase or even ask about things that probably you are not familiar with. Could be like security, could be so many other aspects that probably are required for the role.
So I think definitely do take a grabs of this AI technology and make it useful for the role. So thank you so much for this time. Stefan, I have only one last question from you. I know that we have talked a lot about insights and things like that, but I normally have one last question that I always ask my guest, which is to come up with this thing called the three technical leadership wisdom.
So if you can think of it like an advice or just summary of all the insights that you have shared with us, what would these three will be? Well, the summary is essentially for me, be creative again, that brings happiness. Be a leader. That makes things much easier. I only have these two. I think that would be the most important. Be creative again on one hand, and really be a leader. All right, so thank you so much
for the wisdom. So Stefan, if people wants to buy your book, right, or maybe they want to connect or even get in touch with you for the CDO coach so when they can find you online. They can find me online on LinkedIn and if you want to talk to me and just share something then just share it then it doesn't need to be acdo relationship. We just can have a call or something on one hand and the book is founded CTO book dot dev. Right. So it's one of the best selling book on Lean Pub.
So I think most of you can check out there as well. And I've personally read the book. It's really fun, insightful, and I think it's the most important thing is bite size for those CT OS who don't seem to have enough time to actually read a book. So thank you again for your time, Stefan. So I hope people learn a lot today about the CDO role or maybe engineering, leadership and management in general. So thanks again. My. Pleasure. Thank you.