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.