Navigating the World as a CTO: Insights & Strategies with Alan Williamson

Miko Pawlikowski hosts a comprehensive discussion on the role, challenges, and insights of being a Chief Technology Officer (CTO) with expert guest Alan Williamson, author of 'Think Like a CTO' and partner at New Harbor Capital. Williamson shares his journey into the CTO role, the misconceptions about the job, and the critical importance of understanding beyond just technology to succeed. Key topics include the vital first 100 days, the evolution from technical expert to strategic leader, building and managing teams, making impactful tech decisions, and preparing for company growth or acquisition. This episode is a guide for current and aspiring CTOs on navigating their roles, leveraging their positions for business success, and evolving with their companies.

00:00 Welcome to Hockey Stick: Unveiling the CTO Role

00:51 Alan Williamson: From CTO Struggles to Author

02:18 The Real Scope of a CTO's Role and Challenges

08:12 The Evolution from Startup CTO to Corporate Leader

21:55 Does Every Company Need a CTO? Debunking Myths

29:16 The CTO's Journey: From Vision to Execution

37:43 Harnessing Thought Leadership in Tech

37:58 The Power of Blogging for CTOs

41:24 Strategic Hiring and Team Building Insights

51:31 Navigating Technical Decisions and Open Source

01:03:56 Effective Documentation Strategies

01:12:01 Closing Thoughts and Resources

I'm Miko Pawlikowski and this is Hockey Stick.

Today we're talking about the role of the CTO, the Chief Technology Officer.

Who is that?

What's their job like?

And why is it so hard to survive the first 100 days in the role?

To answer these questions, I brought in an expert on the subject, Alan

Williamson, the author of the book "Think Like a CTO" . Alan is the partner

of the Portfolio Operations Group at New Harbor Capital, and through that

private equity experience he's seen mentored and worked with countless CTOs.

If you think of becoming a CTO, Alan has plenty of advice for you.

Welcome to this episode and please enjoy.

Miko, it's an absolute pleasure and honor to be here, sir.

Thank you very much for inviting me.

Absolutely.

Alan, would you like to tell us a little bit about yourself and how

you ended up writing this book?

Yes.

so basically I was thrust into a Chief Technology Officer role.

I looked around and discovered there was nothing to help me figure out

what the hell this role was all about.

so from that perspective, I've always kept detailed notes and journals, et

cetera, as I go throughout my life.

and I thought, I'm going to start documenting this journey.

and after 10 years, as it were, I had enough material and I had enough stories,

war stories, successes, failures, to be able to bring that together.

And through my work with various private equity, I got the opportunity to meet

many other people ascending the same ladder that I was ascending and both

helping them, learning from them,

So in many respects, I cover a very large spectrum of subjects.

And frankly, your typical CTO will not need all of the chapters.

They'll need maybe 70% of the chapters, depending on the

company that they're with.

So the book is purely there to help the upcoming CTO to

figure out what is the role?

What do you need to do to succeed in the role?

And the sort of.

range of subjects that you're expected to deal with when you are a CTO.

Most people assume a CTO is just basically a senior developer or a

senior engineer, but in many respects it's the complete opposite of that.

And that's the sort of culture shock that a lot of engineers

face when they're looking up to see, 'is this something I can do?'

to be very honest with you, when I first saw it, I thought, that

sounds a little bit pretentious.

But then, as I was reading that, I realized that, pretty much

everybody who works in tech, they obviously know who CTO is.

And then you ask them questions.

"So what's the scope exactly, and what should they be doing?"

And it gets a little bit more fuzzy and a little bit more vague than it should be.

So it's great that you just went ahead and wrote a book about that.

the big shock that most people realize is how little technology most of

your day really is involved with.

what you're usually doing, particularly of companies of certain sizes.

You're trying to help the company fully utilize technology in such a way that the

company does not get hindered or slowed down through its use of technology.

So if we take a step back, for everybody who is already hooked, just

go to manning.com and get the book.

It's called "Think like a CTO".

Once again.

But for anybody else who needs a little bit more convincing,

What does CTO actually do?

The chief technology officer, as per the sort of phrase, sits at the c-level.

And from that perspective, they're there to help the CEO and the rest of

the c-levels determine what technology can do for the company and what

opportunities can that technology open up?

What friction can that technology remove and how best utilize the core assets

of the company, which is usually data.

in order to provide more value to the client.

one of their biggest goals is to lay out of roadmap or a vision statement,

and I go into that in extreme detail in one of my chapters, to figure

out where are we going as a company from a technology point of view.

What platforms am I investing in?

what features am I looking to develop?

there's lots of different types of CTOs.

But, you usually have a company that's either producing technology, and

therefore the CTO's got a much more hands-on architectural engineering role.

And then you have CTOs that are more consuming technology and they're more

aggregating technology from many different vendors, many different sources, but

still providing an overall roadmap as to where we're going as a company.

I believe in your book, You gave the analogy of chess, as I was reading it

for the first time, I completely misread it because they all CEO, CFO, CTO, and

I just assumed that the CTO would be the queen, but that's not the case, is it?

I believe that the CFO is the queen, right?

So in the game of chess, the queen is the most powerful piece on the

board, because that piece can move anywhere, any direction, and any

number of squares at the same time.

A king can only move one piece at a time.

in business parlance, the CEO sets the big direction for the

company, the big decisions of where the company is going to go.

And in many respects, They shouldn't be able to move quickly.

They shouldn't be able to go to the other side of the board quickly,

leaving everybody else behind.

Because part of the CEO is to bring everybody along with them.

So therefore they've got to be far more strategic, far more calculated

in their decision making process.

A queen, however, or the CFO, they basically know the

logistics of the company.

They basically finance everything.

They know how much money we've got, how much money we need, where is it

being spent, what needs to be done.

So therefore, nobody makes a decision without the CFO truly blessing it,

because if we can't fund it, we can have all the dreams we want,

but they'll just remain dreams.

So from that perspective, the two of them work very closely together, particularly

in a private equity environment where it's a much smaller company.

When I say a much smaller company, it's maybe 200M revenue and less, which is

where the majority of us all work in.

so the CFO and the CEO work very hand in hand with each other.

One sort of holding back the other one, egging on the other, et cetera,

depending on the roles and depending on what's happening now, the CTO,

I always liken that to the rook.

We are the ones providing the backbone of the, the overall infrastructure.

We are there to provide stability.

We're there to effectively keep out the bad people.

Keep the business running and make sure that we're dependable and we're

not making any big sweeping changes.

my mind went a different path.

I was immediately picturing the rook being the CFO.

Guarding, the purse and making sure that the money spent the right way and

making sure that we prioritize income to the extent that we need to survive

