dnsUNFILTERED: Stephan Schmidt, CTO Coach

[00:00:00] Mikey Pruitt: Welcome everybody to dnsUNFILTERED. I'm here with Stephan Schmidt. He's the CTO whisperer, I would say. Also has a concept of radical simplicity that I wanna dive into with him. Stephan, can you introduce yourself a little bit?

[00:00:16] Stephan Schmidt: Yeah, I'm Stephan. I'm a coder by heart. I teach myself coding in department store four years ago as a kid to write some video games.

Wrote some video games did a lot of things in between then and now I've been an engineering manager for a long time and for some years now I'm a CTO coach helping CTOs with the pro, the same problems I had. Actually,

[00:00:40] Mikey Pruitt: Let's talk about some of those problems. But first I want to.

Mention how I came across Stephan's work, which was a YouTube video with a bunch of views. I was going over this article at radicalsimpli.city, which is your website. And the first, the whole page is just your manifesto, on how developers tend to overcomplicate things. They love complexity.

The complexity, slows development down really leads to like shallow domains and. Radical simplicity kind of makes development faster and more enjoyable. Can you tell me about your ethos on radical simplicity?

[00:01:18] Stephan Schmidt: Yeah. Oh where to start. It manifested in my mind over the years.

That, or some things came together mainly that the setups I see are way too complex for the problems that are they are solving. So whenever I look in a startup and I look at a tech setup and that technology usage, it's much too complicated for what they want to source. And on the other hand I saw that developers.

Always went into using new frameworks, new libraries, writing their own libraries, creating some complexity that also mostly does not add to the benefit of the customer. It doesn't add value to the company. And especially in the context I'm working, which is mostly with fast growing startups.

You need to do everything to make it succeed. And if you do some stuff on the side that's not raise a focus to succession, to success, then then basically you're on the edge of failing. And so some things came together and and I think radical simplicity is the idea to make the tech stack.

As simple as possible, not simpler, but as simple as possible. So you can concentrate on deep domain features, which needs obviously to play along with product management, but you can concentrate on deep features that resonate with the customer instead of doing some technical stuff. And I think the first time I really came across this is when I didn't know.

But but when I was 10 years old or something like that because there is this game, it's called towers of Hanoi, I think. It's around a small, very simple puzzle game where you move pieces around from one side to the other with some rules. And as a kid I found out what's the algorithm behind it?

And then I tried and then I found the algorithm, wrote some code. And then the code did solve these puzzles. Very simple puzzle, but it did solve this puzzle and I was very proud on my achievement on finding out how this works and and what, how to solve this. And I think this is where the developers need to be today.

So if deep domain problems instead of shallow domain problems,

[00:03:45] Mikey Pruitt: so for those of you who don't know, the towers of Hanoi game as the game with three little sticks and little discs where you can start with the big disc on the bottom that goes up to the small disc, and then you can move them around to move them to another stick, which is, rather complicated al algorithm for a 10-year-old especially.

So I guess when you solved that game you probably were thinking, oh, like this is something I'm interested in and that kind of. Launched you into a world of technology eventually.

[00:04:13] Stephan Schmidt: Yes. That was part of it. Getting on onto the track the, I also got a lot of engineers, I think a lot of developers, I got into the, into all of software engineering, software development because of the creation process.

There is nothing on the screen. It's blank, it's a blank canvas. And then you do something like, in my days as a kid, it was a V 20, Commodore V 20, and you did some. Typing and then this screen turned green or yellow. And so you created something out of nothing. And and this creation process is something that brought me into software development that I think brings a lot of people into software.

[00:04:52] Mikey Pruitt: I definitely agree with that. I do want to talk with you about your thoughts on AI and the future of coding. 'cause I did a little research on your thoughts there too and how that, that active creation, which draw drew a lot of us to coding, to development may not be in the future plans for humanity.

