#186 - The Amazing CTO's Missing Manual: Guide to Managing Tech Teams - Stephan Schmidt

[00:01:17] Introduction

Henry Suryawirawan: Hello, everyone. Welcome back to another new episode of the Tech Lead Journal podcast. Today, I have with me, Stephan Schmidt. So he’s the author of this book titled Amazing CTO. This book is actually in the top bestselling book in the Leanpub. So if you want to check it out, go to Leanpub. 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, Stephan.

Stephan Schmidt: Hi, Henry, welcome. Happy to be here.

[00:01:46] Career Journey

Henry Suryawirawan: Right. Stephan, 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.

Stephan Schmidt: Well, about 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 startup in the 1990s, doing internet stuff, HTML, 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 a CTO 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 startup 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 different manager. I have been on a long journey at that point already and made a lot of changes.

But I think the final thing was at 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.

Henry Suryawirawan: Wow, 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 mention your story, you know, playing the computer at the computer store or some video game store, right? So and then, you know, it piqued, you know, interest. Yeah. department store. and that’s what brought you here now becoming a CTO coach.

[00:03:57] The Role of a CTO

Henry Suryawirawan: 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 a role?

Stephan Schmidt: 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 can be everything. 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, the product needs. And then it’s 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 five engineers to a hundred engineers. And there 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. And that’s where I have some expertise in, which is fast growing startups. So I don’t have a lot of expertise in large enterprises or something.

But in fast growing startups and what defines the CTO role there is that it changes so much. So you might be the first coder, then you need to hire other coders. Then you need to manage them. You need to become a people manager, a tech leader. Then you manage other managers, you’re a manager of managers. And then you can become a CTO 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 some times where people struggle with.

For me personally, I have two defining characteristics of the CTO role, and it does not have to do 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 of 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 are 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.

[00:06:54] The Missing Manual

Henry Suryawirawan: 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 startups 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 a CTO. So you mentioned in the book is 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?

Stephan Schmidt: So the manual 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’ve been chosen as a co-founder and stayed on through changes and the 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 hasn’t mentored them or because 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.

Henry Suryawirawan: 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 gave us a manual. Especially in the startups. If you’re working in a big corporate, probably you can see so many other peers or mentors that you can actually learn from, simply because they have seniority.

But in 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 mentor. So I think, I get the sense like we need this missing manual.

[00:09:22] 140 Bite-Sized Rules

Henry Suryawirawan: But in your book you have 140 kind of like advice or rules. That seems quite a lot. How did you come up with all these rules, actually?

Stephan Schmidt: 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 five 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 and it’s also important. And in the end, I dropped some, but state in the book.

Henry Suryawirawan: Right, so I think I agree, I like reading your book, right? It’s very concise, bite-sized, 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 topic, right?

[00:10:52] CTO Struggles

Henry Suryawirawan: So one thing also you mentioned, you have become a CTO coach. Maybe throughout your coaching experience, if you can maybe summarize what areas typically many CTOs are struggling with?

Stephan Schmidt: I think what a lot of CTOs struggle with is, is there are some areas. They usually do not struggle with technical issues. The one thing they might struggle with technical issues is, and it’s 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 big tech zoo. And then it gets, sometimes it gets difficult to manage the tech zoo, because all of these things need to be maintained. If you want to hire new developers, they need to know about the stuff, so it gets, hiring gets more complicated, maintaining gets 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 a CTO, that’s sometimes where they struggle.

And I think the third thing where CTOs struggle is leadership and strategy and vision. And also being an executive, which ties, I think, into the theme. Most of the CTOs I work with are swamped with work from their day-to-day job. The CEO wants something, marketing wants something, product wants new features, sales wants new features. There has been an incident. So there’s a lot of pressure on CTOs. And too many CTOs 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 a leadership.

For me, vision is very simple. It’s like being at an office, of a company offsite, hiking. And then the vision is having barbecue 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.

Often it’s talking 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 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 a CTO to say, okay, this is my vision. This is my strategy with input from everyone. And this is where we go to.

Henry Suryawirawan: 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.

[00:14:43] Stephan’s Failure Stories

Henry Suryawirawan: So in the first place, maybe we can learn from you yourself in your career as a CTO 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 would be great.

Stephan Schmidt: Yeah, I had several failures. One failure, essentially, was at a 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 me and the team. And my mistake obviously was not giving enough pushback. I should have given much more pushback 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 PM. I want to do something too. And so someone suggested, okay, you can write some JavaScript code here. The senior developer thought, well, if we have some simple JavaScript, Stephan will not screw up.

And well, what happened is I screwed up. I wrote some JavaScript code, which after released brought the website down. And it was a large website, a 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 all the intricate details of the domain and the side effects and what you need to 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 a CTO. 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 a CTO, I 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 than day-to-day, deep in the woods, feature stuff. So that was my, one of my failures.