And I guess this is why mentally already Had that image when I was reading that

It is a fun game to play when you're maybe sitting at a fireplace, drinking some beer

or some whiskey to debate it, the other one that's been interesting is the Bishop.

Is the Bishop the sales team?

Because they've got the line of sight as to what's coming and what's coming on.

it's a fun game to play, but I think that, between the King, the Queen and the

Rook, it covers the three big C-levels.

What about the different sizes?

Another thing that I was immediately scanning your book for was like,

'Oh, okay, obviously it's going to be very different when you have

three people on the team than do when you have 300K people on that'.

How does that affect the CTO position?

That is a great point to make out, and it's something I go

into with a lot of detail.

in your typical start up, scenario where there is maybe only three of you.

The CTO isn't really the CTO.

You're the chief engineer, to be honest with you.

And probably you're getting that title because we can't afford to pay you.

so it's going to look really good in your business card.

but you're not going to stand side by side with, the CTO of AWS.

You're just in a different league.

So from that perspective, you're not really interested in the

long term future of the company.

You're more interested in just survival.

Can we build a proof of concept?

Can we build a product?

Can we build something that proves that this company has indeed got legs?

And from that perspective, you're far more hands-on.

You are literally coding every line of code more than likely.

You know exactly how to deploy the website, how to do the

database, how to do the email.

You are pretty much IT, CTO.

Everything that's technology-related comes under your belt.

So you're pretty much a jack of all trades.

And that's a very good place to start, because you do get a

phenomenal amount of exposure.

Now, As part of that sort of scrappy nature of bootstrapping a company to

start up, you will be taking shortcuts.

You will not be doing everything that you should be doing.

Because why do you need to?

You're the only person between you and maybe two or three other

people that know everything.

So you don't need to do documentation.

You don't need necessarily do backups because, 'hey, it's either

on the server or it's on my laptop'.

One of the two of us will have it.

security, probably not as high on your priority list.

Yes, you're going to keep your client data secure, but there's

only four of you in the company.

yeah, I don't need to keep audit logs.

there are certain things that you'll take shortcuts on.

I'll use my own personal credit card to sign up the GitHub or the AWS account.

The, domain that I registered with GoDaddy or Network Solutions is

probably on the CEO's credit card.

So it's a lot more scrappy on that perspective.

However, you are the go to person.

You probably are the only person that can restart something or push

something out or get something done.

from a CTO perspective at that point, you are, in the literal sense, the

chief technology person in that company.

And as the company grows, it's going to become more structured, right?

Yes, And this could be a hard transition for startup, CTOs here is getting rid

of the sort of the hero complex, which is everything's got to go through me.

what you generally find is your sort of litmus test to see if you

do indeed have a hero complex, go on vacation for two weeks.

How many releases were done in your absence?

How many server restarts were done in your absence?

How many new features were built in your absence?

If you come back and zero was done, then pretty much the company stood

still while you were on vacation.

Or, did you have to log in and do everything that you needed to do?

A company is never going to scale if everything is going to be

bottlenecked through one person.

So therefore, the next evolution is trying to bring in other people and again, I talk

about this in the recruitment chapter.

It is very easy to always be hiring people not as smart as you.

Every book tells you always hire somebody smarter than you.

every management meeting, every management lecture, always

hire smarter people than you.

You should never be the smartest person in the room.

That is wonderful car bumper sticker advice.

But it's really hard to implement because the human nature,

particularly technologists, because we're very ego-driven.

we love our voices to be heard.

We love to be showing off how great our code is.

It takes a very strong personality to be able to build a team around them

where they aren't the smartest person.

But that's going to serve the company and you phenomenally well

as you lay down the groundwork

and that's true of any level of any company.

it does take, discipline to figure out where your weaknesses are.

Where can I shore that up by bringing in outside talent and where can I

remove myself from the daily grind to grind of running this company?

Because as a CTO, you should not be involved in every single release.

You should not be involved with every commit.

Every pull request.

You have to take yourself out of the day-to-day running of the company.

And the sort of evolution is at some point you'll get to a stage where you'll

probably bring in a VP of Engineering.

And that is that person that is involved more in the day-to-day grind

of what's going on to allow you to focus on the greater strategy, but

also to start communicating more with outside of the engineering group.

And one of the sort of, again, red flags is in your day-to-day work,

how often are you speaking with your engineering team versus how often

you're speaking with the business?

If it's 90% engineering team and 10% of the business, you're operating

more as a VP of engineering.

You're not operating as a CTO.

It should be 60-70% talking to the business and 40% talking

with your engineering group.

So it depends on the evolution of the company.

But as we grow, as we evolve, our wants, our desires, our skillsets have

to evolve to adapt to the environment that we are now being placed in.

And sometimes.

You get to evolve with the company if the startup's really going well, etc.

But usually you have to leave a company to jump in at another level in

order for you to have career growth.

Problem being, for example, is if you're in a five man

company, there's only one CTO.

And the four of the people underneath you isn't going to get

to that role unless you advocate.

So therefore they will probably have to leave that company in

order for their own career growth.

that's some of the problems with the smaller company.

Did you find, through your experience with private equity, you mentioned,

did you find that founders who were there from the beginning, did they make

good CTOs often, sometimes, rarely?

You mentioned the jumping out of the company, but for those who stay, we

obviously have some famous examples.

everybody's probably thinking about Zuckerberg or people like that, but

for the average company, let's say.

what would you say is the answer to that?

9 times out of 10 it's usually a poor decision that they've made with a CTO.

it's not uncommon for, companies doing phenomenally well, but the person

that's acting as CTO has been the person that's been there from the

start and has been somebody that maybe the CEO or the founder knew he lifted

up the street or he knew a friend of a friend, because he couldn't really

afford an engineer or CTO at that level.

So basically pair of them have learned together and that's usually no problems.

They have successfully built a business.

However, experience has shown is that they're usually very narrow.

They haven't accepted new ideas or new thoughts coming in from the outside.

They have rarely hired somebody smarter than them.

Because they want to protect the domain and they've usually reached

the ceiling when it comes to like scalability or, security or management,

documentation, all of that usual stuff.

And we often see that manifest itself in terms of, there is no documentation

because they know everything.

Or they've put everything onto the cloud and they think they're cloud-enabled but

in actual fact when you look at their AWS environment or their Azure environment,

they're using it like a data center.

you've just evolved but you haven't thought about it.

And again that shows where they haven't kept up and they haven't

spent time teaching themselves about the new technologies.

Because as we know, our world completely reinvents itself every five years.

What we were doing now isn't going to be what we're doing in five

years time and likewise, vice versa.

you have to carve out time to teach yourself and to keep yourself up to date.

Otherwise, you'll get left behind.