But let's put a bow on that for just a second. 'cause I wanted to go into this. Radical simplicity a bit deeper, but in the aspect of like business management. So you also have a few companies that relate to CTO coaching. Chief Technical officers and matching them with great companies, making them great CTOs, and then matching great CTOs with great companies.

And it appears, from what I can see from the outside, that this radical simplicity ethos has. Influenced those businesses as well. Can you talk a little bit about how radical simplicity of business kind of matches together?

[00:05:53] Stephan Schmidt: Yeah it, the radical simplicity idea I have two things which is amazing.

CTO, which I'm, where I'm coaching CT os MVP of engineering and senior directors. All the people for me, everyone is a CTO who can't bubble up tech problems. So if you can't bubble up tech problems 'cause your boss is not interested, then essentially you're the CTO independently on, on you currently have, so this is where I'm coaching and there's the other thing which is called ink me I-N-K-M-I where we match CTOs to companies.

But in a way where the CTO describes what their dream shop would look like, and then we try to find the the company for that. And the best way how it should work is you get one email a year or one email every second year. But that's really and the radical simplicity idea here is that the stack where, how this is built.

It's really as simple as possible. It's just a Postgres database a go application no JavaScript front end because I think you, you don't need it. And just very simple JavaScript. And also very basic CSS no complicated CSS set up which enables. Me to do a lot of coding and create a lot of value and features without knowing too much different technologies like Kafka and all the other stuff.

Throw Yeah.

[00:07:25] Mikey Pruitt: And about those services, like here at DNSFilter we use a lot of microservices, I guess you call 'em, and you call those out as like when you. It's kinda like a signal, like if you have a lot of microservices, perhaps you're not simple enough or there's room to be simpler.

Is that something that is very telling when you talk with technical teams?

[00:07:46] Stephan Schmidt: I'd say it's very telling. If you have more microservices than employees or more microservices than developers, I think that's a sign. I'm not in, I'm not against microservices. In principle they solve a problem.

They have not been invented for no reason. There is a problem they are solving. So if you have a lot of developers and you want them to work independently. And you also have a lot of services that you need to scale independently. The Microsoft services is a fine concept, I think, but a lot of companies have, I dunno, I meet, have 10 microservices, 10 developers, or 20 microservices 20 developers or something that's too much.

I don't know where the ratio is, but let's say five developers per microservice or something like one team, one microservice, or one team. To microservices. That is something I would consider a normal setup. Because there are a lot of downsides in microservices. It's harder to deploy, it's harder to create a local development environment.

It's harder to debug and trace, cross trace it. You need a lot more tools to make it work. Which when you have just a simple application, everything is very simple. And so yeah I think it depends. But when I hear microservices in a small company or like in a company up to 20 developers and I hear microservices, I think

[00:09:08] Mikey Pruitt: there's a code smell there.

[00:09:10] Stephan Schmidt: Yeah.

[00:09:11] Mikey Pruitt: So you wrote a book called Amazing CTO and it's really seems the technical skills that you have are your technical prowess has elevated you to like a management level and perhaps you're not versed in managing people. Is that what you're, is that what the amazing CTO book is focusing on?

Like how to combine your technical skills and be a well-rounded manager, which those things combined equal CTO.

[00:09:40] Stephan Schmidt: Yeah, you can say, so I think the idea that you mentioned is the technical skills brought you into the position, into the management engineering position because you have been the best engineer.

And for that reason probably have been made an engineering manager, but the hard skills only bring you into a position. The soft skills make you succeed in that position as a manager. And and this is something a lot of engineering managers, CTOs, VPs, but also team leads do not understand enough, I feel and like they in engineering or in software development, leaders and managers have it easier than let's say in marketing.

Why is that? Because. Engineers have a really, have a clear pecking kind of pecking order. They understand which engineer is better, who has more experience. And because we're very fact driven, in fact based we accept people with more experience and we, we usually accept the better argument.