Henry Suryawirawan: 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 miss 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, research will be something that is more relevant and useful so that you can give guidance to people.

So coding definitely is one aspect, right? So there could be other plenty of areas that you need to think of. You just mentioned just now like vision, 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?

[00:18:05] Strategy is for People

Henry Suryawirawan: 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?

Stephan Schmidt: Strategy helps people make decisions. So from my former example of the hiking and the strategy is to go left off 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. Whenever 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 useful. The strategy is not for you. The strategy is for everyone else to support them in their decisions, essentially.

Henry Suryawirawan: Yeah, so I find what you mentioned just now, right, strategy is to help people make decisions, 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 CEO will decide for the business, but for the tech, maybe the CTO will be the one who set up the strategy.

[00:19:59] Set People Up for Success, Not Failure

Henry Suryawirawan: 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 a CTO do that to set up people for success?

Stephan Schmidt: I have quite some coaches or 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 that 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 the person connect to other persons? 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 checkups 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. There are obviously very good managers and they’re 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 their job. And then it’s your mistake. It isn’t a mistake of the person you hired.

Henry Suryawirawan: 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.

[00:22:59] One-on-One & Automatic Management

Henry Suryawirawan: 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 as a CTO role?

Stephan Schmidt: 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 lever 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’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-ones is status updates. Only if the person really wants to do this, but usually, no. They can send me an email 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 email. 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 are 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, who explained 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 as 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-ones, I explain the world by what 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 I know the CEO wants to do something, I talk to the person on the one-on-one and 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 all 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 explains to everyone, we’re going to a new market, in a one-on-one I ask people, so you heard the CEO, does this make sense to you? Is this a good idea? And then they say, no, I didn’t understand what he said. And then I 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? First thing I ask them, yeah, what would you do? I try to always empower people and give ownership and explaining things in a one-on-one does this. As does the strategy and the vision. Strategy and vision 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.

Henry Suryawirawan: Yeah, so I like the automatic management, right? Definitely, if you can let people be independent as much as possible, definitely that will be great. But that also relies a lot with your strategy, right, to help people make decisions. Maybe setting up the right culture as well. And also maybe encourage people to take responsibility, right?

[00:27:29] Delegate Everything

Henry Suryawirawan: 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 CTOs, 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?

Stephan Schmidt: 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 this company was small, but can no longer be your job when the company grows. And at that point, a lot of CTO 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 and say, okay, 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 were 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 own those decisions. Like they own the architecture decision. It’s not something that Stephan says. It’s not something you do this and then people don’t own it, but they make a decision, they own the decision. Down the road, it makes things a lot easier if people own their stuff or own the decisions they are making instead of me making decisions.

[00:30:02] How to Delegate Better

Henry Suryawirawan: 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 skillset. That’s the first thing. Skillset and experience. And they want to take responsibility to actually own the thing. The other thing is, of course, when you are a 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 onboarded, right? Is there any trick from you how can we actually delegate better, right? You can’t just, for example, a new person join, 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 are given to them?

Stephan Schmidt: So everything I said about setting up for 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 the 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 experience, you’re delegating tasks. And my mistake was I wanted to be delegated by goals or something like Stephan solves this. Code coverage or quality or you know. So I wanted to be managed by goals. And then this is how I manage people in the past.

And like 20 years ago, that’s how I delegated things. But like if the person is 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 is senior, that’s also a mistake. They’re telling people who are some very senior, do this, then do that. And then do this again. They get annoyed by you being too 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 and seniority level. I think that’s very important.

And the other thing, the biggest mistake I think is in delegation is “I would have done 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 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 idea solution they had in their head, and then they’re unhappy. But don’t do that.

Henry Suryawirawan: 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 a 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 the 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 is really important.

[00:33:17] Think in 10X

Henry Suryawirawan: 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 a big multipliers. So how can a CTO always think ahead, thinking about the 10x capacity, 10x needs, 10x maybe speed, whatever that is, right?

Stephan Schmidt: The 10x scaling is just a number. It could be 8 or 12 or 15 or something. The main point is that I think a lot of CTOs fall into two camps. And in one camp, which is not thinking about scaling, and then the company 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. You divide it by 10 or at least by five.

You know, so do I need a VP of Engineering? Don’t I need a VP of Engineering? Do I want to add development? Do I have self organized teams? Or how are these teams 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 CTOs 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 a hundred million customers. So they look into a future that will probably never come and scale their team. They hire a VP of Engineering too early. Or they have too complicated processes or they have a cloud setup that’s very complicated. That includes Kafka and that includes a lot of things. And then they are proud of saying, yeah, we could scale a million times. But I think well, then if you scale a million times, that’s not happening. And you build something that’s more complicated for a future that will not come. So don’t be 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.

