The definition of a tech lead is a person with a technical
background, typically, an engineer who is leading a team
and particularly responsible and accountable for their technical
Direction. Hey everyone.
My name is Henry. Sorry Raven.
And you're listening to the tekhelet journal.
The show will 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. Welcome to another episode of
the tekhelet journal podcast with me, Ojos, Henry Surya,
where I won. If you have been enjoying the
podcast and would like to follow any new updates coming out of
the show. You can subscribe to our e-mail
list at technology, you know, dot f, or you can also follow
our social media channels on LinkedIn or Twitter.
I've been very encouraged by some of your likes, your posts,
your sharing, and your retweets, on those channels.
And I hope that more of them can keep coming in order to At this
podcast to more people out there.
And if you would like to pledge your support and contribute back
to the show. Make sure to check out our
patreon page at tekhelet Journal dot.
F / Patron. I will greatly appreciate your
contribution and it would help me towards achieving a goal that
I'm currently running on the page for many of you listeners
out there who have started following this show since the
beginning. Some of you asked me whether
this show is solely focused on the tech lead role due to the
The name that I use for the show, I would like to just
clarify a little bit that this show theme is around technical
leadership and Technical Excellence.
I think it just sound less catchy and a bit mouthful.
If I name the show, technical leadership journal and thus, I
chose to shorten the technical leadership to become Tech lead
and that's how I ended up naming this show as technique journal
in summary. This show is not solely focused
for just tech leads. But it also covers technical
leadership and excellence in general.
However, for those of you who are The Real Techniques out
there, do not be disappointed. In today's episode.
I am really, really excited to share with you my conversation
with Patrick qua. Pep was my ex, click in thought
works. And is someone that I look up to
and always follow for any Tech lead, related, knowledge and
wisdom. He has spent many many years
researching about the role. Roll and even came up with
training workshops and materials to teach people on how to become
a good Tech lead, including a book titled, talking with tech
leads. I have been into one of his
workshops and I must tell you that it is one of the best
resources out there to learn about being a tech lead.
Afterthought Works Pat moved to end 26, a digital banking scale
up based in Berlin to become their CTO and there he showcased
his technical Leadership skills, transforming the product and
Technology team and culture to highly aligned with the demand
of the hyper-growth scale-up company.
This episode contains a lot of our deep conversation about
tekhelet including the definition of the role, the
quality attributes, how to be effective in the row, and some
of the success measures. I highly enjoyed our
conversation and I hope that you all can learn a lot from it.
And make sure you leave me any comments or feedback about The
episode, let's get started. Are you start up in software
development Which is less than five years old.
If yes our sponsor at jetbrains have a 50% startup discount
offer, which allows startups to purchase multiple products and
subscriptions for up to 10 unique licenses over a period of
months to find out more search for jetbrains startup discount
offer or you can check out the link mention in the show notes.
Hey, Pat, It's good to see you again.
Welcome to the technology. You know, I Henry nice to see
you. Thank you very much for having
me here. Pleasure to be here.
Yeah, I'm really, really excited to have you here because I've
been following a lot of your work since that works days.
I've been in one of your Tech lead workshops as well.
I really, really enjoyed that and I hope you can share some of
the techniques wisdoms that you have here as well with the
audience. And I'm also looking forward to
learning of your talk, story, 126 and also it what you're
doing at this moment, so probably we can start with.
What are you up to now at this? This time.
Yeah, thank you very much. So I left and 26.
At the end of last year. I was there for about two and a
half years is CTO and chief scientist.
I think to explain a little bit about what I'm doing now.
I want to just give a little bit of background as to what I was
doing there. You've benefited from some of my
tech lead training and material and I'm very passionate about
the topic as you can tell. I've been doing it for a while
and that's one of the reasons I decided to go more independent.
I really enjoyed my time. Growing technical leaders and 26
Iran. This Tech lead course about five
or six times. And suddenly just because we had
so many people that both needed to go and they're totally
Journey, but also want to make sure they had the right support.
And I had a lot of requests from other companies about helping
them with building out their technical leaders and also
themselves as ctOS and VP engineering from my perspective.
It's something I enjoy doing. It seemed like there was some
man for this and as a result, I wanted to be able to do it
outside of just one company. So, that's the trade-off.
Would begin, a more permanent spot is that I could do with all
the people in that company, but then I was also a limited to
that. At the beginning of the year, I
went more independent and focused on a couple of different
things. So one of them is coaching and
mentoring of ctOS, and VP engineering's of particular,
scale up. So, I've been there as a CTO,
when you will, at that sort of top executive area.
You can feel quite lonely and it's often good to have support.
Either peers or mentors, who can help you through interesting
challenging times, particularly, with scale up or startup type
companies. A lot of people haven't had the
experience and so they just want to understand what are the
challenges and how to do that. So, I Mentoring and coaching at
an individual basis. I like working with the people
at the top of a company because they're creating the environment
for everyone else. So my theory here is that if I
can help those technical leaders, be a lot more effective
than everyone in that environment benefits from that
as well. So that's what I really enjoy
doing. The second thing.
I'm doing is running Tech lead workshops, obviously with a
current situation and covid haven't been able to do that
many in person at the beginning of the year.
It was happening. But like everyone else.
I've had to adapt of adapted that in a couple of different
ways now. So I have Self-driven learning
courses on a website called the tech lead Academy.
So, the moment of developed two courses, one about time
management and systems, thinking, I've recently launched
a online Workshop built from the ground up, particularly for this
distributed manner. It's a three-hour Workshop
because translating two days into an online to day thing.
I know just won't work. And so it's a three-hour
Workshop where there's interactive exercises.
There's interaction with myself using some tools that allow us
to do group interaction, which is a lot more effective than 0.2
0.0 pursue more hang out and then Some exercises.
I've run one of these workshops already and then I'm doing one
more per month until the end of the year.
And then I've had a little bit more free time and flexibility
to pick up some interesting projects.
So I can do things like this podcast.
Thank you very much and I meet some interesting people, like
everyone else this year. It's been a very unplanned but
also adaptive year and I'm also just really grateful that I can
do a lot of my work. Remote cool.
Thanks for sharing that. I see your career profile.
It's very interesting for me. So maybe we can go into your
career Journey, right? You spent about Almost 14 years,
in thoughtworks. The last role you have is adding
principal Technologies. And then afterwards, like, what
you mentioned, two and a half years on 26, as a CTO.
Can you maybe share with the audience hear about your career
Journey? What are some major interesting
turning points or highlights or maybe challenges that you went
through that, you want to share. So maybe we can go back to the
very beginning. I've been working for about 20
years and I wasn't one of those people that was programming as a
kid. I was actually quite lucky.
I grew up in Australia and I took a class.
In high school called, I think it was icy information,
Computing and Technology where we learnt everything about like
word processing, where we actually did do a little bit of
programming. So that was turbo.
Pascal back them. And even things like database
access programming, which is very interesting.
I just love this world of creating something out of
nothing to a certain degree like digital kind of products in that
creativity that you get. So, I decided that something I
would pursue in University and studied a business.
It degree Bond University from that.
I was really lucky to all. All into a couple of different
opportunities did an internship with bell Labs, that was part of
AT&T, which became loose into the time.
I actually learned a lot of pearl there, which is
interesting, but it's one of those hidden things that I don't
typically talk about because their own fantasy Guru Pearl.
It's like PHP, we don't like that.
When I was there, I worked on this Amazing Project built by
some really amazing engineers and I was there standing it, and
it was one of the most well-constructed designs set of
testing scripts. That I'd seen me as a Can you in
turn being able to extend? It just shows that you can
Design Systems well, regardless of language.
So I don't tend to think about language as being better or
worse. There's obviously trade-offs,
but really comes down to how people engineer things for me.
That was actually a really important lesson because when I
went into work full-time, one of my colleagues was an article
where we were doing an RD Healthcare platform for me.
I saw this engineering Excellence from Bell labs, and I
was a bit torn because we had to use these internally bill.
Frameworks which were poorly documented which were not
typically very intuitive and we didn't have a lot of training
around that. So for me, it was like an
opposite. I was actually really lucky
because during that first job in article, we were actually
experimenting with early versions of extreme programming.
I was sitting on really long telephone calls, going through a
requirement specification, trying to understand what we
needed to do for building this Health Care platform, and I was
like, those first graduate engineer saying, hey, I just
want to write some courage. Me something to do.
I don't want to just spend time reading a specification and I
managed to pester my manager enough that he actually gave me
some side projects that he never found the time to do.
So, I now put myself in his shoes.
He was injuring manager or Tech lead, but he was caught up in
meetings all the time. So he never had any opportunity
to code. He had lots of great ideas of
making things better, but he's never had the time to code.
This is actually a great opportunity that he delegated to
me. We were trying to use the first
version continuous integration server, called cruise control.
We were using a source control. All called CVS.
So if you think about get the precursor to that was version
and then because the two that were CBS, so was a few Source
Control Systems go, but the internal release processor
Oracle use a proprietary home-built version of source
control. We wanted to use continuous
integration, which was only working on CBS.
And so, I ended up using my skills with pearl to actually
write an adapter layer as people checked source files into CVS.
It would effectively mirror and push.
Although file changes into the internal source control system,
including things like tags and branches.
Those are really fun project that I worked on and we got to
play around with unit. Testing, with J unit.
We got to experiment with Deuce integration, trying to really
use the benefits of that. And also helps me underlying.
Why mindset makes a big difference in our industry?
An example I'll give you is as we were experimenting with J
unit. The first unit testing framework
or automated unit testing framework.
That I worked with people would write unit tests, but the way
that there would Right. It is they would use system out.
Print line. The current value is X and then
system out print line. The value should be why there's
something that you're not fundamentally getting about
this. Is that this old pattern of here
is how I used to debug systems simply in a different tool and
it made this interesting thing where people just follow the
tool but they're not thinking about.
What's the purpose of it in the value?
For me that's been a principle of mine thinking about when we
do use a process, when we use a tool.
We should be thinking about the value.
Get out of that. And are we getting what we
intend to get out of it? Because the context matters and
the wrong tool, the wrong process in the wrong context,
won't give you that value, or, and it can really impede you
that led me down the path of extreme programming.
Where else can I do more of this sort of stuff?
That's where I join, thought works.
And one of my first projects that I was on in Australia was
working on this startup. Probably they're more of a
scale-up they've been running for a couple of years, but they
had problems scaling their system.
So we worked with them to boost their development team and also
to also Go out their system as an example back.
Then, Oracle had release cycles of probably 8 to 12 months.
We were releasing into production every week or two
weeks in the startup. It was such a very different
environment. There was nothing like,
continuous delivery tools. There was nothing like cloud
computing back then and here we are actually releasing fairly
continuously into production short planning cycles of every
two weeks or every four week planning Horizons, and it was
just a really fun environment to work in.
I learned a lot as an engineer. They're building systems.
AC into production. And then I moved over to the UK,
where I was doing lots of Consulting for lots of different
types of companies, everything from telecoms banking government
charity. I think, for me the interesting
part here was thinking, about, not just the engineering but
also, why is it that some Engineers have, maybe a bad
experience? They can't do what they can.
And I realized I had to do a lot with the environment and it
really depended on the technically do OR manager and
how people set up that environment, one of the Reasons
I have done a lot of reading over my lifetime around good
leadership, good management has because it has such an effect on
everyone. In a company.
We have so many examples of really poor management and poor
leadership. We need more concrete advice
about how people can be more effective leaders, and managers,
so that we can unleash the potential that everyone has in
their Workforce. That's something I really enjoy
doing working as a consultant was like, working within teams,
helping people feel more empowered through adopting more
agile processes, but then also starting to work, With leaders
and managers to help them understand their style needs to
change in a very commanding control, kind of culture.
The leader role is seen as a particular type in more agile
and powered, cultures where I often find myself repeating this
Engineers. During often need to be told how
to solve problems because the essence of engineering is
problem solving what they need to understand is, what is the
problem? What are the priorities and
also, what are the constraints in that environment?
What to optimize for? What are the trade-offs to
consider? Leave the engineering?
Actually come up with the solution and implement it, but
they need help with that environment.
And so that's we're seeing leaders successful or not.
And what made them successful in these environments.
My journey went through leading teams working with Management in
other companies that we worked with to help them unleash that
and then started working with senior leadership people.
So being a director or a CTO helping them understand how they
set up the overall organization. So that leaders and then teams
could be a lot more effective as well.
Sometimes that was Context of migrating Legacy systems.
And often it was more about the organizational side when I had
the opportunity to come and see to your office.
Kayla doesn't Consulting for a long time.
It was always working through other people.
I felt it was a really good opportunity to actually move in
and actually have the accountability but also the
decision-making authority to say.
This is the organization. I would like to build as very
proud of the team that I built there.
When I came in. We had a very small engineering
team. Technology was about 50 people
of which about 35 of those Cool were product engineers and it
was a very small proportion of the business.
One of the interesting things. I noticed there was actually the
ratio of Builders to people who have ideas was way out of ratio.
And so I needed to trust that by hiring and getting that to a
good balance. But I also knew that the
business was going to grow really rapidly.
The proportion of people who had more requests or things to build
was also going to grow. So I had to really amplify
hiring which meant a very aggressive growth strategy for
our engineering team. By the time I left at the end of
last year and a half. Later growing the team from a 50
to about 370 people carry large growth.
And also that's an interesting thing because you have to think
about as things grow and you'll get different constraints and
problems. Along the way.
This was really thinking about. OK, what stages will things
break down? And so how do you change
structures team structures? How do you introduce roles or
capabilities that you didn't have before a different stages?
And then also how do you sustain that growth as your product and
engineering team is really, really growing.
And so that's led me to where I am now and I talked about at the
beginning. Wow, it's pretty impressive
journey, I would say there are lots of learnings that you share
with us as well, which are pretty good.
We can dive deep obviously later, but I want to start with
your bread and butter which is technically you can doing this
for. I don't know how many years now.
Yeah, probably almost ten years. Alright.
Wow, that's pretty long. So maybe let's start with what
is the definition of tech lead? I know there is no clear.
Definition is pretty abstract for some people.
But is there any good definition from you?
What is attacked lead? Well, carry it this way.
Saying every company is different.
So sometimes people might call them a engineering manager.
Sometimes it might be a lead developer.
But for me, the definition of a tech lead is a person with a
technical background, typically, an engineer who is leading a
team and particularly responsible and accountable for
their technical Direction. Sometimes you might call an
architect. But these people are typically
more Hands-On working in a team. So some Architects tend to float
around but this is really somebody who is a counted with a
team and really aligning team and their technical Direction.
The reason I think that's important is often a good high
performing. Team will probably work
naturally towards a different direction.
But in a lot of cases, people disagree.
And the question is, what happens when you disagree, you
need, somebody to make sure that things are moving in the same
direction. So that's the essence of a tech
lead for me. So in the first place, why are
you so interested in researching more about this?
Because obviously you were doing some kind of tech lead role
during your projects, probably in thoughtworks Consulting and
all that. But what made you decide that
you want to dive deeper? And deep and deep and even come
up with instead of workshops during your tire there.
That's a good question. And I think like a lot of things
that comes down to a personal experience.
I still remember when I was pushed into this role for the
first time is that nobody explained to me that
expectations of this. Nobody helps me understand.
Okay, if these are their expectations, there was no
recognition of where your skills are.
And also, where do you need to grow?
I see this repeatedly in so many companies where I think things
like management. There's a little bit.
More training in general, around this at leadership and
management. There's a lot of generic courses
that talk about that but the technical lead role I feel is a
little bit special and that there are these expectations of
what somebody should be able to do in this role that a people
don't talk about. And then be, there's no support
for giving people. The skills of doing that
typically people are moved into this role because it's a gut
feel that they're the most senior or feels like they're our
Tech lead and they're ready to be that, but there's no
discussion in preparation for that.
I guess where the origins of my Is for this is a mystery.
It's just really bad at this and I really want to help our
industry. Get better at helping technical
leaders, move into this role published a lot of Articles book
and a lot of talks about this topic and I hope it really helps
people who are transitioning into that role or particular
companies thinking about establishing this role about how
to help people move into this role easier, because I've seen
too many times when it goes wrong, you get a most senior
engineer, as an example who gets put into a tech lead role and
suddenly they're turning around telling one exactly how to write
code and how to structure code that the dictator type of person
and nobody wants to work with them ever again, and they have a
bad experience because they think my team isn't working
well, or I'm working with poor performing people.
They don't realize they're contributing to that as a system
and nobody's really sat down and told them he has a different way
of approaching that it's about experience.
For that person who maybe gets traumatized never wants to do a
leadership role. Again, it's bad for the people
who work in the team because they don't get to bring their
potential out and it's bad for the company because Typically
won't deliver an effective software project.
If we invert that and give people a really good opportunity
to transition into that role with the right structure for me.
It's the theory that they have the best likelihood of success.
There's no guarantee when it comes to people, you can't force
people to learn. You can't force people to make
good decisions, you hope that they're good decisions.
But if you can support people in that transition and hopefully
they'll have a better experience.
They'll function better. They'll build a team at aligned
around technical choices and hopefully you end up with a
better software project. A better team atmosphere and the
company benefits as well. So I see it.
As a win-win. You have been around for quite a
number of years. You'll probably have to work a
lot of engineering teams. What I'm trying to ask is that,
have you seen the trend changing to the better or is it probably
much the same than the previous one.
I do believe that we're getting better.
I think industry is relatively young still and one of the
reasons I've published talking with tech leads.
I think it's 2014 was there was nothing really around the sort
of material and today. There's a lot of books and a lot
of talks and a lot more communities around engineering
leadership or management. I think one of the really great
book that gives people a good insight into many different
career paths is the managers path by Camille for Nia
outlines. What does that look like on the
journey into being? Maybe a CTO and what are the
skills and changes in responsibilities?
Along that pathway in Europe. We have a community or a
conference called the lead Dev. They used to run these
engineering leadership type things.
I see a lot more people speaking about this topic a lot.
More knowledge that is out there and I think that's really great
because more stuff that we can get out there.
The more accessible it is and we just have so many people coming
to our industry, where more support from different
perspectives is always going to be better.
It's very good to hear that. So you mentioned a lot of things
about the responsibilities of tech lead.
They need to make technical Direction obviously because of
that, they need to know some technical skills.
And also they need to work with people managing, either above or
below within the team or even themselves.
So maybe, can you share with us? What are some of the
fundamental? Those skills are good attributes
of a good, technical lead. It's a great question.
Let's start off with the technical side.
It's difficult to lead. Technical topics, unless you
understand what people are talking about.
So, I think this is where there's a little bit of
rebuffed. When you hear about people
saying, I don't want a non technical manager and that's
okay to have a non technical manager.
If they're not responsible for leading technical decisions.
That's where for me, the difference of that technical
lead, is to understand what a good technical decision.
They need to understand what is being talked about from that
side. Your concrete example is if
you're trying to decide of breaking up a service into
different types of microservices, somebody who
needs to understand how that system is built and the
trade-offs associated, with breaking up, the system in a
certain way. They need to really be able to
understand that quite intimately to understand if it's a good
choice or not. That's a little bit different if
they're thinking about the team and how that's actually
functioning. That's a little bit more
generic. You don't need to be technical
to understand our people, collaborating.
Well, are they avoiding difficult conversations?
Still difficult? Perfect, but it's not so
technical. As if you're trying to choose
the right tools and you're trying to understand how to
improve developer productivity, and also maybe set the right
example patterns. So if you have a less
experienced team, a technical lead, might actually be quite
Hands-On to establish good. First time practices.
There's that technical side of being a good, technical leaders
that they need to have enough technical background, who better
to do that. Well, I do like to say that a
tech lead is often, not necessarily the best engineer on
the team. Sometimes, they are if you're in
a less experienced him, but the technique, Its function is not
just to be the expert on everything.
It's just impossible to be an expert on everything, but they
need to understand enough to be able to lead technical topics.
The second Focus there that I want to talk about is then the
leadership side of being the tech lead and this is really
different skill sets. And this is why I sometimes the
best Engineers aren't great, tech leads is because they have
such a deficit in leadership skills.
So a good leader for instance will know how to engage the
entire team to bring in many different opinions and to get
the best solution out of that. Itself requires interesting
facilitation skills, the right questioning skills, the right
ability to create an inclusive environment, that allows
everyone to feel safe to contribute their ideas.
But then also a way to bring those ideas together to unify
them. And then also to get that buy-in
from a team that itself is not a technical skill, that is a
leadership skill that you have to develop and practice and not
all great Engineers automatically have that.
And so that's why a lot of first-time that leads fail
because they don't realize actually need to draw.
On these great leadership skills.
You have to listen to people in your team or they'll get
disengage. Do you want to make sure that a
decision gets made Fairly rapidly rather than having
conflicting opinions with people go on under the surface?
For a very long time. That's the second area of that
Tech lead role is thinking about that leadership perspective.
The way, I tend to think about, this is a tech leaders
typically, leading within that team.
So making sure that there's a consistent angle Direction,
caring about technical quality to make sure that there's a grid
process. Some things like that.
There's definitely leading outside of that team.
Typically, you're maybe working with stakeholders to manage
expectations. You're maybe working with a peer
product manager to make sure that you're also aligned.
So technical direction is heading in a way that supports a
product strategy or the direction.
And also, you have to be able to lead yourself, you touched upon
this, a little bit earlier in that a lot of first-time leaders
don't realize how they communicate, how they react to
something has a kind of multiplying effect key part of
first time, ladies, I do this with a lot of Engineers and
Allure of helping them build up a little bit of emotional
intelligence to be aware of how they're actually feeling about
something, but also not to let those feelings automatically
dictate, how they react to something.
There's a skill in noticing and observing how you're feeling
being able to call out what that emotion is.
And then also then to not let that interfere with how you
decide to lead, or how you decide to communicate or handle
a particular topic. Today are some of the different
broad categories of skills that I would expect from a tech lead.
It seems like there are so many things for you to be able to Be
a good technical leader. So, I myself, personally also
struggled during that period in the beginning, when I became
Tech lead either like in a project team or in a Consulting
project as well with the clients and at times, I feel sometimes
it's a bit difficult, especially if you knew how to measure your
Effectiveness as a tech lead because you see there, so many
things in play here, for example, you need to know the
technical skills. You need to be able to make
technical decisions. Sometimes it's a hard technical
decisions, where people probably do not agree with each other and
also you need to be able to manage.
People your team, maybe your stakeholders as well and
yourself internet, maybe imposter syndrome or how to
catch up with all these new technologies that the people are
throwing up to you. Maybe you can share tips on how
to measure yourself whether you are good in terms of managing,
this kind of rule. So one of the transitions I talk
about when people move on, this is moving away from what I call
maker to multiplier thinking when you're a maker.
So if you're thinking about a developer you often think about
what is it that you have created, what have you produced?
And typically, that's Our feature of something like that,
when you're in a leadership role, you need to transition
into what is that multiplier perspective?
And the challenge with this, which I know this is an engineer
is that you don't get that immediate satisfaction.
So you have to deal with look, feedback loops.
Sometimes there are some closed loops and that you don't get
confirmation and it's often the challenge, basically for tech
leads is it's not binary anymore.
If you have a function or feature it works or it doesn't
work. It's a yes or no your build is
red or it's green. So you have these binary habits,
but then when you are Dealing with people organizations.
It's never really clear if you're done, or if it's good.
It's a little bit more thinking about good enough.
So I think recognizing you have to move from makers and multiply
mode is one of the success factors and when you think about
multiplier mode when you think about that success there, when
you reframe that is how much have you done to multiply the
effectiveness of your team, then you end up with a broader set of
options. And so one way that you can
think about it is thinking about alternative Paths of reality.
What could have happened if you Intervene, if you didn't
actually intervene in a conversation between two
developers who are constantly arguing, and if you let that run
for weeks, you can have a lot of messy code and tap debt.
And by recognizing. Oh actually we had a difficult
discussion. We had this agreement but
actually at the end of that week, we came to an agreement
that sort of success itself is great.
Have to recognize that actually you've helped multiply the
effectiveness of your team. One of the things that a lot of
leaders need to do is often unblocking or creating a path
for the team with all the Plex city of an organization will
dependencies or things like that.
And once again, it's like those things, those little wins about
blocking things. These are things you should add
into to answer that question about what have I done to help?
Multiply the effectiveness of that, team things like
encouraging learning or knowledge.
Sharing is a really great example of improving, the team's
ability to deal with more complexity to create a high
performing team that actually collaborates.
Well, that itself is also a great thing to be a multiplayer.
And to measure success. I think the challenge here is
that you don't have your ever done kind of thing.
And I think that's the big lesson here is you have to
almost to accumulate actions or a series of wins, but it's not
like you're ever done. You're not ever done with
building a high performing team. You have to kind of sustain it.
As you evolve your architecture your system.
Once again, it's never done. You have to keep it supples,
keeper easy to change, make it resilient over time.
I think for me the ultimate test is your team working.
Well, is it delivering? All you to customers and to the
company. And if you're doing all of that,
that itself is a good enough test.
It's the question of what have you done to help make that
happen? A lot more effectively.
So another question around this, especially from me personally,
all these obviously are great, but they are abstract at times
because there are so many things being thrown at you.
For example, number of meetings that you have to go through and
you have to go with individuals. Checking with them.
Are they comfortable with whatever that they're doing at
this moment? Setting up technical directions,
which could be either weeks, months ahead spending time there
and also in the spirit of Jarrah doing this retrospective of
personal reflection personally. Do you have any quantifiable
things normally that you would measure in terms of technical
leadership? So, I think for tech leads in a
team, one thing that would be a measure would be how much time
do you spend in the code. And what I mean by that is not
necessarily writing code, but even at least reading and
reviewing code, the challenges that tech leads have if they're
going to lead things effectively is they have to understand what
the current state that system looks like.
So it's hard to understand technical.
Risk, if you don't understand how that system is developing
and because you have lots of people typically, modifying a
system. It never stays the same.
The trick here is not to read every single line of code.
But to get a good sense of how you delve into areas that you
think are risky areas. Ultimately, a lot of leadership
is about managing risk and a tech leaders, particularly
around managing the technical risk of the system.
I think one of the best ways of doing that is also delegating
things to other people, a lot of first-time leaders, sometimes
feel a bit guilty about delegating.
I do want to distract my team from doing something.
But if it's done, right? You got to create opportunities
for people to grow. For instance.
If I met Lee, that's first the only person looking at technical
risks, I might then start to work with people of my team to
help spread more of that Village around what I look for, how to
go about looking for it. And then I might also create a
more informal opportunity to say I'm going away on holidays for
two weeks. Can you be the person that's
watching out for an eating things and to maybe raise this
at stand up, or raise this with the team that you think is
risky. So you're slowly delegating
these things and for a lot of people, it's a great opportunity
for them to grow as As well because it's something they've
never done before. That's a win-win.
If you delegate effectively as well and then that creates more
time for you as well. So that's definitely one of the
measures there. How much time do you spend with
the system? The second one is thinking back
to that alternative reality is that I think a good sign of
technical leadership is the lack of problems.
So the lack of emergencies is actually a very good sign
because it means there may be managing enough workflow.
The risk could be that people just keep quitting so that This
is a technical risk and it's a lack of Engagement or a lack of
growth. Maybe people aren't growing.
That's a leadership thing to. Look at when I think about
really good leaders. I think of things happening very
smoothly. Of course, not everything is
completely perfect. But I think the number of
emergencies is definitely a worry about something going
wrong. If you don't have any
emergencies, I think that's a good sign.
You can think about this from a technical perspective of how
many service outages. Do you have?
How many builds get broken all the time?
I think a healthy team should break the build every so often.
Often, but they shouldn't be broken for too long.
And that's a couple of measures, I would think about good
technical leadership. So some of the typical
challenges for Tech lead, especially those that come from
strong, engineering background, one of the typical challenge
that I see a lot. Is that being able to let go?
For example, a lot of time, strong technical background,
people tend to have an opinionated Solutions, or even
the effects, like, whatever that is.
How do you think we should overcome that being able to sit
back and try to let go of all these kind of decisions?
Just not to be solely on you as a technical it, but also giving
people the opportunity to make the decision together as a team.
This is really a journey to leadership for a lot of people.
And I go back to the idea of making to multiply mode as a
maker. You're typically invested in the
craft of how you built something of how that solution was like
your solution when you move to multiplayer mode, and I think
that's the hardest shift is really getting that mindset
shift into thinking. You shouldn't be rewarded for
what you personally have produced.
But really, what the team is producing and how they're
producing that would that mindset or thinking about the
team, rather than yourself? That's the kind of Journey that
people have to go through to step back a little bit.
And then I think the challenge that people have is often
getting the feedback early enough.
When they're falling to patterns of behavior.
Sometimes their actions. They don't realize they're
actually constraining and team as an example.
I worked with some tech leads in the past.
Who when they moved into that role.
They thought they were doing their team of favor by taking
all the hard problems. I don't want my team to be
stressed out. I'm the most senior person.
I'm going to take care of all the complexity but then the
challenges you alluded to like a you have a lot of meetings be
have to communicate a lot more and get that Focus time as much
as you do as a developer. Typically what happens is those
people get really stressed out because they're trying to do too
much. So they're trying to tackle
complexity. They're trying to do all the
other sort of responsibilities. And then the side effect that
they don't see is people don't have an opportunity to basically
tackle more complex problems, which is often a way that people
can grow as engineers. As Engineers solve certain
problems. They want more complex problems
or different problems. What a lot of people that
leadership role don't realize they're doing is that they're
actually limiting the growth of their people and their team will
eventually disengage because they don't have any interesting
work. This is something that people
don't really understand if they're a really focused on
themselves versus focusing on what's better for the whole
team, but it is really hard because you have your style of
wanting to do things. You want to see your preferences
come out. One of the things that can
really help here is a Focus on outcome rather than output.
Typically. A lot of first-time leaders will
be focused on how something is going to be done.
That's the output. So the method exactly how that
could work be structured or the service design.
What they should really be focused on is really outcome.
Did we achieve what we needed to do to help customer problems?
Or have we improve resilience for certain way because if
you're really doing that then that's real test of leadership
versus actually how you have actually done things.
I will say that it does. Is sometimes matter to focus on
the how and the outcome because that's really coming down to the
alignment of the team. That's something that I do think
technical leaders, do need to be careful of.
You don't want suddenly 5 persistence Frameworks because
everyone wants their own style of writing stuff to a database
or table or something. You need some consistency.
So that there's a team sort of feel and so maybe going back to
your thing about a test of does the code look like it was
written by a single person. That's one of the things that I
typically think about or does it look like it's a team owned
thing, or is it actually very highly siloed where you can see
People's personalities based on code.
So that's a kind of anti pattern.
Yeah. I've seen such good before and
it was not fun to read that especially when you travel to
another class and wow, it's different.
So I noticed when you define the technically, that's one thing
that I think in my opinion is not explicitly mention, which is
the business portion understanding about the business
about the company, about Revenue, how the company make
money is this intentionally defined that way you mentioned
also in the beginning that there are Many definitions are
affected. Some people call it engineering
managers and probably even call it.
CTO, is this? Where the place where the focus
on business, is more towards City, oppresses the technique.
It's a great question. And I think I didn't really
emphasize it because my expectation, is that every good
engineer focuses on the business.
I know that's not the reality. But my underlying Assumption of
a good engineer, is that they should also be caring about how
their work has an impact of some sort, but you're right leads, do
need to be a lot more engaged with the business and that sort
of escalates three. Really comes back down to the
outcome. What are you really trying to
optimize for? What are the constraints that
you make decisions by? If you're in a financial
services, you'll need to think about things like regulation and
how you build software will change because of that context,
leaders have to be really aware of what that business outcome,
ins. But also the current parties of
the business in covid X. Some businesses are a lot more
cash-strapped because of their business model.
That means that actually you probably need to be very
cognizant of how that comes into your team.
Training budgets. You probably cut used during
that time or you have to think of ways of cutting costs as a
business and all good leaders will also be thinking about how
their work contributes, the bigger broader goals, but I also
challenge that every good Engineers should be really
focused on that. That was one thing that I
learned from agile, very early on which is about engineers that
come up with technical things to do without being able to link it
to business value to me the heart of every good engineer and
that applies equally to tech leads and all the people in
leadership chain, should be really focused on what is the
business outcome. Value that their work is doing
and I can think of now that you've entered so many counter
examples of tech leads who go. I just want to walk around with
X tool. So coming up with some reason
but there's no business value out of it.
And typically they have some fun, but then the business turns
around says, hey, what have you been doing for three months?
Why are we doing this? No, you're not going to have
this anymore and then the team gets disassembled or something
like that. Everything always has to have a
value of some sort and leaders and Engineers.
Really need to be focused on that.
Thank you for your clarification.
I really like That a good engineer needs to care about the
business and the impact, they're bringing to the, overall growth
of the company or whatever business measures that they are
measuring. I think this is also a good
segue to move to your next row, which is becoming a CTO at 10:26
and you kind of mention in the beginning.
You want to move to a position where you have more
accountability and also have more responsibility in terms of
decision-making. Aligning.
The whole team is also an interesting Journey where you
keep mentioning about scale up. And there are many companies who
aspire to scale as much as possible.
Their business growth. Can you probably tell us during
that time? What are some of the first
things that you did as a CTO which was still small size
around 50 people? You mention, what are some of
the first things that you did? So before I talk about what I
did, I want to talk about my thought, process behind it,
because that's something that a lot of people don't get insights
into firstly. Every CTO is different.
The number of types are archetypes and situations for
ctOS, are even more diverse than probably the types of techniques
that you have. I think the name of a CTO is
one. Of the most poorly named titles
as well, because it's a bit of a placeholder for you, have some
sort of technical responsibility and you just make stuff work in
some places. It's a lot more strictly
defined. For example, it might be a bit
more R&D, technical strategy about 35 year roadmap other
people might be about the currents technical direction for
the platform. There's some basis to around the
technology in that team, but just be aware.
That actually the role of a CTO is really different when I came
into and 26. It was one of the things I was
trying to get an understanding of is, what's the focus point
for this role. What's the thing?
Is that will deliver? The most value is a question
that I have? That's why it's different in
every situation because when I left for instance, we would have
a different set of challenges because the organization has
grown and evolved as a result. One of the things I encourage
leaders to do is to take stock of the environment, understand
what your environment is like before you make decisions.
So I don't believe in cargo cult Ting, even though it worked in
agile Fashions. I didn't really come in and say
we're all doing extreme programming.
I didn't really enforce these kind of things.
I really wanted to understand what Was there in that
environment? What was already working really?
Well? And then also what were
constraints or problems or challenges that were in the
current environment? So My Philosophy to management
is you don't need to manage people.
You need to manage the environment to bring out the
best in people. That's what I was looking for.
I really believe that good management is dealing with the
topics that people recognize but they don't maybe feel empowered
to address as an example, as we were growing and scaling one of
the topics that was coming up was things that were starting
to. Full between teams, we had some
teams that had ownerships of product areas, but then you
started to notice, maybe the interfaces, or a service bus or
something between the teams started not to have a strong
sense of ownership. And so there was a lot of
conflict around that there was a lot of frustrations.
A lot of that came down to lack of clarity of maybe who's
accountable or how to go about solving this.
So I see that as a management problem of the certain
structures that you've got the moment leading to this and you
need to think about ways of tackling the constraint on that
problem. Mm.
I was cataloguing. What are some of these problems?
One of the big ones was, obviously this ratio of product,
engineering to non product, engineering people to give you
an example product, engineering was eight percent of the entire
company. We had about 450 people in the
company of which 35 people were product engineering, even if you
just ask 20% of those people for something, you have no capacity
to actually build that. That was a huge challenge, which
I realized I needed to work on both in recruiting also
retaining and then looking at that recruiting process at the
same time. One of the next set of
challenges that it was going to happen.
Was as we grew the organization, particularly the tech
organization. There's the old saying of what
got you here, won't get you there.
What worked for you at a certain scale won't work for you and
another certain scale. That's true.
As a leader, what works for the you.
As an engineer won't make you an effective Tech lead necessarily.
So you need to keep thinking about these Transitions.
And then also thinking about what's a good fit for the next
transition. One of the things that I
realized is, as we move from 50 people and we get to 150 people.
You just simply can't get over. Ran into the same room in a
start-up mode. People are just used to talking
to each other face-to-face. They grab somebody that they
trust. They go into a room and then
they make a decision and that habit works.
Okay, Addison scale, but then it starts to break down as we were
growing. As also starting to look at how
do we think about processes or structures that would help us
scale and particularly as we started to go distributed, as we
open up an office in New York, as we open up an office in
Barcelona. These are very different
communication and cultural challenges.
Where if you're all center around one headquarter thing.
It's natural that people just focus on headquarters and they
forget about satellite offices. And this is something that I
basically tried to really invert.
I really trying to build up a culture of inclusivity to make
sure that all the other officers were treated as equals versus a
secondary or third kind of office.
The other thing that I worked out is that I needed to work out
how to scale myself. My focus as a leader is looking
at. How do we be more productive as
an organization? How do I multiply that?
And there's only so much that I could do.
That was the other side of what I was going to do, which is what
Has my leadership team look like how does that Cascade into the
organization? And how do we support our team
to do all the things that we need to have?
Then there's this hiring pipeline as well getting that
all up and running onboarding and getting the structures there
in place. That's the story of what I was
focused on when I first got there.
And some of the areas that I was really trying to address.
Thanks for sharing that I'm interested in this ratio, like
way of sight. For example, only 8% product
Engineers within the company and I see this quite a few times as
well, especially in small startups, for example, the They
have typically few Engineers trying to build a product and
then you have a big number of people at the management, who
are throwing a bunch of features for them to build.
So, in the first place, how do you actually convince the
management to actually see the investment in hiring?
More Engineers is worth it? Because, maybe in some cities,
it's pretty expensive to hire Engineers.
So the more you have them on board, obviously, the more
expenses that you will have, how do you convince them?
That's the first thing. And the second thing is about
when they agree, how do you actually hire other?
Things that you follow or framework for hiring people, to
be able to reach that skill. It's a great question to let's
first, tackle, the first one, how to convince people.
So in our case it was not so difficult to convince people
part of it was to present the industry, metrics to a certain
degree. Now, there's no exact number but
8% is really, really small. If we were in a logistics type
of business like Amazon or something with delivery, then of
course, I wouldn't expect a fifty fifty percent ratio of a
company to be Engineers, but we were More digital firm than
something that has a lot of logistics or Hardware type
stuff. So, just giving people a sense
of okay, here is how other companies are.
This is what we are. And that's definitely one thing
that definitely helps just in terms of Industry.
Benchmarking, and just getting a sense of what is a average size.
The second thing was really trying to focus on teaching our
leadership team about Theory constraints.
I did this a lot as a child coach in working with product
teams is helping people understand adding people to a
non bottleneck doesn't really actually help the system over.
All typically, the area that happens when you're dealing with
the digital product is the engineering side.
I kept saying everyone has ideas.
You've got ideas. I've got ideas.
We've all got 59 years. That is not the problem.
We don't need more people. That generate that, that's not
the thing. That is actually generating
value. I also want people through
Littles law, which teaches people, that's a longer.
The Hue is a more slowly, the overall system will go because
everyone is fighting for their pet project.
They want some time but it's actually the focus on the most
valuable thing for the business. Right now, helping people Stand
that and how the system works overall helped people really
understand for us to actually be able to achieve more.
It doesn't really make sense to hire more people with ideas.
We actually need to hide Builders.
So just getting a good sense of that.
And then getting a good ratio. Now, in some businesses and I
think this is important to understand is that I think it's
actually also bad to have too many Engineers too early in a
start-up where you're still discovering product Market, fit.
It may make more sense to have more sales people to try to,
really make sure that there is that interest there boo, hire
more engineers. Veneers.
Because I think another bad thing that can happen that I've
seen in some companies is that you have too many Engineers with
not enough to do and they get bored and they invent things to
do, which I actually delivering value.
So you can go the other way as well.
That's where business value. Focus is really important for
leaders is to know which context you're operating to really
understand what is going to bring the business forward the
most, but it was pretty clear when I came in that, we had so
many different things that we do to launch.
We wanted to launch your products.
We want to launch you markets. We want to launch your so many
different things. We wanted to keep changing
things that we already had. But like, who are you going to
get to do any of this? It's the same people.
We obviously need to change that and ZIP down.
People put two and two together with business people.
They don't really understand that maybe the
interconnectedness of software. They have a little bit more.
Sometimes, a factory mindset of inventory.
I can produce more Supply. If I multiply, I can create more
stock. I didn't have to go too much
into the depths of why software is more complex to kind of
stuff. But simply the fact that we
don't have enough, people is definitely affecting our output
at some point. And then it's up to me as a
leader to make sure that they're structured well, so they can be
as Productive as possible. Let's first part of your
question of your convince people.
Well, the second one that you asked, which I think was how to
hire people. I think this goes back to the
first question or thinking about first principles is, what are
you hiring for? And what does that mean?
When I was thinking about hiring, one of the things I
write being about a leader is that you get to create the
environment of the culture that you have.
And so for me coming from agile ground, I really want to build a
self-empowered collaborative, team environment.
And so naturally I want to look for the best things during the
Be a persis now with hiring. It's challenging because it's
challenging for everyone to hire.
One of the things I was asking myself is what is it that I can
offer as an opportunity for people to grow or interesting
problems for certain people so that I can attract people who
want to work on those types of problems.
For instance, working in a fintech bank.
I'm not going to attract somebody who wants to work on a
music product like Spotify, but there's some interesting things
of either the scale-up challenges or where your
business is now that provide growth opportunities for people.
So I think trying to still, what is your culture down to distill?
What is it that your environment can offer right now?
And then also to communicate that out.
Well, is a important part of hiring.
That's probably where I was doing quite a lot of talks to
let people know. We are here is what we're about.
That's definitely one of those keys to the areas and we end up
building a Blog to also write a lot more about that.
That's why you see a lot of engineering blogs is that people
want insights into how you build things?
Is this how I like to build stuff.
There are companies that are a bit more Hack and Slash and
there are other companies that are maybe more robust by
Disability or transparency of that.
Then people will naturally get a bit more attracted to that as
you go. So, I think that's the
attracting side and then when you think about the hiring
process, I think is really key because this is something that
we Revisited. A number of times.
As we grew, it was really trying to be clear about what traits
you're hiring for. As an example.
I don't really believe in whiteboard exercises,
algorithmic tests, because often They Don't Really Connect into
what people do on a day-to-day basis.
When I work with people to build a hiring process.
The first thing I'm thinking about, is a What is expected
from this role? So what are the skills or
experiences from that and then be, what's the best way of
getting an example of capability around that either through a
simulation either through talking through past experiences
or seeing some of the skills in action for some of our more
senior leadership roles. For instance.
There would be a case study where they would have to talk
about how they would handle a certain case for programmers.
They would be dealing with a specific problem and then they
had a show code because we wanted to see some of that
capability, but I don't believe in doing things.
Things for the sake of doing it just because other companies do
it. Once again.
It really has to come back to. What do you get out of that?
And what's the best way of doing it?
The other thing that I really think is very important, which a
lot of people forget during the hiring process is remember, it's
a two-way street. People are interviewing you and
your company as much as you are interviewing them.
That's a really important thing to keep in mind, is that for
some people, it may not work out in this current situation, but
in the future, the opportunity May align.
Also you have to train people who are going to be part of that
process to help them. And they're testing you as much
as you are. Testing them are these people
who only work with in the future.
Can I learn something from these people or are these people fully
arrogant over thinking that the best and brightest and they're
trying to shame me because they want to show you how good their
knowledge is. So that's something that you
have to do a lot with people who are many first-time interviewing
as well, because it's a skill, and you have to really make sure
that people are trained for that as well.
Thanks for sharing that, I think some of the good tips for those
of you who are hiring as well coming back to this city of
asustek later, as you mentioned all.
The last few minutes, your responsibilities tends to change
when you are at the CTO level. So you have the public facing
part of you. You have the hiring part.
You have the internal with the business.
You have also within the engineering team.
What kind of Direction, what kind of culture that you have to
build. So obviously, we only have 24
hours in the time from it. So how do you balance all these
with more and more responsibilities?
As you climb up the chain in the leadership ox2?
This is how well you can build a team and how well you can
delegate. That's really the sense of
effective leadership if you think about sat here at
Microsoft because another person who's going to be writing every
single product in Microsoft. He just simply doesn't have the
time but the reason he can run something like Microsoft is his
built, a good leadership team and management team where he can
trust and delegate. That the art of any leader is
knowing what part you can play in that sort of bigger picture.
But also, what's the right people that you can grow and
hire, sometimes you can grow them internally and promote.
Sometimes you may have to bring in those skills externally and
then just find a way of letting them work.
Together as well. The essence of it is knowing how
to delegate something, knowing how to give people
responsibility and then also manage that system, so that
people can work. Well, effectively in that
overall system. The hardest thing for me as a
CTO and 26 is everything was changing and my role specifics,
probably change about six or seven times throughout that
Journey. Very early on, I was deep into
our sort of system architecture, really trying to understand how
our teams were building things. But as I grew, and hired people
in to take care of certain, In areas, then I felt I could step
back. Obviously.
I want to dive in to get some confidence every so often if
everything's running smoothly. So once again, that lack of
problems, then I can think about different types of challenges.
And what's the next most valuable thing.
I can focus on that can unleash more or multiply more of the
people that we have or unleash more value to the business.
I saw one of the blog post that you wrote few years back.
Probably, or even one or two years ago is about Target.
Operating model. I think it's very interesting,
right? Up and the framework how it
works. Would you be able to share?
What is a Tom and how do you actually use it?
So the purpose of the Tom is to be purposeful in organizational
design. The essence of it is to be
explicit to be transparent around watching organization.
Looks like and I talked about it in the context of necessarily
the tech organization, but you could use this concept as well.
If you're a CEO and you're thinking about the overall
organization, as I was, describing our journey going for
a fifty to three hundred fifty over two and a half years.
A lot of Things need to change along that way.
And so I knew that early on, I wanted to be intentional about
how we did that, and that was the purpose of introducing, this
target operating model when we were 50.
And then I said, in the next year, we're going to go to about
150 people. But this means that a lot of
things going to break. And so here is what I think is a
good structure that will help us scale to this next size or
scale. So, that's the idea.
It's the target. So where would we like to be?
And it helps people move, and understand that the goal there
is it's not supposed to replace. Product road maps will technical
roadmap, so it's about the how we work together the structures
of how we communicate or areas of ownership.
So that's the operating side of the target operating model.
It's a model. So it's not a perfect
representation of reality because things will never be
perfectly a defined people don't fit into boxes, but it's really
a tool to have conversations around as an example.
When I first introduced the target operating model.
We were moving from a couple of product teams, too many
different product teams. One of the things I wanted to
do. Ooh, was introduced in entering
manager role and you find that role that was going to be new
because we had tech leads, and some of the responsibilities
would shift. So tech leads were responsible
for people management. I would argue that some of our
tech leads weren't the strongest at people management and they'd
often preferred technicals topics.
And so that was one of the areas that came up as I was observing.
The environment is that we didn't have a lot of skill or
capability or maybe time to focus on actually building High
performing teams and actually building in.
Visuals. So that their team would be
stronger when I introduced the entering manager role where I
wanted to introduce a little bit more of a team focused
engineering manager role and the goal would be that they would
work with tech leads. So they didn't have to worry
about the technical Direction. They would delegate and work and
partner with the tech lead, but then somebody would be focused
on building a high performing, team building, good team,
processes working agreements, making sure that individuals got
good one to ones had growth plans and how that all fits
together as well. That's an example of of in the
Target operating model of saying okay, we're going to have these
teams and we don't have all of these teams today and we don't
have all of these people, but we're going to have these
nominal teams with these roles and here's how they will all fit
together. One of the other roles that I
started to introduce was also the director of software
engineering when I came in. I inherited I think it was
something like 12 direct reports and I Knew by the time that I
was hiring, I was going to end up with probably about 17 or 18.
I was like, this is impossible. I promised everyone.
I would give her an at least half an hour, every Fortnight of
one-to-one time. Which I did for the entirety.
But once again, the things that were few or one stage will break
down at a certain scale, and that's why I got the director of
software engineering in is that injury managers will report to
director of software engineering, and then tech leads
at the time would report in to me.
And then that was enough to get us to the next stage.
That was the basis for our current plan.
It was the basis for a whole organization to really come
together. We would naturally take feedback
as things were evolving to see how things were improving as our
organization got bigger. Naturally.
The model starts to maybe Break down or you start to say, okay.
We're noticing different problems.
When you have at that time, we had probably like 12 or 15
different product teams. You then needed a way of
thinking a bit more conceptually about, not just lots and lots of
teams but maybe a product area with lots of teams within that
product area that then led to another evolution in our Target
operating model, where we introduce another constructs
that solve problems that we had. Which was how do you think about
the overall organization without having to go to every single
team? And so we decided to have what
we call a product groups which were Like many areas and each
group would have a series of teams in it.
If you are new to the business, you don't have to worry about
how teams were broken down and say payments area.
There was just a product group of payment stuff.
And if you interacted with them, of course, you would want to
understand which team is responsible for what, but for
most Simplicity you didn't have to worry about that unless you
had to be a lot more involved. So the target operating model
and we went through three iterations, when I was there and
the goal there was really once again to help us Orient as an
organization about how we work. So we didn't just say when
Adopting Spotify, how they work? Because we have different
problems. We had different problems at
different stages and the target operating model was a way of
creating common understanding around new roles
responsibilities and how they all work together.
So towards the end. You also evolved in terms of
role as Royal from CTO. You become like Chief
scientists. I haven't heard a lot about
Chief scientist role in a start-up.
Can you share with us? What is the chief scientist
Rule? And what made you transform to
become this role? So, once again, I think it comes
down to You that thinking about what you do thinking about, what
the business needs where your skills capabilities interests
are and what brings out forward. The reason I created this role
in stepped into this role is as we all sort of growing the role
of what they needed from a CTO was a little bit more
operational. This is really about keeping
delivery going with a product roadmap.
It was a lot more about metrics and Reporting.
And that's not really interesting for me.
It's not something that I enjoy doing a can do it, but it's not
something that energizes me. And the thing that really drives
me was growing. Showing other people in the
business, in our technical team and also seeing what's
interesting there, an amplifier map.
And so that's why I think about this Chief scientist role is.
It's about going through organization and sometimes it
might be just working with a team for a bit to say.
Hey, that's an interesting service that you're building
here. Does other people in our
business know about this, we should talk more about this
because this is actually something that can amplify that
I know other teams have problems with.
It's like going through and seeing ways that you can amplify
and spread knowledge across that.
So scientist in the way that one maybe observes a system and then
tries to maybe design experiments or hypotheses from
observing that system and then try to improve that.
During that time. I did a lot of mentoring,
helping a lot of people grow, a lot of knowledge exchange around
what's actually going on. And so, it's less attached to
the operational side of the business, which is the phase of
where we were at. And it wasn't so interesting for
me from that side. Before we move on to the last
question. Any other resources are probably
tips for those aspiring technically.
Leaders or season technical leaders out there.
What can they learn from? Or where do they have to go to
in order to level up themselves? So I'm going to do a bit of
self-promotion here. There's a level up newsletter
that I actually run. It's a Weekly Newsletter.
Let's level up dot patch, quiet calm and it's a leadership
medical leadership newsletter that focuses on leadership
topics technical topics and organization process topics.
So three areas, I think all technical leaders should think
about regardless of what level that you're at an organization,
I send out weekly that's definitely You can sign up for,
there's a lot of great material out there.
So even if you just Google for things, you'll find things up up
on YouTube or there's a lot more websites that are now producing
content in terms of books and things like that is endless
books that you can list out. Actually.
I just publish a blog post called book recommendations by
engineering leaders, which I think Henry like to later and
that links off to like tons of books where people can find out
more about technical leadership or management type of topics.
Thanks for sharing that do subscribe, everyone to The level
up newsletter. I'm one of them every week.
We will get a lot of articles that pep found interesting.
I don't know how you curate all this.
It seems like a lot of time reading Twitter's reading the
internet, medium blocks, or whatever blocks that you can
find. So it seems like a lot of
curation being done very thoughtful as well.
I'm sure that if you subscribe you will learn a lot from the
newsletter as well. So Pat, thank you so much for
your time as usual Norman this technology, you know episode I
would like to ask the guests to share their three technical
leadership. Would you be able to share your
technical leadership system? Yeah, absolutely.
I think tip one is if you are going on this journey or
thinking about going this journey, you have to make that
shift from maker to multiplier. It's not easy and you'll fall
into habits, making that mindset, shift is a key to being
effective. Sometimes you'll move between
them because they're technically, you're probably
gonna be writing some code at some point.
So you'll still be creating, but the value that you produce is
really much in that multiplier side.
So, focus on that. Second tip is.
I talked about what Got you here, won't get you there.
The skills that made you successful, as a maker aren't
necessarily the skills that will prepare you for being a leader.
So if you're thinking about this, you're actually in a great
place because you're not yet, accountable for it.
They can practice developing these skills, learn more about
these and then find out ways to practice this safely before you
suddenly find yourself having to use these skills, understand the
leadership skills, understand broader system and architecture
skills things that are bigger than maybe, what you might
encounter in your wardrobe. If you're working as an
engineer. Step 2 tip 3 would be to find
people that have done this role before that you're interested
in. I think talking to people
reading about people's stories is really great way of learning
from each other when things that I really appreciate.
And you touch upon this because I've been doing this for 10
years, is that you never really done.
There's no perfect single way of doing something.
You can always learn something from somebody else.
Some interesting Insight, some interesting anecdote.
And if you start to talk to people, you'll start to build
your toolkit is how I often describe it.
It's like the bottomless bag, you can keep adding more things
your toolkit because it never gets full.
You can always learn something about how other people do it.
It doesn't mean it's right or wrong, but it's something that
gives you more breaths to draw upon when you're in a different
situation and it can give you a different Insight.
So they would be my three tips. Thank you for sharing that.
I'm sure your level up in your selected, as one of those
toolkit. You can find.
It keeps growing and growing every week.
So thank you, Pat Kwa for your time.
I learned a lot myself and I am sure all the audience here will
learn a lot from your experience and your knowledge as well.
And for those of you who are interested.
Sign up with petrol on Tech lead Academy and Tech lead workshops
are provide the links later on. Thank you Pat.
Why and hope to see you again in future episode.
Thanks very much for having me. It was being a pleasure.
Thank you. Thank you for listening to this
episode. If you highly enjoy it, please
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 really helps me a lot. Stay tuned for the next
technique Journal episode. Code, and until then, goodbye.