And you're in this environment. And it's easy to be the leader. It's easy to be a team lead because you already have to respect from the team because you're probably the best engineer, which brings you the respect. So for some time it's easy to be a leader. And then at another level you talk to business people, you're the CTO, you're sitting in the board.

And your technical skills are not nothing worth anymore. People assume you're the best engineer because otherwise why I you, the CTO. So it does not bring anything, any benefit, so yeah, it's like the

[00:11:15] Mikey Pruitt: in the inherent authority that is given to you by your technical skills is not there when you're A CTO.

Yes. It irrelevant.

[00:11:22] Stephan Schmidt: Yes. And at that point. They try to do the thing that worked for them in the past with engineers and it doesn't work with other people in marketing or in business development or in sales or with the CFO. And then they struggle and at this point in time for this, there is the.

[00:11:43] Mikey Pruitt: That's actually really funny. It makes me think, so I actually work in marketing now at DNSFilter and I began as a DevOps engineer here. So I, am a technical person and I was, not the best engineer for sure. But now that I'm in marketing, I'm the best engineer in marketing, so a hat that I get to wear.

Thank you. Marketing team at DNS Holter.

[00:12:04] Stephan Schmidt: Yeah, which is very valuable. When I was the CTO in several companies often all the time, we saw very hard technical problems, really hard technical problems with millions of users and difficult things. But no one thanked me for these and no one, but what they thought, but what they said when I left the company, they said, oh, Stephan, it was great working with you.

You could explain technical things to business people and we could talk to you and you would understand that. And this is what people valued when I left. I none of the technical things we did and they were really astonishing things. Some of them, one technical problem, basically, safe safety company.

Without the team solving the problem, company would have gone vast, but no one recognized that outside technology,

[00:12:55] Mikey Pruitt: it was like a, somebody walking by in the hall. Oh, good job, Stephan. Yeah. Here you go. Thanks.

[00:13:00] Stephan Schmidt: Yeah. Like a handshake that's, you got use that, that you understand business and can interact with with people outside of technology.

[00:13:06] Mikey Pruitt: So your book, amazing CTO, you called out one of the reviews that said Pleasantly BS Free, which was, yeah, I loved, because that was your favorite review, the one that you put like under the book page. Yeah. So this book I'll link it in the description below this video. But yeah, check it out.

Amazing. CTO if you're, engineering minded and thinking about, elevating your career or maybe even not, just to understand how CTOs. Should behave. I think it would be a really good read. I've got mine on order already from Amazon, so looking forward to get, getting that and taking a read.

So you have another book? No. Let's, lemme rephrase. You do not have another book yet, and I haven't written down here. Where is it? Let's see. Yeah, have another book, the Tech, you do have another book, but you have a book that's not written yet called technical Debt. So you are, you're thinking of writing a book on technical debt, but instead of writing this book, you put up basically a landing page that says, how much would you pay me to buy this book?

Which is like the embodiment of radical simplicity. Minimum viable product. People say that all the time, but they rarely do it. But in this case, you actually did. The minimum viable thing, which is, Hey, how much would you pay me? And if enough people say, I would pay you X dollars, maybe you'll go write this book.

[00:14:24] Stephan Schmidt: Yeah. So two things. I have another book. Which is a book about poems. So there, there's a book. Oh, I didn't see that one. With poem. It's not about poems. With poems. Basically sold five things, five, five books. So not a large market but poems in Germany. But yeah, tend to write a book and working on it on technical depth because this is something that also comes up in coaching all the time.

CTOs are pressured into shortcuts and flaky solutions to things. And then when the company gets serious traction, they usually have a lot of problems they have accrued over time. And so yeah that's going to be the book. And the landing page the very interesting thing is that it's really the amount of.

Money people want to pay is really the same. It's like people say, oh, I want to pay between 25 and $30 or so. So a lot of people have signed up, left a price mark and it's really like you have some outliers. People say, oh, I paid $5, and some people say, oh, I pay a hundred. But overall it's astonishingly similar what people want to pay for that kind of.