And that's a problem.

of course it manifests itself as the imposter syndrome.

We'll talk about that later, I'm sure.

But ultimately, You have to keep up to date with the latest

and greatest technologies.

That's not to say you have to implement the latest and greatest technologies, but

you've got to be at least aware of what's going on, particularly within the domain

that your company is operating within.

What do you think of people who seem to be successful despite

going completely against basically everything you said right now?

I'm thinking people like Elon Musk, who are running multiple companies.

They happen to be CEO, CTO, whatever else they happen to feel like on that day.

They claim to be, at the very least, like a chief engineer on the rockets team.

Is that even possible?

What's your take on all of that?

I personally don't think Elon is as successful as he really is.

and I'll give you another example, Larry Ellison, 5th richest man in the world.

His title is CTO of Oracle.

Is he really a CTO of Oracle?

Or is there somebody underneath him that's really playing that role?

So I think there's a lot of facades going on it's good for the marketing buzz.

It's good for the story.

It's good for that.

But I don't really think that they're operating at that level, but you're

always going to get your outliers.

You are always gonna get your 98-year-old man that just doesn't seem

to die, but smokes every single day.

contrary to medical science, there's always gonna be those outliers.

The vast majority of us, we gotta work with our realities

Alan, for the newly implanted CTOs, for the CTOs who are just getting

started, Why is it so difficult for new CTOs to survive the first 100 days?

because you have to fight absolutely every single instinct

in your body to change stuff.

We love to fix things.

That's what we do.

We see a problem, we fix a problem.

And it is very tempting to go in and start quickly fixing things.

You see a process that should be changed, but the first thing you've

got to do is to understand why the process the way it is, what is the

true value of your human capital?

And what I mean by that is how strong is your team?

you've got to get to know your team over a period of time before you

truly know who are the go to people for whatever thing you need to go to.

Who are the people that are reliable?

Who are the people that switch off completely the moment they leave work and

therefore they have to remember everything again when they come back in the next day?

who are the people that know how everything works in this company?

And you'll always find those one or two people that, Yeah, that's why we did that.

They will always know the reason why some hokey process is the way it is,

because it's okay, there was a client at a given time that needed a given

feature, da, and we never did it.

Okay, so this is where we've got.

Okay, fine.

So the first 100 days, is you just listening, absolutely listening

and watching and learning.

And one of the analogies I use in the book is, you're basically like Mel Gibson

in the Maverick movie when he first sits down at the poker table and he loses

all his money for the first two hours.

He's using that money to buy knowledge about all the other players on the table.

So when he does start to decide to start playing, he knows how

to play poker against them all.

So your first 100 days in a company is not only listening and learning

about your own engineering team.

More importantly is understanding the wants, the desires and the

frustrations of the business as a whole.

Where are we getting this right?

Where are we getting this wrong?

Where could we do better?

And you're not making anything materialistically huge

changes in those 100 days.

You may do the odd little things, tighten up certain meeting structures,

get a little bit more cadence with respect to daily stand ups or

bulletins, et cetera, whatever it is.

But you're not changing anything yet because you need to sit down And

then after that 100 days, usually doesn't take that long, you've

probably got something within the first sort of 60 days, is figure out

what is going to be your roadmap?

What's your vision for this company?

Where are you going to take this group going forward in order to

be successful for the company?

Does every company need a CTO?

No.

It's a great question.

And it's very hard to give a set of checklists as to when you

need a CTO and when you don't.

By and large, if you're producing technology, then yes, you do.

That's an easy one.

if you're not producing technology, but you've got a significant amount

of data and you're producing a lot of aggregated services, etc.

Then yes, you probably do.

At that point in the equation, the blurry line between CTO

and CIO now starts to come up.

Chief Information Officer.

But by and large, they're both operating at the same sort of level

and the same goals and what have you.

So in many respects, a CTO can be a CIO for a non technology producing company.

If, however, you're just A small company, you're using a handful, maybe one or

two different services such as like an EHR platform or Salesforce or, if

everything is in one given environment, you probably don't need a CTO.

every company will need an IT manager iT is usually not under the remit of the CTO.

So that's basically the person that ensures that our laptops, our machines,

our back office systems are in check.

It's usually not the CTO that takes over that role.

I've had this version of this conversation with a few of my friends

about AI, how now every company is AI-first, and, I think before AI data

and like data-first or data-driven was another one of those catchwords

that, were fairly popular as well.

Absolutely.

And mobile-first was another one before that.

yes.

mobile first.

yeah, we have gone through our seasons, haven't we?

it was big data.

It was web 2.0.

It was crypto.

now it's AI.

and I think the whole AI world, it's absolutely fascinating.

We probably talk about that in a completely separate podcast, but that

one, Particularly for us in the private equity world, we see AI being splattered

everywhere over a company's deck in order for them to say, Look, we're so

much more valuable because we use AI.

Yeah, but you're not really using AI, you're consuming AI, which means

there's no real competitive advantage.

Okay.

Kind of like me saying, Hey, I'm, I'm Office 365.

So what?

My competitor can be Office 365 too.

What's the big advantage?

There is none.

I think with respect to that, one thing that we're looking at is, it's more in

the machine learning side of the fence.

what are you utilizing your data for that is unique to you that only you've got?

As opposed to just slapping on those two little letters and hoping that people

will get starstruck by whatever that AI is going to produce for your company.

So I wanted to transition now and, unveil a few of, the bigger thoughts

that, people will find in your book.

But before we go there, can we also talk a little bit about

the negative side of this?

What would you say is the least pleasant part of being a CTO?

You're the first person to ever ask me that question.

I think from that perspective, it's the culture shock that you

don't get to do coding anymore.

Or you shouldn't be doing coding anymore, particularly if you're a CTO from a

developer's engineering background.

Because ultimately, you will have far more responsibility Then just simply

producing code and checking it in and you never want to be the bottleneck for

a project or a feature to be released, because you were pulled into an executive

meeting, you were pulled into whatever fire was raising at that point, you

couldn't get to that code or you realize you probably weren't as good as you

thought you were in the code and what you did slap dash in is now proving to

be more problems than it was solving.

And you're still holding people up.

But because you've been pulled elsewhere, it's there.

So that's a very hard thing for CTOs to let go of the keyboard.

Now, I personally, I carve out small little side projects for myself

in order to keep myself relevant.

But I make sure that those side projects are never critical path projects.

I'm more than happy to bootstrap an idea or kickstart some

thoughts to prove the concept.

And then hand it over and say, 'Okay, productionalize this.

make it to make sure that it'll never fall over' type stuff.

That's my personal way of keeping my hands on the keyboard.

But, there would be weeks that would go by I would rarely open up visual code.

and a little bit dies inside of me when that happens.

