What did a CTO really do? A CTO, it's about giving the
business the technology needs to be able to drive their success,
Okay. So from that perspective, you're
not simply delivering tools, you're not delivering solutions.
You're delivering a vision, you're delivering A roadmap to
allow the company to be able to grow in scale, at a level and at
a speed where technology never holds up their growth.
Hey everyone, my name is Henry Surya Virawan and you're
listening to the Technical Journal Podcast, the show where
I'll be bringing you the greatest technical leaders,
practitioners and thought leaders in the industry to
discuss about their journey, ideas and practices that we all
can learn and apply to build a highly performing technical team
and to make an impact in your personal work.
So let's dive into our journal. Hey, what's up, My listeners?
Welcome to the Technijunal Podcast, the podcast where you
can learn about technical leadership and excellence from
my conversations with great thought leaders in the tech
industry. If this is your first time
listening, don't forget to subscribe on your favorite
podcast app to get notified for future episodes.
Also subscribe to Technijunal contents on LinkedIn, Twitter,
Instagram, YouTube, and TikTok. And if you have been enjoying
this podcast and its contents, support my work by either buying
me a coffee at Techly journal dot def slash tip or becoming a
patron at Techly journal dot def slash patron.
My guest for today's episode is Alan Williamson.
Alan is the author of Think Like a CTO.
In this episode we discussed in depth how to become a great CTO.
Alan first described what a CTO role is, how the role differs at
different company stages, and the attributes of a good CTO.
Alan then explained the importance of a CTO coming up
with a vision and how we can all improve ourselves in visionary
thinking. He then touched on how a CTO
should work together and understand the expectations of
the CEO. Alan also gave his tips on how
to build engineering teams that can produce high quality
results. Towards the end, Alan gave his
personal advice on how a CTO can deal with imposter syndrome and
the importance of a CTO doing a personal review.
I hope you enjoy listening to this episode and learn great
insights on how to become a great CTO or engineering leader.
Many of us aspire to become a CTO one day and I hope this
episode gives you some practical tips to build yourself into that
direction. And if you enjoy listening to
this episode, please share with your colleagues, your friends
and your communities and leave a 5 star rating and review on Ale
Podcast and Spotify. Your small help will help me a
lot in getting more people to discover and listen to this
podcast and I really, really appreciate it.
Without further ado, let's go to my conversation with Alan.
Okay. Hey everyone.
Welcome back to another new episode of the Technical Journal
Podcast. Today I have Alan Williamson
here. So excited to have you here and
we'll be discussing a lot about the role CTO, I'm sure many of
you are intrigued by this role. So today I hope you have a good
discussion about it. Welcome to the show, Alan.
Thank you very much, Henry. Honored to be here my friend.
So Alan, I always love to start the conversation by knowing
about you first. Maybe if you can share any
career highlights or turning points in your career, that may
be good for us to learn from. Okay.
Well, I think being a child from the 1970s is it where I started
off life with my home computer, the ZX Spectrum.
And I remember convincing my parents to buy me one of those
and for them it was like a month's salary for them.
But anyway, Fast forward a bit, I convinced them and then I
remember I still remember it to this day.
My mother's face when she walked into my bedroom and I had it
opened up and I had things soldered into the back of it.
And what I was doing was I'd figured out how to control my
railway points for changing points on my railway track using
basic in the ZX Spectrum and my mother just screamed blue murder
cause this expensive piece of kit.
I had managed to solder bits onto the back of it and trying
to figure out what and said look, but look at what I've
done. I could I can press this button
and it makes the train go that way.
Now the woman didn't truly get the cheer genius of what I was
doing many, many years. It took about 30 years for her
to finally see OK that spectrum thing was a wise investment from
that perspective. I've always loved this computing
space. You know I found university just
I was like a sponge bring it on, bring it on.
Bring it on. I've never worked a day in my
life. I I truly do love this.
And again, we're in an industry where we reinvent ourselves
every five years. And what I'm doing now was like
cloud, serverless, all that sort of stuff.
I mean, that's not what I was doing 10 years ago or five years
ago or 15 years ago. I actually love it.
So my career has always sort of been more from the embedded side
of the fence. And as I've evolved through
that, the embedded philosophies that we have in terms of memory
constraints, processor constraints, multitasking, etc,
with different areas of the embedded world, it migrates to
the enterprise horrendously well, just at a different scale.
So all of the sort of the hardcore techniques and
algorithms that I was taught 35 years ago is still as relevant
today as as what it was then, but it's just the different
packaging now and and that's why I always consider myself still a
hardcore developer at heart, even though I'm at a CTO level
now as I guide and mentor other teams.
This episode is brought to you by Miro.
Being a CTO or engineering leader requires you to share
your vision, strategy, systems and processes within your team
or with the other leaders and stakeholders.
Not to mention when building them.
You will also need to collaborate interactively with
multiple people to come up with the best ideas, and one tool I
find that allows us to do so effectively and in a fun way is
Miro. MIRO Mirror is an online virtual
workspace and a visual collaboration tool where the
whole team can build on each other's ideas and create
something innovative together from anywhere.
With Mirror, you need only one tool to see your vision come to
life. Strategic planning becomes
easier when it's visual and accessible.
Planning, researching, brainstorming, designing, and
feedback cycles. It can all happen across teams
In Mirror you can quickly start collaborating within 90 seconds
without having everyone registered as a mirror user
before. There are also more than 300
predefined templates you can use to kick start your collaboration
within seconds. So the next time you're looking
for a digital tool to support your strategic planning and
online collaboration, do give Miro a try.
You can Sign up today at mirror.com podcasts miro.com
Podcast. And your first three mirror
boards are free forever when you signed up now.
And now let's get back to our episode.
Thank you for sharing your story.
I think that childhood moment is I think very unique to you,
right. And I think you could always
remember it. But I think also another thing
that I look from your profile right, you have a very vast
experience at the CTO level so to speak, right from startups,
you know SME's and even including from private equity
firm right when you invest in different portfolios of
companies. So today we'll be talking a lot
about CTO role, definitely from your book think like the CTO.
But first of all, almost every engineers that I talk to aspire
to become a CTO, right. But what does it mean to become
a CTO? Maybe a little bit of definition
from you, what is this role all about?
Sure. So you're absolutely right.
I mean, when I first started out, when I first graduated from
university, I didn't even know CTO existed.
I didn't know Chief Technology Officer was a thing.
We always knew what that managing director and the CEO of
a company did. But what did a CTO really do?
A CTO it's about giving the business the technology needs to
be able to drive their success, Okay.
So from that perspective, you're not simply delivering tools,
you're not delivering solutions. You're delivering a vision,
you're delivering A roadmap to allow the company to be able to
grow and scale at a level and at a speed where technology never
holds up their growth okay. And in many respects that's the
hard part that most in my experience of of mentoring and
going through this with other teams, developers and senior
developers have a problem with is because they're no longer
talking to like minded people. They're now talking to the
business, they're now talking to clients, they're now talking to
board levels. So it's a whole new vocabulary
they need. They need to be able to distill
down what is effectively complicated stuff into items
that the board and the leadership can understand and
appreciate. Because frankly, the board does
not care if it's Azure or AWS, does not care if it's Node or
Java or Python or Go. They couldn't give a crap about
the latest framework. They just want to know, does it
make our delivery of solutions to our clients easier or not?
That's all they're interested in.
And sometimes technologists, we get caught up and get excited
with the detail and we don't know how to distill that detail
in a way that says okay, fine, How do I package that to the
board for them to be able to say, wow, we can build a
business off this. We can grow the business using
this okay. Now as it's CTO, you're there
between the technology side of the fence and the business side
of the fence. So yes, you do care if it's Java
or JavaScript or Symphony or hardcore PHP.
What you're trying to figure out is, if I make a decision one way
or the other, is this going to speed up my ability to deliver,
or is it going to slow down my ability to deliver?
Am I chasing the cool new technology that maybe hasn't yet
matured enough that we can bet the farm against?
Because scalability is more than simply how many hits can you
process in a second? It's about how healthy is the
ecosystem around that particular area, technology, software,
whatever it is that I can find resources, I can recruit for it.
I can have a long term vision for it.
And you know, somebody said something to me a few months ago
that that sort of resonated at that level is when a car
manufacturer, for example, introduces a new car into the
market. They have to be able to show and
prove that they can support that car for at least 25 years,
right? There's going to be servicing,
there's going to be all of the warranties and all that sort of
stuff you. And that's because you don't
want somebody to be able to buy a car and suddenly it to be not
supported. We're the same in the software
world. As technologists, we always love
the new shiny, bright toy. We're always going for the
latest version, the latest cool stuff, the latest stuff.
And I suffer the same fate, but I just simply can't turn the
business around. Quick to say, right, we're all
going in this direction now. We're all going in this
direction now because the business is sitting there
thinking we we've got clients to deliver.
By the way, guys, are you creating more noise for us?
Are you creating less friction for us?
So from a Cto's point of view, you're always trying to balance
those two areas. Thanks for emphasizing the
importance of knowing about the business and also the clients,
right, because ultimately the technology that you use or
deploy is actually used for a business impact, business growth
and also user satisfaction, right.
And I like the way that you mentioned that Cto's role is to
come up with a vision and roadmap.
And ensuring that technology doesn't hold up the business
growth, right? I think that's a very key,
important thing for people who aspire to become a technology
leader, not just CTO, Probably, right?
Yeah, and that's always my sort of first litmus test.
When I'm introduced to CTO, I say okay.
Well, here's a whiteboard pen. Draw me your vision.
And if they're blanking, then I'm thinking okay, you're not
quite ready for the CTO level yet.
Okay, a CTO should be able to off the back of their get me a
road map in a vision because everybody should be aligned as
to where they're going on that front.
And if they don't even know what the vision is, then how does the
business know what to plan for and how does the engineering
team know how to align to that vision.
So it truly is CTO is simply not the guy that knows the most,
it's the one that knows how we're servicing the business,
how we're moving towards that and what are we going to look
like in two to three years time, right.
But first of all, I mean in the industry there are so many
different terms of, you know, there's a CIO, there's a VP of
Engineering, there's also Chief Data Officer, you know, Chief
Transformation Officer. There's so many things, right?
Is there any differentiation between CTO and all these roles
or are they just different names, that same flavor?
No, there there is. I would, I mean again, this is a
Pepsi versus Coke argument. There's going to be many people
that will have different opinions on this.
My opinion is that the CTO is the one that's pretty much sits
above the malls because they take all of the stuff.
So Chief Data Officer, Chief Information Officer is probably
one that's maybe sits alongside the CTO, but Security Officer,
all of VP of Engineering, etcetera.
The CTO, at the end of the day, is at the top of the pyramid,
coordinating and getting input from all of those different
quarters in order to come up with that single vision, right?
Thanks for the clarification. Another thing that people also
think about when they have this CTO role, right, is there any
difference for you know maybe a startups or small startups
versus a big companies or even like traditional corporate
companies because I can see variations in the different
types of companies as well. So what do you feel from your
point of view for sure at the startup level?
The CTO is often one of the founders as well.
They're also the ones that are truly building the product.
They're the ones that are coding.
They're the ones that are delivering.
They're the ones that are producing.
They're they're supporting. They're doing everything at that
level. You're not really being a CTO
okay. You're in founder mode.
You've got the CTO title in order to show, yeah, I'm the
tech guy, the other guy's the business guy.
But really you're playing the role of proving the concept of
the startup right. You're truly are in proof of
concept mode because anything that you're building at that
level 9 times out of 10 is going to be thrown away.
Because once you get a greater team around you and more
discipline around you and much more responsibility around you.
And the fact that hey, we've got paying customers and they simply
can't go down. So therefore I just can't
release this code tomorrow. I I've got to schedule it and
there may be downtime. I've got to go through a process
now and if something goes wrong, I've got to be able to roll it
back because I've actually got paying clients that's going to
get angry at me and they may want refunds, etc.
And that's going to throttle my cash flow.
So the discipline comes through a natural evolution, not because
that we love process, it's because we want to guarantee a
quality of service to our clients.
That's why these processes get started and get pushed in the
1st place. So the CTO at the founder level,
frankly, they get to have the most fun.
They have no process, they're a free reign.
They get to play, they get to do all that stuff and they get to
truly forage a new path in the trees.
As that path starts to get more beaten, then the company starts
to evolve, it starts to get either more investment or it
gets more money through simply organic growth.
So therefore there will be a natural evolution that the CTO
then becomes further away from the code or further away from
the responsibility. And often what happens is and
again another little test is can that CTO go on vacation for two
weeks and not worry about opening up his laptop?
I would argue that most startups can't afford that luxury and
again, why not? Everybody deserves a vacation
Okay. So you know, as we get up higher
into bigger companies, even into the public companies.
Yes, the CTO can take two weeks off because there's a team
underneath them. There's a team, I keep saying
him, but it it is sadly the majority of males.
I would love to see more females in in the world and there are
some great examples of female CTO's.
So please apologize, the gross sexualization there, the
fundamental difference there is that you want to be able to have
an organization whereby the CTO is operating at the level that
the business needs of it at the time of the business evolution.
So you're right, the startup needs to have that person
cutting code, but the company is sitting at 5000 employees.
If the CTO is still cutting code and releasing it, something has
gone wrong in the in the line there.
They're probably not a CTO. So thank you for clarifying
that. So I think, yeah, it's always
like a misnomer, right, the title in the startup versus
title in the big companies, they may not be all the same with the
responsibility and also day-to-day job.
So we have discussed a little bit about you know, like what is
the CTO role and you know responsibility and all that.
I mean in your book I read you define a quality of what a good
CTO looks like. You mentioned just like what you
mentioned in the beginning about technology probably is the least
part of the CTO role. But you mentioned interestingly
about the people that actually will make or break your success.
This is probably a bit of something that unexpected for
people to hear as a CTO role. Your success actually depends on
people. Maybe if you can elaborate a
little bit more about this part. What a good CTO do.
Yes. And again, I mean, this often
speaks to the engineering's heart.
We're a very egocentric personality.
You know, we love our little wins.
We love puffing ourselves up. We love to think that we're the
best at things, etcetera, right. And and there's usually the sort
of not invented here syndrome that kicks out here.
Well, I could develop that better.
I could do that better myself. I could oh, I wouldn't have done
it like that. Okay.
The reality is that you should never be the smartest person in
the room. Okay.
You should always have good people that you can bounce ideas
off of and that they can challenge you and pull you and
move you. And somebody that's not scared
to say no to you Okay. And that's why having strong
people is so important to the development of any team.
That when you're bringing on somebody to do a specific role,
yes, they should be able to do that role at a very high level.
But you should be able to give them the latitude and the
responsibility to do their role and for you not to micromanage
Okay. And if you find yourself as a
leader, having to micromanage each of the different layers,
then either you're not hiring correctly or you're not a leader
that's confident to let go. Okay.
Why do I want to hire a SQL developer if I'm always writing
the SQL statements for them? Save myself money, Get rid of
them. I'll just do it.
Okay. But you're never going to scale
A-Team if you keep having that attitude.
So you've got to hire. Well, you've got to hire of a
good quality, but more importantly, you've got to let
them do their job. Okay.
So I think what you mentioned is actually very, very important
for whoever is in the top right, not just CTO, but maybe also
leaders, right, VP of engineering or whatever that is,
is to be able to help people grow and also scale yourself,
right. You can't be micromanaging every
little bits of technology aspects of the organization.
And this is something I find it difficult for some engineers,
right, Because they will never train for it in the 1st place,
right? I mean, there's no university
that, you know, guides you to become a CTO or becoming a CIO,
right? So you mentioned in the
beginning that the most important part for the CTO is
actually to be able to draw the roadmap division.
And I think probably this is also one thing that many people
are not trained of. So maybe can you tell us how can
we actually improve ourselves to go into this route so that
probably become a better CTO. So there's usually one of two
problems that happen when somebody's laying out a vision
well, the first problem is recognizing the fact that you
can do one. You never have to be asked to do
a vision okay and most developers.
Probably have their own vision in a sort of very macro level in
terms of, well, I want to upgrade to this version or I
want to refactor this code. I want to do that.
That is indeed a vision, Okay. It's very short term vision for
sure, but it's still a vision at a CTO level.
You have to think of that vision a little bit longer and a little
bit bit broader, but you have to give yourself license to come up
with it in the 1st place. No, you can fail in one of two
ways. When you're coming up with that
failure, one is not thinking long term enough.
It's thinking more in incremental improvements.
But you're not doing anything big, you're not giving the
business anything to hang their hat on, for example.
And the other one is your vision is too big, that it doesn't have
any detail in it. There's no milestones in it.
OK, You know, perfect example that I'm sure every CTO with
this precise moment, it's got a line in their deck somewhere
saying we'll move the company to AI in three years.
What does that mean? Two years ago?
We're going to move everything onto the blockchain.
Again, what years before that was everything will be big data.
Notice there's a cyclic nature at all of this sort of stuff.
But again, those are two big visions.
What does it mean that I'm going to go onto AI?
Which parts of the business is going to improve to get to
there? What are my steps that I need to
do in order for us to realize that vision?
Simply saying that I'm going to be the best technology company
in the world, not enough. Your vision's got to be able to
lay out plants and how you're going to get there and what are
going to be the benefits to the business and to your engineers
because you're going to recruit for this to be able to do part
of that exciting vision. So a much more down to earth
vision would be for example an organization that has
historically got physical servers in Iraq somewhere saying
we're going to move in the next three years to a cloud enabled
API driven architecture. Brilliant benefits being reduced
cost to the business, more flexibility for spending, easier
way to utilize existing components and not have to keep
redeveloping stuff. That's a real vision.
Now I've got tangible results. And now that every time we're
doing something, every time that we make a decision and say,
okay, we're creating a new file service, I need to buy 4 new
Dell boxes. Hold on, is that getting us
closer to the vision or further away from the vision?
Well, I'm having to buy more boxes, so therefore I'm getting
away from the vision, okay. So let's not do that.
That's not in support of what our vision is, Okay.
So a vision truly has to be factored into every decision
that's being made in order to be realized that the vision is
indeed correct. No, the vision is not a one and
done statement because the business changes, the industry
changes. So it's got to be always
evolving, always changing, but it's not going to be changing to
the point where it's a complete and utter 360 every single six
months that we're going after a completely different vision, a
completely different world. It's got to be true to the
nature. So for me, it's usually a two to
three-year vision with a very lofty 5 year goal as to where
we're going. But you don't want to be going
any further out than that because there are too many
factors that are going to come in that could completely change
the way you operate. Right.
Yeah, I think, I think this is a good guidelines, right.
So two to three years of vision, but not too short, because too
short probably is more like incremental like what you
mentioned, right. It's more project management at
that point, yes. Yeah.
So how can engineers train themselves to be able to come up
with good visions? Because many engineers work on
low level tasks and it's always incremental unless there's a
series of projects being driven from the top.
So how can engineers prepare ourselves better to become a
better CTO? It's a great question, Henry.
So for this one here, I always sort of liken it to the stock
market, Okay. One of the nice things about the
stock market is that you buy and trade stocks and you can
effectively play the game without losing money.
Okay. You can sort of say Okay, I'm
going to go back ten years and I'm going to sort of run my same
sort of methodology or algorithm, if you will, on the
stocks 10 years ago. Would I have made the money fast
forwarding it or I'm going to play with play money in the
current stock market and see if that would have worked or not.
Okay. You can do the same thing with
the Visionary statement. You can go back in a company's
history and say Okay at the time and you know, perfect example
would be like Microsoft at the time that Bill Gates stepped
off. If you were the CT of Microsoft,
then what would have been your vision at that point?
Would you have gone all into the Internet?
Would you have gone all into Azure?
Would you have gone all like what would have you have done
there and did that play out as what was expected?
We've plenty of examples of companies that have failed and
failed to adapt to the existing environment.
Kodak completely missed out on the whole digital phone sort of
stuff, etc. So the CTO there probably didn't
do a great job, but what would you have done?
Now of course you've got the benefit of hindsight, but that
hindsight history teaches us a lot about what's going to come
up. So even though that we're all a
little bit more intelligent and it's easy to look at the likes
of Blockbuster and Netflix, Kodak and the smartphones, is
it? Well, I wouldn't have done that,
Yeah. But at the time, given the
knowledge you had at the time, what could you have done
differently? Nobody can seize into the
future. But at the time, what could you
have done? So as you look at the evolution
of your own company, yes, the developer sitting there who
doesn't maybe have the authority or the visibility, they do have
a history of their own company. They can see how the company's
evolved and even from the point of view of when they first
joined to where it is now, be king for the day.
What would you have done? What difference would you?
What change would you have done? I suppose you're sitting there
going, well, I told you so. I knew that wasn't going to
work. We should never have gone with
whatever the language of the day was, Play that game and and then
sort of look at it. And if you've got a good strong
relationship with your management and your leadership
and your Oneonones, ask them the questions.
So why did you go that fast? I'm interested.
What was the thinking there? Why are we now considered a Java
shop and not, say, Node? Teach me what you did to get
there. A good leader will never shy
away from that conversation. And they could be the, well,
yeah, you know what? At the time, it was the right
decision. But given where the industry's
moved now, we're going to have to pivot a little bit and move
off of that stack and we're going to go this direction or
we're going to go away from servers, going to look, whatever
it is, a good CTO and a good leader will always be mindful of
being adaptive to the current environment and therefore will
change. You never want a person in that
role. It's just so frigging stubborn
it will work. I just need the rest of the
world to catch up to my vision. Okay, no, we're not Amazon.
We don't get the set certain tones.
You have to figure this out by ourselves.
So from that perspective, ask, ask, ask and doing a respectful
way, you're not sort of going to your mind, well, why did you do
it this way? I wouldn't have done it that
way. No, you're you're listening,
you're listening. So make the conversation
fruitful and understand their data points because the bit that
you're probably not appreciating is the business side of the
fence that you may not have exposure to okay.
You may not be seeing certain details that at your level
doesn't make any difference to your job.
So therefore you wouldn't get to see the balance sheet, you
wouldn't get to see the current sales sheet, you wouldn't get to
see the forecast because it doesn't help you in your job
really. But as you're laying out
division of where it's going, then yes, you do want to start
that. And areas that we've seen before
is where a CTO would say, right, we're now moving towards an API
driven architecture and you get people sort of thinking, well,
why aren't things working the way they are.
I know this code is doing well. What they may have missed is
that clients are now starting to ask for the API so they can go
deeper into their organization. And any time that a client asks
for an API from your organization, you want to run
100 miles an hour towards that request because that creates a
very sticky client. Now that's the sort of tools and
the sort of way that a CTO can truly help the business get a
lot more. Integrate it with their clients
by providing them tools that the clients are looking for.
As opposed to saying, well, we don't do APIs, just give us a
file upload and an FTP directory.
How old school is that? So when it comes to visions,
when it comes to figuring out what a vision should be, ask,
ask, ask. Thanks for sharing this
interesting technique right for all engineers out there.
If you want to exercise your socalled visionary skills, look
at the evolution of your own company.
Make sure you probably analyze some of the key decisions,
whether it's right or whether it's wrong, right.
Maybe you can analyze and use that as your knowledge right?
And maybe even ask your leaders if they are supportive to share
with you, right? I think these are all great,
great learnings. Don't forget that you can also
learn from the past history as well.
And I just wanna quote a few things about, you know, you
mentioned about visions, right? Vision is not just one project.
So let's say you wanna develop this API driven technology,
right? It's not just once done and you
know, dusted, right? So it could be a series of
projects 2-3 years. That's kind of like your rough
guideline. And also one thing that is very
important, I find that it can be delivered and celebrated by the
people as well, right? So it's not something that never
celebrated. Exactly.
And that's very important because otherwise you're just a
snake oil salesman, you're never delivering, you're always
delivering tomorrow, you're always delivering tomorrow.
One company that suffers from that big time would be Tesla.
I mean I was a Tesla owner and I got sick of self driving is
coming next year. No, it's coming next month.
No, it's coming next year. Self driving's still not there.
It's like okay. Elon, can you actually deliver
on a product? I I don't think you can.
So the cyber truck, it may not be released this year, it may be
released next year. I mean, they are the never
release company. Now they do eventually get
there, but think of the fatigue that that puts on your customers
and your clients and all that sort of stuff.
So a good vision should not be too lofty that it cannot be
celebrated when it's delivered. Right.
So yeah, please do think about milestones when you set up your
vision. Don't think of too far ahead and
you'll never deliver some incremental milestones in the
journey, right? So one thing when you mention
about business, right, definitely CTO needs to talk
with other leaders, especially CEO right?
And it could be also their boss, right?
The CTO boss, Yes. So this dynamics is for sure is
very interesting. So maybe a little bit of wisdom
here. How do you actually work
collaborating with the CEO? Any gutters that CTO must know
about in order to maybe collaborate better?
It's the hardest part of the role, Henry, to be quite honest
with you. Because the CEO, while you're
the CTO and you've only got the responsibility of the technology
side of the fence, they have the responsibility for the overall
company, right. We are just one but leg that
reports into them. They have many other legs and
they're trying to straddle the vision for the company's whole
delivering to the clients as a whole, putting together the
growth plans etcetera. And a good CTO has got to
appreciate that there are small cog in a much bigger engine.
They have to serve everybody towards that end goal and to
also have empathy as to what the CEO is trying to accomplish.
And that is, they don't want to micromanage you any more than
you want to micromanage your people, okay.
They want to be able to look to you and say, is this done?
And you'll say, yes, we'll get that squared away.
You don't need to micromanage me here on this front.
I understand where you're coming from.
I know what you're trying to do and what you're trying to
accomplish. Now the flip side of that is
understanding the level of detail to which your CEO enjoys
to have a conversation with. And I've worked with many
different ones where some are truly business level.
They don't want any details as to what stock we're doing, what
we're doing, da, da, da, da, da, da.
They trust us to do what we're supposed to do.
Then there are others are a little bit more interested.
They would actually like to know well what are we using, are we
cloud, are we data, why are we going this direction, Dadadada,
have you thought of this, etc. Those are wonderful CEOs to work
with as well. So it's finding that balance
with that CEO and then talking in their language to know that
okay, they're interested at a sort of let's call it an API
driven layer. But do they really care if it's
driven by Java Node or third party service?
Not really. So I don't need to go into that
level of conversation when I'm talking to them.
And the other important part that I often sort of spend a lot
of time mentoring people with, and I go over this in the book
as well, which you've probably read when CEO was asking you a
question. Most of the time they're not
asking the question for themselves, okay.
They're asking the question on behalf of probably somebody else
okay because they have to stand up at a board, or stand up to a
client or stand up to other leaders of the business to be
able to effectively communicate what you're telling them for
their audience. So therefore think about your
answers in such a way that you give them the talking points to
make it easier for them to convey their results.
So the last thing you want to do is to get sucked into a whole
buzzword laden geeky explanation.
Because roof, it may go over the CEO's level, but sure as hell
it's going to go over the board level, right?
They don't care. So when you're talking, talking
the language that their audience is going to be in, and that's
very, very important. And a good CEO will help guide
you in that respect, particularly when you're first
starting out in that journey. But they will come to respect
you and start to sort of look forward to your conversations,
your one to ones, your quick five minute calls, etcetera.
Because they know that you're going to be able to distill this
down in such a way that A, they can understand it and B, they
can envelope that into their own words and then go and do what
they need to do with that piece of information.
The last thing you want to do is, yeah, the website went down
because Java went through a upgrade and we didn't have the
blah, blah, blah, blah, blah, blah, blah, blah, blah.
And all they heard was the website went down.
It doesn't help them understand what what we're doing and how
we're mitigating that future problem as part of that example.
So talk to the CEO in their language.
And that's the hardest part that a technologist has, because you
talk to any technologist. We love our buzzwords.
We love our geek speak because, hey, it makes it sound way more
impressive than we really are, makes it sound way more
intelligent than we really are. But in a business setting, you
don't get away with saying out a buzzword and then thinking,
well, it's your fault if you don't know what that buzzword
means. What do you what do you mean you
don't even know what that means? Well, you must be be gone with
you, Okay. We have a very arrogant attitude
at times and we do this in sort of microaggressions as we talk,
as engineers talk with each other and what have you, we
subconsciously do it. It just what happens.
You don't get away with that at a business level, okay, because
you're there as a team. You got to empower your CEO.
You got to empower your CFO. You got to empower everybody
else that's at the same level as you to know that, ah, don't talk
to Alan because, Jesus, I feel stupid after every conversation
I have with him because he just hits me with lots of buzzwords.
You've failed as a CTO when you're getting that
conversation. Right.
So I think it's important to know what success to them,
right? So like explaining things in
their own language as well. Don't get too much details as
well, especially the jargons, the technologies, they may not
get it anyway, but they also want to convey your message to
other, maybe board directors or maybe other people who are
interested in the growth of the company, right.
So thanks for sharing all that. So one aspect is to be able to
understand what CEO wants, translates that to technology.
The other part down there is actually to build a great team,
right? Maybe have the leaders under you
as well who can perform and execute your visions.
So any tips about building and managing teams for engineers
here? Yeah.
And I think like to your point, you know, a CEO will say that
that's assume we're sitting in New York at the moment.
We're driving what I need to get to San Francisco.
That's the level of detail he's going to give you right now.
As a CTO, you got to figure out how are we getting to San
Francisco? Are we going to fly, We're going
to take the train. We're going to take the car.
If we take the car, how many cars do we need?
Da da da da da da da da. As you think through the ask of
what the CEO is doing and the spirit of what the CEO is
saying, that then dictates the team to which you need in order
to get to that vision. And as long as everybody is
completely clear as to where they're going and what role they
play in that particular journey, then building the team up
becomes relatively simple because you know exactly what
you're looking for. I've been quoted many times
before that I'm not a big believer in the full stack
developer Mentra, because it's like okay, You're Jack of all
trades, master of none. But in this journey, do I need
more of an API person or do I need more of a web person?
And frankly, if those were two separate people, would I be able
to get there faster? So this notion of building up a
team of effectively Jack of all trades, master of none, isn't a
good way of building a team. You want disciplined people that
know their particular area very well, that know that they're
going to deliver at the best level, that this is the best
code or the best query or the best structure or the best
infrastructure that I can build because I eat, breathe and live
this particular discipline. So therefore, I'm of course
going to be far better than somebody that's just got a
cursory view of it as a whole. And as the company grows, you
have more budget to allow yourself those very strong
disciplined areas. As a startup, of course you've
got to have that one person that knows everything.
You can't afford to buy each of the different expertise.
But as the company evolves, you get to a point where you say
okay, we're now a database company because we've got like
literally terabytes of customer data sitting in databases.
Maybe we need a SQL person, maybe we need a dedicated DBA to
be able to manage this, to optimize our queries, that eats
and breathes and lives this, whereas before said it wasn't
that big a deal in our company, so therefore we could have made
do so. As the team evolves, you will
find where you need that very disciplined and focused
expertise to maximize the resources and again to not get
in the way of the business delivering what they need to do.
Right. So thanks for explaining how to
hire the team, right. Especially the different stage,
different growth, right, requires different kind of
people, right. Maybe in the beginning you have
more full stack engineers, as you grow, maybe you need more
disciplined people. So the other aspect apart from
just skill set is actually how to execute, right?
How to make sure the team aligns.
That's the first thing because sometimes it's very hard to
align and how they can execute it with high quality.
I think this is probably $1,000,000 question for every.
Technology. It sure is.
Quality is. It's my #1 bugbear, to be honest
with you. Quality to me, Henry, is kind of
like the old school. How you treat your waiter is how
you treat other people. It's kind of like that litmus
test, how well you're going to do it.
Same thing for me. I like to see quality at all
levels. So if, for example, you're
building a web form and there's a little bit of inconsistency
with UX, or there's a label that's misspelled or there's
something that's just not quite right, why was that little
simple thing not corrected? And if you missed that little
thing, then what did you miss in the back end of the stuff that I
can't see? What shortcuts did you do back
there that I'm never going to see, Maybe one in every hundred
execution path it'll get triggered.
So okay. So for me, that's the litmus
test. So if a team is truly focused
and gathered around quality, then it trickles down to every
level and what we all like in any product or anything ticket,
your favorite car, your smartphone, anything, there's
that one thing that it does that you go that's cool.
How I really like that that that's a nice little touch Okay.
And for that reason, you're no loyal to that particular thing
Okay because you like the way it does it.
You create that relationship with it.
We sometimes forget to do that as software engineers and as the
products that we're delivering, we're too focused on getting the
clinical solution over the line. We sometimes forget about the
spirit of what it is we're delivering.
And I like to instill that sense of spirit and quality into the
things that we're building so we can anticipate what the end
user's going to need. So instead of us just delivering
the bare minimum, we give them that little extra, extra little
touch that makes it easier for them to fulfill their job.
And again, it comes down to quality.
Empathy is another word that I use a lot on a weekly basis.
Have empathy for the person that's using your product now.
It could be the person that's reading the report.
It could be the person that's doing the data entry.
It could be the person that's installing your software.
Have a little bit of empathy. What can you do to make their
job that little bit easier? And it could be as simple as a
DevOps guy writing a read me file to make it easier to be
able to turn on this service. Okay.
Whereas in their head to thinking, oh, but this is so
goddamn obvious, why do I have to even write this out?
Well, you probably don't, but there's going to be that one
person that one day is going to look at your read me
documentation and go, oh thank God, he just saved me hours
worth of work. That's wonderful.
Thank you. So that little bit of empathy,
that little bit of quality check does help a lot in building up
confidence, building up faith and building up stickiness of
your users. When something is delivered,
they look forward to the next release.
They don't fear that, Oh my God, what have they broken now from
that perspective? And again, I go back to Tesla.
Every time they did a major release in my car, I knew that
three days later there'd be two more releases coming because
they'd have to fix the stuff that they released the first
time. I'm speaking from like a 2 year
old releases. Maybe they've got better, but
they locked me out of my house for three days because I
couldn't use the garage door opener to be able to get into my
house. I was like 2 days later they
released a fix and it's suddenly my my guy's door started to work
again and it's like okay guys, there is such a level of lack of
quality that was being pushed out, but we have that at all
levels, Okay. And you know, we no longer
distrust the Windows Update. We no longer distrust the
Samsung update on our phones because it just works.
Same thing with our Chrome update.
It updates in the background because we just have faith that
it it just works. When was the last time somebody
updated their Chrome and it completely destroyed everything
that they were working on? Rare.
Very rare. We as software engineers have
got to get back to that level of quality.
And it all starts with the team. It all starts with everybody
knowing that that's what you're needing to be doing as part of
your role. And collectively, it's how we
build a great product. It's how we build a great team.
We never want to get into a situation where we say, oh, but
QA will find it, QA will catch it.
No, QA is not your safety net. Okay.
QA, if they're doing their job right, should never find
anything. They should be that level of
assurance that Yep, you did have a good quality.
You know the clue is in the title.
Quality assurance. Yes, I'm assuring the quality is
there. Too many teams rely on QA to
find the bugs, to find the stuff and for them to be the I got it
off my JIRA ticket list. It'll come back to me if it's
really broken, knowing fine well it is going to come back to you
and you should have done it right in the 1st place.
So yes, I believe a good QA team is not your safety net.
It's there to assure that the team is indeed producing quality
and it all comes down to everybody's responsible for
producing the quality. Thank you for emphasizing that
quality is at all levels, right? I think one of the aspect of
Cto's to ensure everyone, every team understands about this
aspect. And be able to deliver quality
results, right? Not just, you know, like
delivering features over features, right.
Another aspect that I want to ask you about CTO is actually
sometimes as individuals, right, they are suffering from
impulsive syndrome, right? Because they can't know
everything for sure in the technology.
You're saying that they keep reinventing themselves every
five years, right? So first of all, how do you
manage yourself as a CTO? Dealing with the busser
syndrome, dealing with uncertainty and dealing with not
knowing the maybe the results of the visions that you are taking.
So maybe a little bit of guidance here for great
question, Henry, and you know, imposter syndrome.
I had imposter syndrome 5 minutes before we had this
interview. Am I going to live up to Henry's
quality? Am I going to live up to the
quality of the guests that you've had historically?
Did I have selfdoubt? Of course I did.
Everybody has it. We all have it.
And it's that stage fright. It happens.
So how do you deal with it? Oh, frankly, you don't.
You just learn to live with it. Okay.
You got to live with the fact that you don't know everything.
You got to live with the fact that some days you're going to
wake up that everybody's going to be talking about a new
buzzword and you have no clue what they're talking about and
you're going to feel dumb, dumb, dumb.
Because I've heard this buzzword 4 different Times Now for four
different people. I'm thinking, how the hell do
you know about that buzzword? Well, I I have no clue what
you're talking about. Okay.
So embrace that and actually run towards it.
And instead of sort of trying to bluff your way through a
conversation and thinking, yeah, no, just say guys, I have no
clue what you're talking about. Somebody educate me here And
what you'll probably find is that most people are probably
playing the buzzword game is themselves and they don't really
know it, truly at a level themselves.
I've discovered this a lot. How somebody says something
confidently can make you convinced that they actually
know what they're talking about. So get past that confident layer
and simply be vulnerable to ask questions.
I don't know what you're talking about, Okay.
And there are certain times that this will happen inside of an
organization. You know, we've we've all been
there. We've been talking to somebody,
we've maybe met them at a party, we've maybe met them at a
meeting, but it's gone beyond that point.
We think I should have remembered the name at this
point. I've forgotten their name.
Now. It's going to feel real awkward
when I asked them, but what's your name again?
Because it feel awkward. That's imposter syndrome.
Okay. Every so often in a company that
you may have been there for a number of years, a term will
come up and you're thinking, I should know that by now, but I
don't. Can somebody help me?
What? What?
What do you actually mean by that?
And again, it's just laying yourself to be vulnerable and to
be that person that is comfortable holding their hand
up a class and saying, teacher, can you go over that one again?
Because I don't know what you're talking about, because if you
have that confidence, then I can guarantee you that there's
probably somebody else in the room that's a little bit nervous
to hold their hand up and ask the same question.
But the nature of you asking it, they will get their answer as
well and hopefully will inspire them to see that, hey, I asked
about this particular term. People seem to be receptive to
it. I didn't get fired.
In fact, I increased the knowledge of the room.
Maybe it's okay for me to do it next time.
So the whole imposter syndrome is just acknowledging the fact
that you don't know everything, you won't know everything, but
don't be scared to ask the question there.
And then when something new does come up in terms of how one
tries to get ahead of some of this stuff, and I pull out a
couple of examples in the book as well.
If you're in a given industry, then there are going to be
certain disciplines within that industry that you should
probably keeping an eye on. And that can be done very easily
through trade journals, websites, etcetera that you read
maybe once or twice a week, etcetera.
You just to hear what's going on.
But if you're not, say for example, in blockchain or
crypto, then don't be concerned about what's going on in Bitcoin
that particular week. Don't feel stupid or don't feel
dumb that you don't understand what the latest and greatest
contract protocols are going to be for blockchain.
No, you're allowed to not know that.
OK, just like embeddeds that I'm allowed not to know certain
stuff because it's not within my field.
If, however I'm in this sort of database field and I'm not being
kept up to date with the latest releases of the particular
server that I'm on or the particular trend that things are
going on, then yeah, that's a problem.
Don't try and consume the full space.
Consume the space to which you're focused in on.
Give yourself the license to say I'm okay not knowing about that.
It will come up as and when I need it, so I'm not going to
stress about it. Okay.
And as long as you're open to new knowledge, because yes, we
do reinvent ourselves every five years, but that doesn't mean
that suddenly on the 5th year we get all of this knowledge
suddenly inherited to us. No, we get pointers that things
are starting to go off in a different direction.
Things are starting to go. This buzzword keeps popping up
time and time again. Maybe I need to learn a little
bit more about that, give you an example that that I've had to
sort of come around in the last six months.
Machine learning and AI, yes, knew all about that.
But generative AI, we keep reading about that all over the
place. What is this generative AI and
what's it, why are we now calling it that?
I had to go and learn about that, had to go and read about
that. Now that was everybody was
starting to drop it into buzzwords.
And I said, well, what's the between that and say, machine
learning and AI? And you get like blank
expressions and so you're clearly not the person to ask
about that. Okay, let me go and ask somebody
else. I eventually found that person
that could sort of sit me down and say, Okay, let me take you
through. And now I suddenly feel much
more knowledgeable on it. But that was an evolution.
That was me laying myself bare to say I have no clue what
genitive a I really. I think I've got to guess at
what it is. But I I'm not confident enough
to to use it in a conversation. Somebody explain it to me.
We're going to have that every single year and there's big
seismic shifts every five years as as you know, so don't get
stressed about suddenly needing to know everything about
everything on a five year window.
Embrace the learning, embrace the lack of knowledge in certain
areas and use that as a mechanism to run towards but
imposter syndrome. Live with it.
There's no cure, yeah. Thanks for emphasizing that.
We have to live with the Impulsive syndrome, right.
And I think in your book you mentioned that it doesn't mean
that we have to be at the bleeding edge, but we have to be
at the leading edge, right. So not enough probably when the
time you really need it and you can dig deeper, right.
So I think thanks again for reminding that.
So apart from dealing with the impulsive syndrome, which you
cover really brilliantly just now, right.
So I have one other question about managing yourself as a
CTO. So most of the times as an
engineering leader, right, most of the times when you're at the
top, it can be very lonely up there, right?
So with very limited input signals for people to give you
feedback. So maybe my next question is how
do you actually review yourself, maybe your performance, maybe
your skill sets and how can you improve in order to also be
effective? CTO OK, it's a great question
Henry. And I think there's a couple of
answers and a couple of techniques that I do personally
to keep myself in check as it will.
The first thing I do is I keep a journal.
I keep a dear diary. Now that journal is ironically,
it's actually a Google spreadsheet.
It's linked to every device that I've got, every browser, etc.
And it's got a line item for every single day and a column.
It's for free for the various different things.
Now what I do in that journal, it's not like a, you know, dear
diary, he didn't speak to me again type sort of thing.
It's more of a I track my emotions, okay I attract, did I
feel I had a good day or a bad day.
And if I had a bad day, what made it a bad day?
Did things not go the way I wanted it to go?
And if things didn't go the way I wanted it to go, then how
could I've done something differently afterward?
So what I do is I don't try and analyze the journal, frankly, on
a daily basis. What I do is that I collect all
that data during the week and it could be silly things like had X
number of meetings, da, da, da, da, da, various emotions, etc.
It's more like tags, if you will.
And then at the end of every week, as I'm planning my next
week out, which is usually Sunday evening or Sunday
morning, I look at the week that just gone by and say, okay, ha,
what could I have done better? What did I do?
Okay? Which members of the team
impressed me? Which members of the teams
caused me problems? Which meetings were productive?
Which meetings were not productive?
What new things came in that were completely out of my
control that I had to do something about.
So I use my journal very much as that touch point.
And I also like note things like when I was traveling, where I
had to go, did I have doctor appointments and all that sort
of stuff. Because it's funny how I just go
for every time I go near the dentist, which is my every four
months I go to the dentist. Any meetings I have beforehand
are generally not good because I'm anxious about going to the
dentist. But that's a data point I didn't
realize I had for such a long time until I tracked it.
So it's as silly as that may seem.
So I do that. Now, the other secret weapon
that I've got, I have a good strong right hand.
I'll, I'll name him Ryan Birch who has the license and has the
authority to say to me, well, you didn't do that.
Well, Okay. He's my man.
That is pretty much in a lot of my meetings or our orbits
collide a lot. But he's the one that I will
always use as my litmus test to see.
Did that go well? Did that was was that right,
etcetera? No, he can't Like, he reports to
me. Yes, but we have that strong
relationship whereby he will tell me how he feels.
Sometimes he's right, sometimes he's wrong.
But to have that trusted third party person, that's not just
going to be a yes person to you, that's going to say, yeah boss,
you probably were a little bit strong there, or maybe you
weren't strong enough or I have no clue what the hell you were
talking about there. So maybe you want to reclarify
that again to see how well that worked, Okay, because in your
head you think you've communicated perfectly and we
don't sometimes feel how we came across and what Ryan does
beautifully, he never tells me at the time in the meeting.
It's always a one-on-one very confidential.
I trust him, right. I've also got a little visual
cues from him that during the meeting I can read his face at
times and say Okay and and right.
So having that trusted person huge, and he has helped me a lot
and that I think is, is, is something that will help with
keeping a check on yourself. So between that and the journal,
what I'm basically saying, Henry, is be open to feedback,
be open to the fact that maybe you have areas to improve,
nobody is getting it right all of the time, Okay.
And different external factors will affect your moods because
hey, we're not machines, we are emotional beings.
We're affected by our environment.
So therefore, if one can be a lot more mindful of your own
environment, well, that that would usually spill over to
being a little bit more empathetic to the people that
you're trying to lead. If your rock star developer is
suddenly having a bad week, maybe there's something else
going on. Maybe there needs to be a bit
more latitude given because something now you don't need to
get into details as to why it's going on, but be empathetic to
the fact that hey man, there's clearly something that's
changed. Do you need a little bit more
time? I don't need the details, but do
you need a little bit more time? That is an empathetic leader.
So that is somebody that's truly keeping yourself.
But it starts with yourself. Can you be introspective to
yourself? And can you be honest with
yourself? Very interesting answers.
I was thinking that you might want to say, you know, find a
mentor, read the books and things like that.
But actually you first advocate having a journal.
Surprisingly. Actually, I do have a good
journal as well. I use an app for that.
And sometimes you can find interesting insights just by
tracking your activities and the So what sort of things do you
track, Henry, when you say that? So that's wonderful.
I'm glad you do that. Yeah.
So the first thing is about mood tracking, right?
And then I most of the time I put the high, not so much
highlights like interesting activities that I do.
So things like for example meetings, playing sports right
and activities that I also want to track as habits.
So all these things I normally track in an app called De Leo.
And the good thing about the app is that it also gives me
statistics and you know, interesting visualization of how
I do those stuffs. So sometimes it gives me a very
good interesting insights. Fascinating.
I'll check that out. And yes, to your point, I do
have a mentor. You know, Jim Millbury is my
mentor. He's been a mentor for the past
sort of near on 20 years. I've known him for over 25
years. I dedicated my book to him.
He's my guy that I ring up and say hello, How do I handle this
for sure? And he will tell me he doesn't
sugarcoat it. And the second interesting thing
that you suggest right find so-called the right hand right
maybe in your team it could be direct report.
Although I know that some maybe leaders may not have access to
this trusted right hand person. It depends on how you build
trusted exactly yes. Yeah.
And I think it's really interesting if you got that
person in your team as well who can give you the cues and give
you feedback. I may not necessarily direct
feedback in the activities of itself, right, but maybe through
private one on ones and things like that.
So I think that's a very good, interesting advice that you give
for all of us engineering leaders out there.
So thank you so much for all these great, wonderful coverage
about think like a CTO due to the interest of time, right.
We have to cut it short. And I'm sure we could talk all
day long about being a great CTO.
I have one last question because you know, this is a custom
question that I normally ask for all my guests, which I call the
three technical leadership wisdom.
You can think of it like get an advice you want to give to the
listeners here so that we can learn from you better.
So what will be your 3 technical leadership wisdom, Alan?
OK, that's I, I I love that that question.
First one is listen. Listen to not only your own
team, but listen to the outside because they're your real
customers. Listen to management, listen to
that sort of stuff and don't be quick to offer solutions as part
of that. Sometimes we jump to, I can
solve that, I can do this. Oh, you need to do it.
We can use that tool. We can use this.
No, just listen. And the more you listen, the
more data you're receiving. So the better validated solution
that you have. Now you may quickly jump to a
solution in your head. Great, continue to listen.
That's number one key. And something I've had to learn
myself. Because as a young engineer I
was always quick to solve a problem, quick to think.
I was like, everything is easy, everything can be done.
But the more I listened, the more I learned.
The second tip I would have is assemble the right team around
you. You are not going to do
everything yourself. Therefore you have to rely on
others and you have to rely on what they are bringing to the
table and the skill sets that they are doing.
So the the first thing that you have to do as a leader is
determine what skill sets do you need to be around that table for
you to be successful in your role as you deliver for the
company as a whole. So very carefully and
strategically determine that skill set and then recruit
accordingly. And at sometimes you're going to
have to make hard decisions because there are certain people
that you think, I really like you.
You've done a great job for the company but your skill sets just
don't match what's going forward.
And we're going to have to have that conversation square peg
round hole does not work. Get the right people by the
right skill sets. And then finally my last
leadership thing is and just finished I've just I've just
finished reading the the the the power to fail book which is the
whole history on General Electric.
It's been absolutely fascinating.
The the author goes through each of the different CEO's and he
focuses of course on Jack Walsh which is the considered to be
the greatest CEO in the world. And his big tip, which I have to
say I've I've embraced myself and I have been doing it a long
time and it was kind of like oh, Jack does it as well.
So I must be on the right track as well.
That sort of validation stuff, which is make sure you have
people around you that will argue you want people that will
actually put up a strong argument with you, will not be
intimidated by you or your title or your role.
And it doesn't matter if they report directly to you or not,
but have people that will actually put up an argument.
If you don't, then you're never going to evolve to the right
solution. And what's interesting about the
Power to fail book is that Jack was was one of these people that
love to have an argument that was never a personal argument,
it was a argument around the particular issue of the day.
And apparently Amazon works in the same manner as well from
what I've read from their books. But the following CEO that came
after Jack, he didn't like the argument.
He surrounded himself with people that were effectively,
yes people and therefore an awful lot of solutions were
effectively never really vetted out.
We're never really, we never really kicked the tires on those
at General Electric and it was absolutely fascinating to see
the two different CEO's being contrasted back and forth from
one another. So again, it's have people argue
and and that tip came from my mentor a long, long, long time
ago which was make sure people are not scared to stand up and
say, Alan, you're wrong and here's why I think you're wrong.
That's my top three. Thanks for sharing this wisdom.
I like the last one. Right?
Have people to argue, Of course, in the spirit of good faith,
right in the best psychological safety as possible, right?
Otherwise, it will be just a debate and fight internally.
You've got to argue with data. You're not allowed to argue with
emotion. That's the key differentiation.
Right. I think that's a very good tip
as well. So for people who you know, you
feel that you don't have enough argument.
Especially for engineering leaders, maybe create that
ecosystem or you know, culture in which people are not afraid
to give their feedback as honest as possible, right?
And you do have to listen and you know, maybe acknowledge even
though maybe you don't agree. In the end, I think the best
ideas should win, right? Not just the highest person pay
opinion, you're absolutely right.
So Alan, it's been a wonderful chat.
If people want to continue this conversation, is there a place
where they can find you online? Alan dot IS keep it simple and
you can also find me LinkedIn. Right.
Very short and simple. And I'll put it in the show
notes as well. So thank you so much for your
time, Alan. So thank you for writing the
book. I think this is a very, very
rare book for people who are the CTO, not many resources I find
that will give people advice or insights how you can become an
effective CTO. So thanks again for that.
Thank you again, Henry. Thank you for listening to this
episode and for staying right until the end.
If you highly enjoyed it, I would appreciate if you share it
with your friends and colleagues who you think would also benefit
from listening to this episode. And if you're new to the
podcast, make sure to subscribe and leave me your valuable
review and feedback. It helps me a lot in order to
grow this podcast better. You can also find the full show
notes of this conversation on the episode page at techlyjuno
dot dev website, including the full transcript, interesting
quotes, and links to the resources mentioned from the
conversation. And lastly, make sure to
subscribe to the show's mailing list on techlyjuno dot dev to
get notified for any future episodes.
Stay tuned for the next Techlyjuno episode, and until
then, goodbye.