[00:15:37] Mikey Pruitt: Yeah. So you can basically crowdsource the price, the appropriate price. Yes. Kinda like AB testing essentially.

[00:15:44] Stephan Schmidt: Yeah.

[00:15:44] Mikey Pruitt: But yeah, great use of simplicity and minimum viable product on that page, you actually said in one of your articles that you haven't met a team that does not have technical debt and that there were types of cultures that te tend to breed technical debt in their development.

[00:16:02] Speaker 4: Yes. I, the overall company, like the overall company

[00:16:06] Stephan Schmidt: culture, that it's obvious, but if you, the main driver, a technical debt is basically business pressure, so the features need to be delivered faster and faster. Products need to be delivered fast and faster. And this business pressure delivers creates technical depth inside, inside the code base.

Be it with because there has been shortcuts, because code has been placed in the wrong places because something that's should have been configurable is hard coded. So there are many ways where this pressure materializes depth, and I think that the challenge for them. Or the CTO is to understand when technical depth is a good thing and when technical depth is a bad thing, and use it when it's a good thing and prevent it from happening when it's a bad thing.

This is a, that will be the guess how to, and then also how to get out of it if you're accidentally running, how to identify

[00:17:07] Mikey Pruitt: When you're there, and then how to get out. Yeah. Yeah. Let me ask, what what advice would you give CTOs on leadership struggles and just developing into a well-rounded chief technical officer?

[00:17:21] Stephan Schmidt: Oh, there's so much. First buy my book. There's a no. Seriously. Even if I didn't earn anything with it I think it's a good book and it really, it's written to be helpful. It's, it has something like 140 rules which is one page each, and it's really written budget free and snack of the because I have so many books I haven't finished, so I thought I'd write a book.

You can easily finish. And read one page a day or something. And there's a lot of stuff in it, but what most of the, what most of the, or one pattern I see that a lot of CTOs and engineering managers struggle is by delegation because they don't delegate enough for various reasons.

Perhaps at the organization. Especially from my background with working with growing organizations. So the organization is growing. There is new stuff getting put on top of the CTO but they don't get rid of the stuff they're already doing, so they get need to do more and if you don't start giving away responsibility and ownership early enough, then.

You don't have the people to give ownership and responsibility to, so it's not only, oh, I don't want to delegate, which is part of the problem because a lot of them are perfectionists. They have a high standard for code for staff. So they don't want to give things away because everyone does it worse than them.

Which is true. But yeah, that's a way to stay. But

[00:18:51] Mikey Pruitt: They do it worse than them because they haven't been able to try yet. Yeah. Sounds and

[00:18:55] Stephan Schmidt: yes, and that's the second point is, and if you want to delegate something, when at the point when they are at the breaking point and they really need to delegate, they don't have anyone to delegate to.

'cause it takes some time to build up an organization where you can delegate tasks and ownership. You need to start small, give feedback, give guidance set up the people for success and do a lot of things. And then over time you will have several people in the organization where you can easily delegate.

Even demanding stuff too. But usually don't, they don't delegate then they come at a breaking point. They want to delegate, but there is no one there. So I, my, my core, my, my principle of advice I think is delegate early. So you have people that you can delegate to, you need.

[00:19:44] Mikey Pruitt: Yeah, that makes sense.

I've actually heard I believe it was a CEO Adam Robinson ends a company called retention.com. I think he was talking about. How to hire, not to import a new CTO, for example, or a know a marketing leader just grab somebody. But what you really, the type of people that you want in certain types of companies is people that are very entrepreneurial.

So that say the CEO, could then hand off the responsibility, ownership of that segment of the business to someone that can go make it their own. Create like a mini business within there. And it sounds like being a good CTO, like you're describing is very similar to that.

[00:20:28] Stephan Schmidt: Yes. Yes it is. Because you really need to give, there's so much, many things to you need to look into, security code, quality technology selection, so many things.