But that's the reality of the role that we playing.

I think to an extent, it's also shared with, other slightly higher

level positions that not necessarily CTO, some staff engineers I know,

they struggle with the same.

That's, to scale the impact they have to decrease the percentage of time

to actually doing hands-on work and focus more on things like architecture,

focus on resolving, potentially political issues around, internal

office, It never lands well with them.

I think there's just something about the type of people who end up doing this roles

that it's always like a cross to bear

It is.

It absolutely is.

if you've got an engineer's heart, then feed that passion.

It may not be 80% of your day anymore.

It may only be like 10 or 20% of the day, but keep feeding it.

Don't take them out of the server.

Okay, you're now just project management.

You're now going to make sure this team of engineers is doing everything

right and all you do is code review.

They are just going to hit a wall and one day just leave.

feed the passion and carve out time to allow them to basically play and

to innovate and to truly feed that so they don't get bogged down with 'Ugh,

I spent the first six hours of every day doing emails and Jira updates and I

Is this what my life has come to now?'

Some people enjoy that.

Great.

But if you've come from an engineer's heart, you probably don't.

For anybody who is not going to stop listening now and say,

okay, now I can't do that wants to learn more about the CTOs.

your book is basically, a long list of chapters covering on different

focus areas for CTO, like planning, division, naming narrative.

Interviewing onboarding, building the team, growing people that you've

already hired, obviously the tech decisions themselves, the development,

documentation, all that stuff.

So let's go through some of this and try to focus on one piece

of advice that you consider the highest return on investment there.

the first thing that you said about the CTO, the grand vision, what would you say

is like the one thing that might be the most important, for a new starting CTO?

I'll give you an example when we look to buy a company, we'll,

part of that is due diligence.

And that's really just getting to know the team and getting to know

what the company is, et cetera.

And it's also verifying that they're doing what they say they're doing.

Okay.

And I will run up the technical diligence on that side of the fence.

And I love talking to people.

I just absolutely love.

Especially if you've found an engaging CTO or an engaging VP of engineering.

What I usually do is to start off the meeting is get them to

stand in front of a whiteboard.

I say, draw me the five year plan that you've got for this company.

If they can draw it like that, then they're a great CTO.

If they can't or they struggle, And they can't get past six months or they

can't get past a handful of features.

You're not a CTO.

You're more of a VP of engineering you're not showing a path of where the company

can go because in many respects, even with this AI stuff, your average C level

isn't going to have a clue what the hell they can do with AI, but you as a CTO,

you're supposed to be able to lay out.

Here's what we could do with AI.

I'm not saying we're going to do this with AI, because that's an executive

decision we make as a company, but I'm going to show you what's possible.

Or I'm going to show you what's possible with the mobile.

Or I'm going to show you what's possible if I'm in a manufacturing company.

Here are the latest and greatest IoT devices, here's what we could do.

So I'm going to show you a possibilities.

And you're also going to let yourself dream.

If we were to go down a certain path, then we could do this, then we could do

this, we could do this, we could do this.

And that sort of seeds the c-level as to what is possible.

Now once the c-level has decided 'we're going in this direction', now

you have to effectively put a lot more meat on those bones and truly come up

with a vision plan to walk that path.

And to show that here's where we're going to be at each step of the way

in year one, we'll be here, year two, we'll be here, year three.

Hey, it could all change depending on what we learn in year two and

depending on what the industry has done.

But hey, assuming everything is going the right way we're going

to continue along this path.

Now that is a far more engaging and exciting person that is being proactive

as opposed to sitting there waiting to be reactive as to say, 'okay, we'll

wait and to see what our clients say'.

We'll wait and see what features they want, or we'll wait and see what comes up.

That's not a CTO as far as I'm concerned.

So that's what I'm looking for there, is somebody that truly knows what it is.

Now part of that vision planning could be moving off of legacy systems.

Because, it's aging out.

We can't get the resources, either hardware, software or even human

capital to support it anymore.

It's causing us more problems than it needs to be.

So that needs to be vision planned out as well.

So all of that.

I'd like to see a whiteboard completely filled with arrows and plans and

dreams and but it comes naturally.

And you'll know when somebody sells you that story.

And that's the other part of a good CTO is, can you sell me the

vision without using buzzwords?

Can you sell me the vision without making me feel intimidated because

you're using things like blockchain?

I have no clue what the hell blockchain is.

What does it mean?

I don't give a crap.

What does it do for me as a business?

What does it do for me as a customer?

Cloud, I don't give a crap about cloud, what does it mean?

you need to be able to articulate that in such a way that the CEO and everybody

else on the chessboard can contribute their thoughts and their ideas in such a

way that you're not coming up and saying, 'this is the way it's going to be'.

I'm the technologist, you don't know technology, trust me,

this is the way it's going.

I've met many people like that and they fail quickly.

You need to be able to bring along every other person.

Bringing along your engineering group, relatively easy.

They're in the trenches, they know the problems, they know

also where their industry is going, they know the buzzwords.

Preaching to the choir.

You may get into a tabs versus spaces argument with some of your

engineers as to which framework, which language, that's fine, those

are good conversations to have.

But from a business perspective, can you sell what it is you're doing in such

a way that they can understand it and also get excited about it because When

you're selling your vision to the CEO He's not the end person or she's not the

end person, because they've got to then go and sell it to the board if you're

not Representing on the board yourself.

They're going to represent it to the clients.

They're going to represent it to the investors So you're really telling them

the soundbites That they can then reuse using their words and their understanding.

So whenever they tell the vision of where the company is going, it sounds authentic.

It sounds real and we've all met people where you're thinking 'you've no clue

what that buzzword means, do you.

You're sounding confident, but you've no clue what you're talking about, do you?'

And that's a bad thing, you always want to make sure that your CEO, your board,

your investors understand completely what it is you're trying to sell.

So to an extent you're actually in a translator role, right?

You have to explain these, very, Boring to a lot of people, details of

what is going to enable the company to achieve the things that it wants

to on the technical level without actually using the technical terms.

you're absolutely right and it's something I say to all of my engineers

at all levels is the biggest part of your job isn't QA'ing, isn't

producing code, isn't documenting.

You're a salesperson.

That's the biggest thing that you're doing because at every level we're always

selling what we're doing, we're always trying to persuade somebody that this

function is better than this function.

This feature is better than this feature.

This way is better than this way.

We're always trying to influence, persuade, sell our thoughts and

our ideas to those around us.

The only difference at a CTO level is to your point, you're not allowed to use

all of the buzzwords and the ingredients that you're usually allowed to use.

Now, the only time you are allowed to use buzzwords And it's again, my little

litmus test is, as soon as either one of the big tabloids start using the