Henry Suryawirawan: 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 happens 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 10X, for me, definitely, it’s quite a challenge to always think ahead in terms of 10X. But definitely, as a CTO, you need to always think far beyond, right, far beyond what is really required.

Stephan Schmidt: But not too far! You will not get a million times customers next year. That’s not going to happen. It can’t go that viral.

[00:36:15] Radical Simplicity

Henry Suryawirawan: 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 promote 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?

Stephan Schmidt: It’s important for two reasons. The first reason is that is 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 difficult if you have a lot of stuff. It’s difficult to manage, so it’s difficult for people to get in and during onboarding. So that’s one, one reason.

The other reason is if developers 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 senior developers like today in the indie, the group of indie developers in the game, in the app store with games. And that was in the eighties. 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 Elm or from Elm 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, the website asks you, do you want to sit in the sun or not in the sun? And then you say, okay, 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 on 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 bit 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 checkbox, want to sit in the sun or don’t want to sit in the sun or 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 known but there is this puzzle kind of type. It’s called Towers of Hanoi. It’s a little bit of 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 a, I don’t know, 11 year old kid. And that made me proud coming up with this solution to this problem, to this puzzle. You know, I have 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 intellectually stimulating. And long story short, if you practice radical simplicity, you have a minimal tech 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 Apollo GraphQL 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?

Henry Suryawirawan: Yeah, I think simplicity, definitely, many techies would probably fall into the trap, right? So they first probably think, oh, this is simple, but it turns out it’s not. 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, skillset, 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 for that, that is probably okay, right? But the rest of that should be radically simple.

[00:40:56] Managing Yourself

Henry Suryawirawan: 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 bugs, 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 think it’s very important for a CTO 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 peers to talk to. So maybe some of your tips how we can actually be a mentally healthy kind of a CTO?

Stephan Schmidt: What we’re talking 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 put the opportunity to vent often. 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 a company are better at networking. You know, the Head of Sales might or the VP of Sales might go to lunch with the VP of Marketing every week or something, you know. That’s what they are doing. In no way derogatory, when I say they.

But CTOs 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 a VP of Marketing or with the VP of Sales or the VP of Customer Support or 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 a 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 think, is what a lot of stress comes from, I feel it’s 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 expectation 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.

Henry Suryawirawan: 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 startups actually is a tech driven kind of a company, right? Sometimes they take failures too seriously. You know, like if something, there’s a bug or service is down, maybe because of a good heart of an engineer, right? They take failures really seriously.

[00:44:07] Impostor Syndrome and Handling Failures

Henry Suryawirawan: And the other aspect, which is quite common for any engineers, imposter 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?

Stephan Schmidt: I think the best thing about imposter syndrome, I think it’s just talking to other people and accepting their view, 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 say, oh, 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 in a negative way, but in a positive way and take this positivity away from it. So I think that’s important to follow the 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 CTOs, and this goes down to the senior developer, probably, or to the junior developer, they want to keep key failures a secret. And that also feeds into the impostor syndrome. If you keep failures a secret, it always is like, okay, 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’re transparent around your failure, especially as a 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 intact, 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 we 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 it to email. We have currently have a problem. We’re working on it. And then when the problem was solved, sent out an email and said it’s solved.

So being transparent about incidents, about failures, like there was this critical bug. We lost 50,000 euros or a hundred thousand dollars or something, be transparent about it. That will help you stay, 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.

Henry Suryawirawan: 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.

[00:47:07] The Future of CTOs

Henry Suryawirawan: 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 evolve?

Stephan Schmidt: 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 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 CTOs have been coming very good at executing other people’s 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 CTOs to grab AI, to see how AI can positively impact their business, own it and drive it. If you don’t drive it as a CTO, someone else in the company will drive it. So don’t fall in that trap.

Henry Suryawirawan: 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 code base or even ask about things that probably you are not familiar with. It could be like security. It could be so many other aspects that probably are required for the role. So I think definitely do take a grasp of this AI technology and make it useful for the role.

[00:49:46] 2 Tech Lead Wisdom

Henry Suryawirawan: So thank you so much for this time, Stephan. 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 guests 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?

Stephan Schmidt: Well, it’s 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.

Henry Suryawirawan: All right. So thank you so much for the wisdom. So Stephan, if people want to buy your book, right, or maybe they want to connect or even get uh in touch with you for the CTO coach, um, so where they can find you online?

Stephan Schmidt: 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 a CTO relationship. We just can have a call or something. On one hand, and the book is found at ctobook.dev.

Henry Suryawirawan: Right, so it’s one of the best selling book on Leanpub. 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 the most important thing is bite size for those CTOs who don’t seem to have enough time to actually read a book. So thank you again for your time, Stephan. So I hope people learn a lot today about the CTO role or maybe engineering leadership and management, in general. So thanks again.

Stephan Schmidt: My pleasure. Thank you.

– End –