And if everything is with you, it's just not scaling on one end. And on the other hand, you're not doing the things that you probably should do, like having a vision working on strategy working on innovation, see how you can support business. 'cause you're swamped with the things that you inherited from a.

From essentially your past roles while growing. So yeah, I would agree.

[00:21:05] Mikey Pruitt: Yeah, that makes sense. Your, I was gonna ask you, I don't know if we should get into the AI topic or No. You ready to get ai? 'cause I I have similar feelings to you on ai. But you were talking about the future of coding, what it looks like, and you mentioned at the beginning like your love for creation brought you into the world of development.

And you have a few posts on your websites that basically talk about what coding looks like in the future, which is you request an outcome and you have little. Little action to do during the creation process because AI will just, do that for you. And we've already seen with some of the AI coding apps like cursor pair ai cloud dev that you can add to BS code.

There's a lot of coding assistance built into IDs now, and it sounds like what you're, what you think will happen is. The IDE will basically become irrelevant itself. 'cause anybody could just go to whatever AI thing and say, I want an app that does X and Y. And then it would pop out the other end and they would add a domain or whatever happens to be like, how do you picture this future of AI and coding to go?

[00:22:21] Stephan Schmidt: Yeah I think the. I envision it in some steps. And one step is that a lot of code and a lot of manual tasks currently that you're doing as a developer will be done by ai. Creating tests finding bug operating and monitoring a deployment, and all of these things. A lot of things. This is a net.

This is where we currently are already in, but this will become more and more perfect. To a point that it's just you do a very minimal thing of instructing, of prompting, and then everything magically happens. This is the phase we're currently in, and as I said, there will be some kind of.

Perfection. We're not yet there. But then the next step is

[00:23:10] Speaker 4: I think is replacing

the next step

[00:23:17] Stephan Schmidt: Is replace, yeah. Is replacing teams and replacing parts of this of the IT landscape. For example, I personally think that data teams will be one of the first ones to go and perhaps DevOps teams too. But it's easier to see with data teams. There will be the first startup that comes up with a perfect data warehouse solution that works on a data lake, on an S3 data lake.

And the CEO can just say, oh, draw me the revenue for last month. And then you have a revenue or create a slide deck with with the KPIs, and then you have a slide deck with the KPIs. And, I don't know, don't need people building reports. I don't know. People don't need people doing sql. I don't need people doing several SQL layers and pipelines and all of that will go away as soon as someone creates this working.

Chat, GBT working level AI that just does everything from between gaps closest, the gap between a data lake and the KPI. Yeah. PowerPoint, Dick,

[00:24:23] Mikey Pruitt: I've seen apps that are like, chat with your data, and it's yeah, it's not cool. It's not quite there yet. Like the world you're describing.

I, I agree that it's, on an infinite timescale would probably definitely happen and it's really probably the goal of computers itself. That's. The goal of computers was to do everything for us so that we can, relax on a beach somewhere.

[00:24:44] Stephan Schmidt: Yeah. But hopefully they won't

[00:24:45] Mikey Pruitt: try to kill us in the long run too.

[00:24:47] Stephan Schmidt: No. Yeah. And I think it would be very fast, like just by Slack or Notion, like no one was using Notion for my clients and then at some time everyone was using Notion. People use different things, and the same with Slack. And I, this is how I envisioned it, someone. Creating a data application that just works and does everything a CEO and marketing and everyone wants from a data.

And then I think most data teams are toast. And

[00:25:13] Mikey Pruitt: also you did the like departments and job titles you were mentioning has probably got a lot of our audience, we have a large IT audience, a lot of business people in the audience. And a lot of them are probably thinking, oh, that's my job.

Ah, like a little scared. And I know some of them personally at, on staff at DNSFilter, they're probably listening to this going, oh my gosh. But, I think we'll be fine. We'll find something else to do.

[00:25:35] Stephan Schmidt: Are you trustee first? So just like. Coders will also, it will just spread to other easy other parts.