buzzword, CNN, New York Times, Wall Street Journal, pick whatever one it

is, as soon as they start using the buzzword, you're not allowed to use that

buzzword, but you have to caution that buzzword to make sure that, okay, let's

have a quick session on what, Crypto is.

Let's have a quick session on what blockchain is.

So you become a teacher, you become an educator in order to make sure that when

you're giving that five minute overview of what that new term that has been published

in the Wall Street Journal really is, that the c-level can go, 'ha, I got it now.

I actually get it'.

Because again, we're also running hard.

We usually don't take the time to explore some of these words and we hope that by

the time we've read it for the sixth, seventh, eighth time, we'll figure out

the context that it keeps being used in that we'll be able to bluff our

way until such times we've got a true understanding of what it really means.

But a CTO should always be putting out thought pieces to the company

to say, 'Hey, you've probably seen this' or one that I always love to do.

If you realize of a big public hack or a security breach has happened.

Use that.

Send it out to your company.

Break it down.

It may have nothing to do with you.

But educate all of your employees as to how did that happen?

What steps were missed?

What was the consequences of that particular stuff?

Become a thought leader.

in technology in such a way that people feel you're far more approachable and

therefore you're not the guy that's going to make you feel this height because

you come and ask them a dumb question.

That reminds me of, a few engineering blogs that I enjoy reading.

Do you think that's a good use of, CTO's time to do this thought

leadership really that you're talking about in the form of a blog.

Yes, for two reasons.

One, it gives you time to sit down and think about what

it is you're writing about.

At university, for example, when you were at a lecture, those that wrote

down the notes had a higher likelihood of remembering what was going on.

So a blog helps you with that part of the equation in a modern day environment.

What it also allows you to do, which is where I get a lot of comfort from it

as I run a lot of internal blogs, is it allows me to sit back and say, 'okay,

if I'm to read this without all the buzzwords, am I communicating properly?'

Can I remove words in such a way that I can get this right?

So it allows me to truly hone in on what it is I'm trying to say and

what it is I'm trying to communicate.

I'm going to make the assumption that the reader is going to skim it.

They're not going to really read it in depth.

So I've got to be able to write it in such a way that, that I

get what I need to get across.

And it's a great.

tool to allow you to tighten up and to really make your email succinct.

That's actually one of my own favorite litmus tests.

if you can't explain it to someone else, that means you don't understand

it, uh, well enough, but it can also be a big time commitment.

writing a proper in-depth, blog post that can easily take a day or two.

Oh, completely.

But, you never know when that blog post will pay off for you.

It may be turned into a white paper.

It may be turned into a green paper.

It may be that the CEO suddenly says, Hey Alan, I need you to

talk to a big potential customer.

They have no clue about this particular technology.

Can you help walk them through it?

you never know when on a dime you're going to be asked to turn

and to present and to do something.

So I always like to be prepared for that sort of stuff.

And it's something I go into with respect to, the future planning of a company is

that, particularly when a company gets to the point where it's maybe being

sold, you'll never know when suddenly you'll get a tap on the door and say,

Hey, got some people I'd love you to talk to, could you walk them through

what we do and where we're going?

And that's basically code word for, 'hey, we've got a bunch of new buyers.

Can you put our best foot forward here?'

So a hint for everybody listening to this.

I guess if Alan is looking into your company That's the thing to do.

Go and write some blog posts.

That's a green flag

It absolutely is.

And an excellent book that I would recommend people

getting is "Smart Brevity".

it's a 70-page book.

It's well worth the investment, It helps explain how to tighten

up your communication in such a way that you use a lot less

words, but communicate a lot more.

I hate to be promoting somebody else's book while I'm promoting my own, but

hey, there's enough for everybody.

Yeah, there's this quote that I'm forgetting now I think it was Blaise

Pascal saying that if I had more time, I would have written a shorter letter and

that's definitely a good motto to have, I hope I didn't misattribute that now

Let's move on.

so we've got a vision, the CTO, a CEO, we all agreed on the

grand vision, going forward.

And now, we need people to actually make that vision possible.

What do we do?

How do we go about interviewing and onboarding?

We first of all have to decide who do we need.

What skills do we need and what skills will we need today?

And what skills will we need tomorrow?

And that's very important because you want to be able to bring in people that

can evolve to where you need them to go in the future because your product

will grow, your product will change.

It will adapt.

So you need to have people that's going to come along with you.

from that perspective, you also have to figure out my timing in all of this.

do I hire engineers anything from coders to data scientists to

anybody that's under the CTO banner.

Don't keep assuming I'm always talking about programmers.

so when you're hiring your team, do you need to have full time employees?

Or can you bring in contractors to get you initially past a given point

or is this something whereby I could partner with a third party development

company and let them do that part and instead of us investing in say 10 or

20 people, let them do that because we may need 10 or 20 people for the next

six months But after that once the development is done, we'll probably

be down to five or 10 whatever it is.

So do I want to have to downsize my group?

after six months.

I don't know.

it's about figuring out your overall plan and working closely

with the CFO and the CEO.

The three of you have to figure this out together once you've given

certain options, and those options will be, a factor of time and cost.

And if you want to go faster, it's probably going to cost more.

All of the usual, stuff that comes in and around there.

And that's where having a conversation with both of those

roles will help you solidify.

Because they will know what they can tolerate.

Both from a, I can wait six months for this feature or I can only wait

three months for this feature or I've only got a million dollars versus

a hundred thousand dollars to spend on this at this precise moment.

So that's a very important thing to do there.

So once you've decided that, then it's effectively an interviewing process, and

the interviewing process should always be the same irrespective of whether

that person is going to be on the team full time or as part of another company.

You're interviewing the company, but I always like to see the resumes of the sort

of people that are going to be working with me, even though they're going to be

working with me for a short space of time.

they're still humans.

You cannot simply trust the fact that this outsource company has said,

'yeah, we'll give you ten React.

js developers in the world best'.

Yeah, but are they?

Really?

Okay.

Can I talk to one of them?

Can I?

Let's meet them.

Let's have a conversation just to make sure that they fit culturally.

They've got the sort of ethics that I want to lay down.

They've got the code quality, the standards, the way I want

to work and produce this.

Even though they're a third party company, you're still a boss.

You're still the one that's paying their salaries effectively.

I also learned that, and surprisingly took me a good few years into my technical

jobs to understand that a collection of individuals, as impressive as they

might be, each one of them separately, doesn't necessarily make a team.

How do you build a team out of your hires?

What

advice do you great point.

don't hire all rock stars.

off the bat, don't hire all rock stars.

they will always be competing, and overwriting each other,

and undermining each other.

there's a reason there's only one rock star in every band.

