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.