I think that probably data QA and DevOps is easiest before goes into more into coding. And then we have a state where these applications are created. But then what I think when I have discussion with coders, they don't understand that there will be no applications anymore. It's, I'm not a Star Trek fan per se, as like some of the stuff.

But I think it's, it will be like in Star Trek, the computer. You say, I want this, and then the computer does it. I want I don't know do I have. Or make more money out of my prime customers. And then the computer makes more money out of prime customers by sending emails or by inventing a VIP or whatever.

It does little thinking.

[00:26:25] Mikey Pruitt: The think a little bit, then it's okay, this would probably net 10% increase in revenue. Yeah. So do that and maybe it can do some AB testing of it. So yeah, I mean that probably is the future. So

[00:26:35] Stephan Schmidt: there's cm. There's no just people think, okay, the CRM map and then the AI will write the CRM map.

No, I don't think the AI will create an CRM map. It will just do the task.

[00:26:48] Mikey Pruitt: So a lot of the concepts we've been talking about simplicity technical debt looking forward, what is to be expected from tools like ai. They all are we are focusing very heavily on development and coding and technology, but they also apply.

To the business world. So the simpler, say I work in marketing, the simpler we can keep our sales funnel, the more likely we are to have the ability to make adjustments quickly. Yes. Go ahead. I just,

[00:27:20] Stephan Schmidt: Yes. That's one of the main points. Yes.

[00:27:22] Mikey Pruitt: Yeah. So the, that simplicity carries over across realms across departments for your business marketing, sales, et cetera.

Anything you can. You can simplify, you should try to, and then the kind of the hiring the entrepreneurial spirit of your employees is really helpful too. And it sounds like you're trying to coach CTOs into being good managers and having ownership and delivering their. Report essentially in a way that particular stake stakeholder needs it, which is good advice for any section of a business.

And then obviously the future what is coming next year, what is coming up five, 10 years from now. And I think all of this really relates to a business as a whole, not just development and. You're like, I agree. Totally

[00:28:15] Stephan Schmidt: agree.

[00:28:17] Mikey Pruitt: Yeah. And that is exactly why I wanted to talk with you, Stephan, because I love geeking out about this stuff.

AI in particular is a, a pretty big passion of mine. But in your topic on radical simplicity, it's it's definitely needs to be read. I'll link it here. It definitely needs to be read by everyone, but these are not just. Do not just apply these concepts to code to developers. This is for everyone in business.

[00:28:41] Stephan Schmidt: Yeah, because it just, as you said, I totally agree. Just as you said the downsides of this complexity. Don't care. Do not care about if it's coding or not. The downsides of complexity is that you go get slower because you need to incorporate new things into the complex setup. And the more the com more complex your setup is the more difficult is it to change direction or to add something new.

And the simpler it is, the easier it is to add something new or move in a new direction. And that's independently, just as you said, independently of technology. So if you have a very complicated sales setup, it's difficult to move. Like for some of my customers struggle with very complicated Salesforce setups, for example.

Difficult to move. So yeah, I see this in other departments too.

[00:29:30] Mikey Pruitt: Yes.

[00:29:30] Stephan Schmidt: Awesome.

[00:29:31] Mikey Pruitt: Stephan, where can people find you online?

[00:29:34] Stephan Schmidt: They just need to type amazing CTO somewhere, and then they're probably going to find me.

[00:29:40] Mikey Pruitt: Yeah, amazing. cto.com, inc. That's INKM i.com and also on LinkedIn. So I reached out to Stephan pretty blindly on LinkedIn, and we had a hilarious conversation and then this ended up happening.

So reach out to Stephan. He's a great person to chat with about all this stuff. But if you're a CTO or an engineering director, definitely reach out to improve your skills and maybe get matched with a great company.

[00:30:06] Speaker 4: Thank you.

[00:30:07] Mikey Pruitt: Thanks for being here, Stephan.

[00:30:10] Speaker 4: My pleasure.

[00:30:11] Stephan Schmidt: Great being here.