The Rolling Stones has got Mick Jagger, live with it.

Queen, Freddy Mercury, live with it.

Yes, there's other people in the band, but they're not all rock stars.

fundamentally, You need a mixture of senior, mid level and junior.

Everybody needs to be able to aspire.

Everybody needs to be able to learn from another.

Not every developer is equal.

Not every role is equal.

You'll have different levels doing different things.

The human tends towards certain things because they like that particular part of

it, but they don't like that part of it, but on paper they're both the same title.

so you want a good blend of people.

And more importantly, skills can be taught, but an asshole

will always be an asshole.

So culture is huge.

You want to define what your culture is going to be and I've

seen many different variations.

From one end of the spectrum you've got the sort of the real gritty team

that will curse and swear and I mean it's it truly is like a builder's

yard but they all love and appreciate each other It's their love language.

Then you've got the other end of the equation where it's all

horrendously polite, we use our title, we use our stuff.

I first started out my career in the Ministry of Defence.

I was a civilian working in a military environment and I was struggling big

time because I kept forgetting the bands on everybody's shirts as to

how I was supposed to address them.

So I was insulting managers, inadvertently, by simply not being

his part of that environment.

so I did not succeed in that environment.

and what was interesting was I then went to Harman Kardon, that was my eye opener.

Going from shirt and tie military situation to effectively sandals,

open shoes, and hippie culture, and sound studio, it was like,

'oh my god, these are my people!

I love this!' So you gotta find the right people that will fit

into your personality of your team.

Because it can just take one person to truly spoil the rest of the team.

And that's hard, that truly is hard.

So you've got to be very upfront in your interview to make sure that you test them.

So if, for example, you are a very sweary environment, then

let them know in the interview.

Would this make you feel uncomfortable?

Or likewise, this is a very strict environment.

You've got to be here at 9 o'clock.

If you're not here at 9:15, then we're going to assume something's wrong.

Are you okay in that environment?

Whatever it is, whatever the blended environment is, make

sure culturally they fit.

Because there's so many different versions of it, and that's what

makes this world so wonderful.

But finding the right person will, by and large, outstrip any technical

skills that they'll bring to the role because we can teach them how

to be a better React developer, or how to be a better QA person, or how

to do the new version of SQL Server because they're on two versions below.

If they're culturally the right fit, I want that person on my team.

So that brings us to an interesting situation.

like you said, you want everybody to have a chance to grow.

You want to actively be growing the team for everybody to get better.

But you also want to hire people who are better than you or smarter than

you, who are more skilled than you.

How do you, as a CTO, give those people a chance to grow if they might

be, already beyond what you know.

from that perspective, I like to elevate them above me.

for example, if they're starting to shine and I know, unless I leave,

they've probably reached their ceiling at this point, but, however, I want

to make sure that they continue on.

Instead of me presenting at the board meeting, I'd probably invite

them along and say, hey, I'm going to bring you in for 10 minutes.

I want you to present this area and that's given them visibility.

It's given them experience, it's given them that

responsibility to go at that area.

I'm also a big believer of celebrating when somebody leaves.

I've had people in my team that I hated to lose, but I'm so proud of

the things that they bounced into.

Big titles that they went into, because we were part of their journey.

We were part of their growth, part of their learning, part

of their desire to get there.

I never would send out an email to say, 'George has left, we never

liked him, he was a pain in the ass and he always kept breaking stuff'.

I want to celebrate the fact that George has been with us for the past two years.

He's done a phenomenal amount of stuff and we're really excited

at what he's going towards next.

And he'll always have a home for him back here if he ever wants to come and see us.

I want to make sure that people know that, and this is something that Reid

Hoffman of LinkedIn said, it's one of the questions he asks in the interview,

"when are you going to be leaving us?"

because you're not joining a company for life anymore.

So let's pretend that you are going to be leaving within two years.

Great.

what point in this career are you going to say I've outgrown this company?

Tell me about your future plans.

Cause I want to get you there, but I'm going to utilize you and

we're going to work together for the few years that I've got of you

and then you're going to move on.

And that's a celebration.

Never see it as a deign against loyalty or somebody turned on you.

no.

And that's part of the emotional growth that a CTO has to go through.

Just because your lead engineer has left you, have they left you for good reasons?

And if it's good reasons, then pat them on the back, wish them the best

and look forward to listening in on their journey as they continue forward.

I think the world would be a much better place if everybody thought that way.

It is hard.

Again, these damn emotions that these humans have really

do get in the way at times.

They really do.

What about the non-human element?

So far we've focused on that, and I think that's probably

the hardest bit, like you said.

but there's gonna be some other things that we should be focusing on as well.

with the technical being a hint in the name.

What about the tech decisions?

what would you say would be some of the most crucial elements and

the biggest decisions that every CTO is going to have to face?

so it's always hard.

particularly if we go to some more of the engineering side, deciding, for example,

which language you're going to use, or which framework you're going to use, or

which cloud provider you're going to use, or which database you're going to use.

We, by our nature, love new shiny things.

We love

to test and play and use the latest and greatest.

That's the hardest part of this role, is saying, ' I can't be

on the cutting edge anymore'.

I can be on the leading edge, but the cutting and the bleeding

edge, I can't do that anymore.

a new language that may have popped up that seems to answer

everything that you've wanted.

If a CTO was to say, now we're moving to this language and everything's going to

be ported to this, huge warning signal.

Because that's a vanity project.

You're not thinking in the best interest of the company.

Because that language, or tool, whatever it is, hasn't proven itself.

We don't know, can we recruit engineers for it?

Do we have a support system?

Is there an ecosystem?

Is there a business system around this to figure out?

Yes, it's not sexy that I have to choose SQL Server, but I know that I can throw

a stone and I'm going to get a SQL Server expert, a company, a support

person, a backup, no matter where.

MySQL Postgres have now earned those rights as well, but there

was a time that choosing MySQL Was a 'whoo that's a big risk.

Okay, who's really supporting who's really doing' and until Oracle bought

them, they then got their sort of big boy validation at that point.

So it's very tempting to chase the latest and greatest, or the greatest buzzwords.

And where we usually see this the most is in the JavaScript frameworks.

Holy crap, that's like friggin Fashion, they go in and out of

fashion, left, right and centre, and it's really hard, to say it.

And I bumped against a wonderful Instagram reel the other day, and it

was one of these sort of, Say the one thing out loud that nobody wants to say.

and it was one of the, one of the software engineers said, "JQuery is okay.

It'll always get the job done".

Okay, I get you.

Anyway, so from a technology decision, you're not making technology

decisions based on what you like.

You're building it based on, can the business build upon this?

Can the business make money off of this?

Can the business pay all our salaries off of this?

And in five years' time, how's this going to look.

In 10 years' time, how's this going to look?

Because here's the thing.

While software technically doesn't age, it does.

But the years go by very quickly.

So you have to keep pace with that.

And I generally don't like to support any big open source projects unless

they've got a big commercial backer behind them, because I want to know

that somebody else is investing in the health of this framework, project, etc.

And it's not just us, because I'm a smaller company that I'm not

going to be able to influence it.

And while it's cool to be able to say, 'yeah, but it's open

source, we could support it'.

No, we've got our own day jobs.

We don't have time to be able to support that framework.

And nor do we have the knowledge of the framework at that level to

be able to build and support it.

So yeah, that's a placebo.

Do people say it's open source?

For me, the open source banner, and I'm a huge open source fan,

is that we collectively contribute to the success of that project.

But it still needs a big sponsor before I'm going to bet the livelihoods of

everybody working in my company on it.

I guess another facet to the open source equation is that it helps you

avoid lock-in, which is something that's very appealing a lot of the time, right?

for sure.

And To be able to freeze frame, there's been plenty of examples in the past

of where a particular open source has now moved over to GPL or moved

over to commercial or just stopped it and said, okay, I'll snapshot the

previous version that we were using, which was a license-friendly and we

will run with this ourselves until such times we find an alternative.

So it gives you time as opposed to a commercial company saying.

We're out of business next week.

What are we doing now?

Scramble.

because it is a core part of the architecture that it's there.

but again, as an architect, as a CTO, I always like to build in, very much a

microservices API facade type patterns, whereby if a core component does

disappear, I'm not writing to that core components APIs per se, I'm writing to

facades API, so I can then go and, Insert another one, and where this is happening

a lot, Miko, is AI companies are failing as quickly as they're being created.

So whether that's an AI company that's doing OCR for something or audio

transcription, whatever it is, when you're building and utilizing that service,

by all means do it, but put a layer in.

that allows you to switch out that vendor should that their

pricing go way up because they're not made able to make money.

So they have to double their prices or they've gone out of business

because they can't compete.

Then I have to make switch in another provider.

So a CTO is always keeping their eye on the business consequences

of that going away and ensuring the architects, if they're not the

architect is giving us an insurance policy that I don't have to go to the

board and say, Sorry, company's down'.

Why?

this company that we thought we were going to be hanging around has just

gone out of business and we're humped.

I think the AI is something that a lot of people have realized now.

It's moving so quickly that literally you might start using a tool today

and a couple of weeks later, it's, 'Oh, wait, the website bounces'.

What's happening.

It's happening a lot, isn't it?

It's frightening.

I think a lot of these, they're cool ideas.

They're more features as opposed to businesses.

But like you said, slapping AI on your pitch deck, definitely helps at

the moment, at least for some people,

It opens the door to the conversation at least.

exactly.

from your experience, what are the best patterns for arriving at the right

decisions, because I know some people are more, I don't want to say totalitarian

in how they, Bring this decisions.

but it's easy enough to picture a CTO who just does their analysis.

And then all of a sudden he says, 'Oh, we're doing this' and expects

everybody could go through with that.

I've also seen people who are much more humble about that.

And they do things like drafting a thing to gather people's opinions,

or maybe write a white paper or some kind of RFC request for comments

to gather people's opinions.

It's obviously not possible to get everybody on the same page all the

time, but what's your take on what you've seen being successful the most

In terms of arriving at decisions that are not always straight cut.

There's always some subjective, part to choosing this database over that database

or this provider versus that provider.

You're absolutely right.

And I think at some point, it always does come down to a Coke versus Pepsi argument.

It doesn't really matter which one you're choosing, you're still getting

that Coca Cola flavor, if you will.

My personal way of doing stuff is, I love wikis.

I love to show my workings.

And I love when I'm putting out a new idea, a thought,

architecture, whatever it is.

I will actually put it out so everybody can see it and review it.

and I invite criticism.

I invite holes in it.

Now, I have a very strong, and I would recommend this for any CTOs, make

sure you have a strong right hand.

And that right hand is somebody that is going to pull you aside and

' what the hell are you thinking?'

What are you doing?

This is dumb.

You need that person that doesn't see your hierarchy but will truly help you

think through stuff and is not going to scare to say to you, you could have

handled that better, couldn't you?

Okay, or you handled that very well.

Do that again.

o that right hand is always a strong, asset to any CTO, and from that

perspective, they're your first line of defense in terms of any idea, any

strategy, any thought you're doing.

It's to, to throw it off of them.

What's their thoughts?

What do they get?

Because a right hand should never be scared to go against you.

You should never be scared of the consequences of completely

disagreeing with you.

Because it's through disagreement that we figure out, I missed something.

Oh, you're right.

I completely missed that.

Or, this gets us 80% of the way, but the last 20% is going to be

a real pain in the ass because we've chosen wrongly at the start.

That type of stuff.

I liken it to the, If NASA leaves the Earth atmosphere by half a degree

out, they're going to miss the moon by hundreds of thousands of miles.

The small decisions at the start can really make a big impact.

they're your first wave, and then again, whether it's white papers, et cetera,

I always like to show my workings.

And to make sure that if we're deciding we're going to use this software

or this platform, I'm going to show them the three alternatives that we

debated, the feature sets, why we didn't, and why we've chosen this one.

And it could be a mixture of lots of things.

Favorable licensing, feature sets, availability of up and

coming features that we know we're going to get, whatever it is.

Make the argument be data-led, not emotion-led, and make it

feel like there is a voice for others to come in and collaborate.

But ultimately, you're the decision maker.

You're the one that's going to be responsible for deciding

Postgres versus MySQL, to put it down into a real simple example.

The Coke versus Pepsi also made me think about some of the advice I heard elsewhere

about how when you're in a situation where you can choose a path where the decision

is effectively reversible, there's really no point spending too much time on that.

You can almost flip a coin between Coke and Pepsi and then you try to

save your time for the ones where you can't reverse them easily.

Is that good advice?

That is brilliant, absolutely brilliant.

sometimes it's hard to determine which ones are the big decisions

in which ones are the smaller ones.

Fortunately, in today's environment, even from a language perspective,

like a perfect example is, I'm a huge serverless fan.

I find that the vast majority of companies that we interact with don't

need large servers, they can manage with serverless and serverless has truly

removed the language decision away.

So we can write a handful of endpoints in Java.

Or a handful of endpoints in Go or Python or Node.

I don't have to be a single or a couple of language shop.

I can be a polyglot environment using the right tool for the right job.

So the consequences of me saying, ' I'm going to write

these four endpoints in Java'.

Six months down the line.

Damn, I've got no more Java developers.

Okay.

Rewrite those four endpoints in Node, please.

Because we've got a team of Node developers.

That's a much easier thing to do than saying, 'we have to rewrite this whole

architecture now because we've decided now we're going to use a different language'.

So from that perspective, There are certain safeguards that we can

put in, or insurance policies, to make it easier to unwind without

the business feeling the effect.

that's solid advice.

Let's cover one more thing that I think a lot of people and teams struggle

with, and that's documentation.

What advice would you give to people who may have never seen

a team that actually has solid docs or enjoys writing this docs?

How do you make that better?

Nobody likes to document, because they always feel like it's holding them back

and you always get that engine that says, 'But my code's obvious enough.

It doesn't need documentation.

Anybody can read it'.

And to a large extent, they're right.

for sure.

my sort of, advice on that perspective is once your team gets to a significant

size, hire a technical writer.

They're one of the best investments you could ever make.

they will, produce the documentation to a level that's required for the business.

And when we need business, we're talking about continuity, which is when we

change somebody in the team or we move something, do we still have knowledge

of how that particular system worked?

And it doesn't usually have to be that detailed from that perspective,

but you do need to have a trail.

The other thing that I would advise is your head always goes to the

written word because that's just the connections that we've made.

Video is documentation.

I'm more than happy for an engineer to talk through a given area and just

record it and now that's available.

And given our modern AI tools, we can transcribe that at a later date

in order to make it searchable.

that's a zero cost, transcription.

Particularly if you talk into Teams, for example, they'll transcribe it

for you in real time, as will Google.

Boom, there, you've done your documentation.

in order to make that a little bit easier, and less interview-ish, is, at certain

points in the project, Get your team to present what they've just done as part

of an educational video and let that Q&A to happen back and forth and record that.

And now you've just documented it.

And once your team gets to a certain size and your company gets to a

certain size and you need to be able to have tighter documentation because

of compliance, because of, SOC 2 or ISO or whatever other compliant

framework you're trying to adhere to.

Let the technical writer fill in the gaps for that.

But don't force everybody to crack open Word and create a Word document.

Or create confluence pages, etc.

Documentation can be inherently sourced through Jira bug tickets.

through, comments in tickets, commit messages, video talks.

It also contributes to the overall knowledge base of the company.

And my best advice would be to run up a wiki in order to have that

wiki to be the glue between here's the link to the GitLab repository.

Here's the Confluence one.

Here's to the SharePoint where the videos were recorded.

Here's to the stuff.

and have that wiki be that little bit of informal.

The conductor and the orchestra to know where all the islands of data are.

Untl such times that you can dedicate a role to that, to bring that data

together in a more formal manner.

Most of the time it's not required in a formal package.

Gone are the days where I'm looking from a 60 page PDF of the product manual.

I think the one thing I would add to that is that, I've gotten a lot of mileage

from just setting one simple rule for my teams that every major piece of,

functionality or of work really that we do, that requires people to talk to

each other to see what it's actually going to look like, how it's going to

get implemented needs to result in a small design doc that basically says,

'okay, this is what we set out to do'.

This is roughly how we expect it to work.

This is what we're going to do.

Just having that written down instead of having that in Slack

messages and Jira tickets And stuff.

Completely.

Even if it's part of a wiki, like you said, tends to work really well.

It gets outdated, obviously, when you've got newer versions, but

at least gives you a snapshot in time of, this is why we did that.

Oh, wow.

Okay.

yes.

and having somebody stand in front of a whiteboard, draw a picture, and

then somebody take a picture of it.

That's documentation too.

little time.

It doesn't have to be somebody going back into draw.io to recreate that whiteboard.

Why?

it's doing well as it is.

Just leave it as an image.

Make sure it's indexed though so we know how to find it and what we're

about to do when we click on that image.

Absolutely.

Some of the last chapters of your book, talk about the company growth and

potential acquisition and how to make it as, smooth as possible from again,

the perspective of the CTO, what would be the most important message on that

front that you would, want to send

When you are in a very growth-orientated company,

inevitably the company will evolve.

Now it'll either be acquired, It will acquire other companies, it will go

through a growth phase, of course it will.

And what you're doing there is making sure that all the decisions that you're

making are going to outlive your tenure.

so any decision that you make, you've got to make sure that the person

coming behind you is going to feel confident that, 'hey, you made the right

decision, I can take this on further'.

Okay.

And planning that far ahead takes, takes discipline and it takes hardness.

for me, I've worked a lot in the private equity space being a CTO

for a private equity company.

So what does that basically mean?

It means that, you're going to be sold.

At a given date, because that's how private equity makes their money,

and that means you're going to be sold to either another private equity

company or another company that's going to consume you as part of that.

Now, what I love about being a CTO in a private equity world is that at some

point, and I talk about this in the book as well, is you're going to go through

a process that's called due diligence.

And that's when somebody comes in and effectively, rates

everything that you've done.

And that's where I like to say, somebody's gonna come in and say, Hey, which

asshole thought this was a good idea?

And you're gonna have to put your hand up and say, I'm the asshole.

I thought it was a good idea.

So by having that level of, oversight and review that you know

is coming, it keeps you more honest.

It makes sure that you make decisions that are going to stand up to scrutiny.

Because if you're a CTO in a private company, who's really

going to question your decisions?

CEO's not going to come in and say, Hey, why did you choose

this database over this database?

They don't have the time for that.

They probably don't have the knowledge to do that.

But during acquisition time, There will be experts that will come in and they

will know the reasons why you should have done one over the other, etc.

Or the pain points of having one over the other.

And they're going to ask you to justify that, and what

your plans were for that, etc.

And now you truly have to be standing up and take stock of what you decided to do.

I like to make sure that when I'm mentoring and teaching and helping other

CTOs that, Stop thinking about today.

Start thinking about tomorrow.

And how is this going to look?

Did you choose to say, for example, go with, AWS's best cloud practices?

Or did you decide that you knew best and you were going to go this way?

Which one of the two is going to be easier defended if you're going to go this way?

Or which one do you think is going to be easily google-able?

For a new engineer coming in trying to figure out how to

help manage your ecosystem.

don't always go your own path.

Sometimes go a path where everybody else is trodden.

Because there's support for that.

That doesn't mean you can't innovate and you can't change and tweak and evolve.

But you're always doing everything.

For the behalf of the company, you do not want to be the reason

that salaries cannot be paid.

for sure.

This has been an absolute pleasure, I think I personally learned quite a

bit, and for anybody who wants to learn more about Alan's book, it's called

"Think Like a CTO", it's published by Manning, and it's available right now.

Alan, thank you so much, and hopefully see you next time for your next

book, and thank you for sharing.

Miko, it was an absolute pleasure.

Thank you, sir.

Thank you.