#43 Pat Kua on being a consultant, a tech lead, a CTO and helping people grow
Transcript
⚠ The following transcript was automatically generated.
❤ Help us out, Submit
a pull-request to correct potential mistakes
Tim Bourguignon 0:15
Becoming a software developer is a never ending journey. Some developers started coding when they were kids. Some ended up studying computer science and others came from very different backgrounds. Some taught themselves programming. Others went through apprenticeship programs, a few even jumped in yet boot camps. One thing is sure, no journey is void of bumps, forks, and hard decisions. Every journey is unique and full of learning that are worth telling. So let's ask developers from all around the world, how big they are today. And how will they grow?
Whether you are a junior Dev, starting your career and learning the ropes, or maybe a senior developer, pushing and guiding others around you, we have something for you. Welcome to the software developer's journey book.
Hello, and welcome to developer's journey, the podcast shining a light on developers lives from all over the world. My name is Tim Bourguignon, and today I received Patrick Patrick is the CTO of the mobile bank in 2016, where he is building the engineering group that will change modern retail banking for people like you and me. Formerly a principal technical consultant at thoughtworks in London, he's also the author of three books. I think it's for right now, isn't it? That's a few participation. Oh, okay. Okay. First one is a retrospective handbook. The second one is talking with tech leads, and most recently, building evolutionary architectures. Patrick is a frequent conference speaker, he's a blogger, he is passionate about bringing a balance, focus between people, organization and technology. And I hope we'll talk about this today. Pat, welcome to the journey.
Patrick Kua 2:32
Hi, Tim, thank you very much for having me. It's great to be on the podcast.
Tim Bourguignon 2:36
It's our pleasure to to have you. So let's start with it. Tell us about about the forks and bumps your story, what led you to to finally work for thoughtworks in London, and then grow into many, many roles there? And finally leave it and and become the CEO of 26. In Berlin?
Patrick Kua 2:57
Yeah, it's a really great question. So I guess, I have been in technology for quite some time, it's almost 20 years. So the story is quite long, I'll try to keep it quite short. I sort of fell into technology when I was in sort of high school. And it was interesting, because I was really looking at trying to do something between business and technology. It's actually what I ended up studying at university, and then ended up deciding Actually, I definitely prefer writing programs than say, accounting or finance. And that was the direction that I wanted to go into, because I realized that that sort of build a mentality what you could create from code. And the impact you could have was really, really exciting for me. I actually started work in Brisbane in Australia. And it was quite interesting, because I was graduating at the time of the sort of.com. Boom, and also bust. And that was very interesting, because in Australia, people have sort of graduate recruiting programs. And you normally know, sort of february of the year, when you graduate at the end of the end sort of November, you know that you have a jump of some sort. And this was the 2000 and I actually ended up getting a job with Capgemini Ernst and Young consulting at the time. And in my last semester, I actually went abroad because I felt you know, I had a job. Everything was good. September, September 2001, actually, it was happened and you know, Twin Towers and the sort of whole.com boom kind of exploded, and this is where it went to bust. It was very interesting because I was overseas at the time on campus, in a different university, different city where this is all going on. And the graduate recruiter, tried to get in touch with me and said, Oh, we need to have a chat. And I ended up losing the job because they ended up deciding to close the office. So you know, jobless, and then Fortunately, I went back to Australia and managed to find a job. And then was temporarily at flight Centre for a bit and then ended up at a job article. And that was really interesting, actually, because I guess Oracle is a big name. And I fell into an r&d pub article, which was in Australia, and they were actually experimenting with early versions of extreme programming. So we use the first version, continuous integration server cruise control, we use the first version j unit 1.0. I don't even remember what Java version one dot one eight, I think, probably back then. And, you know, I could actually see some of the problems that they were trying to solve with it, right. So big teams, lots of frustration of trying to get something working in an environment, you had a Build Team assembling the software, I spent a lot of time on phone calls or documentation. And a lot of those pieces of the puzzle came together. And I was like, well, this XP thing, the whiteboard totally makes sense. And I want to work in a place where we can do this. So I ended up actually fighting thoughtworks because obviously, Martin Fowler is one of the Agile Manifesto signatories, and decided I wanted to go somewhere where we could really embrace XP. And the first client I started working for in Brisbane was actually a sort of.com kind of startup that was very successful. We were releasing back then, every two weeks, which was a big achievement. And, you know, doing pair programming, unit testing, automated testing types, and you know, sort of went on that journey. I really enjoyed my time as a consultant at thoughtworks. I think one of the interesting things that happened along that journey of where I was there for 14 years, was really helping companies get better at building software. And I think over the period of time, when I first started it, I think a lot of companies viewed software as a cost center, right? So it's like the thing that you would maybe buy once you would install, you would then maybe think about upgrading the following year. And then maybe you commissioned a project to get another company into sort of do that. And I think, looking back at significant changes in the industry, I think there were a few things that changed over time that have really made a big difference to how we build software today and the role that software plays. So I think things that I talk about often are things like the open source movement. So when I first started, I think a lot of companies were still building their libraries, open sources, seems very skeptical edge kind of community to really understand that.
If anyone remembers SourceForge, it was starting to come about but more for tools rather than some libraries. And you know, I think that's really changed today. I think another thing that really changed over time was agile is sort of mainstream, right? So I think it's very common that everyone talks about Scrum. But I still remember when we first started, the show was seen as the dirty word, right? It's the it's the hacker group. It's the people with no discipline, which is completely opposite. It's people who added risk. It's like, what's the complete opposite of actually helps you manage risk, helps you surface that risk earlier, helps you understand what they are, helps you learn. And, you know, I think it's really changed today. And I think that's also changed how companies work. Obviously, Internet's everywhere. And even more accessible with things like smart devices and 4g networks. And, you know, the accessibility of that. And I think that's really changed the way that we build applications. So you know, we've moved off from desktops. Well, I mean, we still have desktop servers and desktop applications. But we mostly use predominantly web applications, or mobile devices, which rely on connectivity for, you know, giving us functionality. And along the way, also, cloud computing is another thing that really came out because of the internet and connectivity, and sort of the reduction in cost of sort of service. So for me, it's been really fascinating because the role of software has become more and more important, as it became became sort of the heart of a lot of businesses. And I really enjoyed helping companies work out ways to, you know, build software, in better ways deliver value with software, not just building software, but also delivering valuable software that has impact. And, you know, for companies that have been around for 20 years where, you know, the mindset was software as a call center, they need a lot of help of going through a cultural shift of then moving to, you know, understanding that they have to change the way that they work to really make a difference, to deliver software in her effective way. And I really enjoyed that working as a consultant across different industries. And actually, it's one of the reasons I ended up in 26, where, when I first started, it was a very small team. And I recognized it was a really good engineering core. And one of the things that I feel I work really well Weller is helping companies work out how to sort of change some structures in their system to scale up or to leverage the sort of systems at play. And so I sort of came in, it's been like a year and a half, we're now about four times the size in terms of technology team. And we're still delivering amazing product. And I think this is like, you kind of control a lot of people at something, and you can get a lot of chaos. But if you do it, well, you can actually help create a lot more stability, sustainability, and sort of scale up effectively. And so that was some of the reasons I came in was, we're a hyper growth company, there's a lot of really interesting opportunities, as we grew, both in terms of delivering really great products that I use as love, but also, you know, had a lot of satisfaction of sort of shaping the ways of working the organizational structure, so that people could be as effective as they could be. You know, I think there's a very different culture that comes in tech that I've learned that isn't necessarily shared in other domains, like business or business development. So, you know, there's still definitely a thinking in other parts of the industry. And you know, even in legacy IT companies where they see it as sort of resources, or release, we'll talk about people with resources. But my philosophy of sort of leading and managing organization is you hire a bunch of really smart people who learn, right? They have the best context of the problems, because they're closest to the information. me telling people exactly what the right solution is, doesn't scale. And it'll often be the wrong solution, because I don't have the context. And what's really important is that you create the right structure to give people the things or the information they need the support that they need to make good decisions, to ask the right questions that people may not have remembered to ask. But, you know, at the end of the day, people who are willing to learn and have the right mindset will often make better solutions. And so that's the thing that I've really enjoyed being able to do in my current role.
Tim Bourguignon 12:08
How did your, um, your past as a consultant prepare you for that?
Patrick Kua 12:14
It's a really great question. I think one of the interesting things you learn about consulting, is the ability to build relationships really quickly, to sort of contextualize or to seek understanding, and also then to influence. So I'll talk about each of these different things first. So obviously, when I came in, you know, there's an existing structure. And I think one of the things that you don't want to do as a consultant is sort of say, here's exactly how you should do things. So I think one of the worst consultants, like, here's a recipe we've prepared earlier, just follow this recipe, and you'll be perfect. You know, every organization evolves to the way that they are because of things that happened in the past. And they're successful as a result in different ways. There's also maybe cultural hangups or habits that have been established because of those things. But in order to help them understand how to get to the next sort of stage of evolution, you kind of have to understand what led up to where they are now, right. So sometimes those things were there, for good reasons. It's everyone's always trying to do the right thing. It's just maybe there are forces at play that you don't understand. And so this is where, you know, why I practice as a consultant was really going into an organization and sort of spending time with people and just trying to hear their story out, right? Because I think this is one of those things that I've read about management is, it's like, the things that consultants do is often tell people the time right on your watch, and part of that's kind of true, because management's often not really listening to what's happening on the ground to the people. And there's a value in actually, you know, giving a safe space for people to express their concerns in a way that creates an anonymity for them. And then there's also then waiters, sort of bringing that in conceptualizing that for management and then saying, based on these things, who would be the next concrete steps that would actually have the most sort of impact from that perspective. So I think definitely the building relationships is really key, listening to people and understanding the context. And then the third part is sort of the influencing and I think this is one of the things that I really try to teach when I'm trying to grow other leaders is that you can use authority as a mechanism for influence. I've experienced experience that doesn't really work very effectively in technology. So the reason I think this doesn't work so well is there's the whole shift of things that moved away from that taylorism right where that was very about the mechanical manufacturing industry. Have we split toss up, you don't have very highly educated sort of learning people. They just focus on tasks software, by its nature, requires creative problem solvers who are constantly learning and applying that same philosophy doesn't really work there. And I think this is where, you know, you have to engage with with the people as well. And so this is where you don't want to rely on the authority. And this is where you have to sort of influence people by maybe getting people to see different perspectives that they didn't see before. So using questions rather than sort of assertions, you know, understanding and bridging is an influencing technique of once again, trying to understand where people are, and help them understand what a new world could look like, so that they prepared for change. And I would say that those kind of three skills around so the building, the relationships, the conceptualizing, and influencing are three kind of key areas consulting really helped me prepare for my role, right, what I do?
Tim Bourguignon 15:47
Mm hmm. Fantastic, fantastic. You just say that, um, that you teach and grow older leaders? Do you have I want to ask for a recipe, but how do you do that?
Patrick Kua 15:59
It's, it's a great question. So I think so one of my personal passions, and it's actually one of the books that I published as a sort of talking with tech leads. And part of this was born out of my own personal experience as well is, and maybe I'll take a side story here is that I was on a project once where I was an engineer. And I was actually I went away for a weekend or a holiday, and I was at the airport coming back. And surfing, which was the function and thoughts that allocated to different projects, gave me a call at the airport, as I was like, on my way home, and they're like, Patrick, you know, we're really happy that you've been working on this project, what we really need to do is start with this customer, and lead a team. And I was like, Oh, this is exciting. This is like completely different new opportunity. At the same time, I was like, What do I do differently? Like, there's this kind of panic thing, right? It's like, I now have this kind of role title that I need to fulfill. But what is it that I need to do differently? And, you know, one of the things I felt is that a lot of people don't prepare you for that role. And that's one of the things that I really wanted to do, through helping grow people and sort of the book that I published was really about exploring people's coping mechanisms or experiences as I went through something similar. Because when you're in that sort of role, you feel like you're learn, but actually, you start to talk to other people, and they all feel exactly the same. So it's kind of some, at least you're not feeling completely alone, if you know that other people are in the same situation. To go back to your question, though, about how to grow and lead people, I think there's a couple of different things I tried to do. So I think when people think about their career development, right, a lot of people think up is always better. And I don't think that's always true. I think it's really a question about what do you want to do? And how do you want to have impact. And I think one of the interesting things about leading teams or leading people is a it's a different skill set than what you focus on as an engineer. And it's often one of those things where I say, for people in technology, as developers, or engineers, it's one of the hardest shifts to move into a leadership role, say, compared to other groups like business, developmental marketing, or communications, because there's a very low percentage overlap the skills that you develop as an engineer, that prepare you the support you need for leading. And so what I like to do is at least help people understand what are the types of things you're going to end up doing? What are the responsibilities? What are the struggles? What are the challenges you're going to have? Because, you know, I think some people step into that role, they kind of get really surprised by, it's not at all what they were expecting, and then they don't know what they want to do. And it's okay to say, actually, you know, I've tried this leading thing, and I don't want to do it anymore, I just want to go back to being an individual contributor and writing, you know, amazing production code. And so I like to help grow people by trying to help them understand what does it actually mean, right? Is this something that you really want to do? There are other people who are kind of naturally sort of maybe leading by, I guess, nature, or like, they sort of gravitating towards that direction anyway. And, you know, what I try to help them do is then give them specific tools that will help them solve certain problems, right. So I do a lot of mentoring, one to one sort, of course, sessions with some of the people here and 26, and people in the past, and we try to talk about specific problems around, you know, how are you coping with maybe two people on your team that are having a conflict? How, what are you struggling with the most normally it's things like time management, context, switching, interruptions, and then we talked through what it's I tried, what other ideas might they have. And I tried to sort of help them sort of self discover some of the tools. Of course, I also then tried to connect them to other resources, books reading. But I really try to help support people with the problems that they have. One of the other things that I do is I actually run more ad hoc tech lead courses as well. So it's something that we run internally in 26. And it's something that I've run for other companies, every so often. And it really covers a lot of these kind of basics. So, you know, what is the expectation of things like a tech lead? What are the responsibilities, and then for each of these different areas, some technical, some more people kind of skills, then we cover different types of tools and expectations that hopefully help people prepare for that.
Tim Bourguignon 20:53
Interesting, could you give a very short definition of the tech leader or the what you think the definition is? Who should be?
Patrick Kua 21:01
Yeah, it's a really great question. Because, as everyone knows, in software naming is one of the hardest things and I've discovered, through a lot of research that there isn't really a consistent understood definition of what a tech lead is across companies. So what I describe as my definition of a tech lead, take it with a grain of salt, it may be different in your organization's. But my definition of a tech lead is a developer. So somebody who is technical, who is leading a group of developers towards a common goal, and also also responsible for the quality of that solution. So what this means in general, is normally you have a team of engineers working on the same system. And that system should be evolving in a consistent fashion, long term. And so the person who's who's sort of shepherding people to work towards that technical vision, other people who I call the sort of tech lead, the reason I also talk about the quality of the solution is that it's very easy to sort of focus too much on features. It's often another thing that product managers or owners will sort of focus on, or users. But one of the things that I think does need to be taken into account, when you build a solution, it's really about the right level of quality. And these are a lot of the sort of internal quality, these are about the architecture types of qualities, when these are things that the technical team should be responsible for. And it's kind of understandable, it depends on your product owner, or your users about how well informed they are about how software is built. But somebody needs to be looking at to see if the system is secure, to see if a system scales to see if it's important to be reliable, depending on the type of nature. And so somebody needs to be sort of gatekeeping or sort of shepherding that those qualities are also built into the system. Because there's value in that as well. Right. So and so this is the part of the tech lead role. I also envisages that somebody needs to make sure that those things are accounted for planned and then built into the system, as people evolve that system over time.
Tim Bourguignon 23:19
Do you see your role as a CTO as being a tech lead as well?
Patrick Kua 23:24
So
it's a good question. And I'll caveat a little bit because I think the first thing is that it's very, it's also even more nebulous than a tech lead role. So I talk a lot about the CTO role is like a chameleon role. Like it's the most adapting nebulous, misunderstood role in our industry, or maybe one of them, maybe not most, but one of the big ones. You know, so I often explain if you're in a startup with like five people, you as a CTA, probably a developer, right. That's where you spend most your time, as you maybe grow the company to like 10 or 30. People, you're probably then leading the development team for the direction. But you know, as you make a step, jump into, you know, 50 person organization, you can't make all the decisions, you can't lead like a 30 person engineering team, and your role changes again. And then there are also different types of industries about the role that technology plays about how important technology is to the business. So, you know, worked in organizations where the CTO role is a lot more about business strategy about more mergers and acquisitions about business capabilities. And that's a completely different skill set. You know, in other places, and particularly if the company goes through like an IPR. You know, what most people they're trying to do, trying to focus on reducing operational costs, because that's something that worries like the market and so you'll have Somebody who's a lot more, I'd say, number crunching, sort of looking at numbers to sort of reduce operational cost. And that's a different skill set again, for the CTA role. And so, yeah, the role I described is very misunderstood chameleon. It's also not clear about what companies need. Where I was at the very beginning of my journey here is what I describe as a sort of scale up seat here. So in this case, I'm not necessarily eating technology direction, there are principles that I try to ship it. But for me, it was really about scaling up the organizational structure, to allow us to add in more people to sustainably grow at a good rate. So, you know, the analogy that I kind of describe a lot is you can, you know, if you're in a room of, say, 50, people, you know, everyone can kind of talk and get along, and it kind of makes sense. But then if you then threw 100 150, more people in you legit end up with chaos, right? It's not clear who should be doing what, where people should focus on, you hope that there's something there. And this is sort of what I kind of talked about in my sort of scaleup. CTA role is really about that sort of setting enough guidelines and boundaries to give people focus. So, you know, one of the things that I was doing here, for instance, was really trying to establish teams with a strong ownership over an area of domain, you know, trying to have more stable teams, because they're really fluctuating. And so when you have that sort of strong identity of a team, it's kind of like the sort of company within a company kind of mentality, of people have identity, they have a clear focus, they have kind of a personal sort of mission, and then they can really deliver. And that becomes a lot more sustainable. If it's clear also about what other people are focused on, then it's also clear about who do you talk to when you need to talk about something like a dependency or when you rely on something. And so those were kind of more about the structural things that I was doing with the organization. And once again, it's evolving as we grow as a company, and it'll evolve again. And so you know, I think the the thing that I felt is that the engineering team was really great at a technology level. So I didn't really need to be going poking into much about like what we were doing, we had really good practices already, you know, continuous delivery pipeline, sloto, like testing automation, security, automation. So there's lots of really good things where I didn't really need to influence that. Now, if those were missing, then I would probably step in, but they were very much aligned with what I would expect from the sort of technology organization. So in my role, it's really been about satisfying kind of a need of what the organization needs to help us grow. And in this case, it's been less about a tech lead type CTO, and it's been more about a scalar type CTO.
Tim Bourguignon 27:58
Very interesting. Thank you. And if I have a kind of meta question that I want to ask is, you've been evolving into into many, many roles throughout your careers. And how do you personally grow? What What is your, your, your learning pattern? Or how do you get help? what's what's your story in there? How did you do that?
Patrick Kua 28:23
Yeah, it's a great question again, because I probably don't have anything clearly to find. I think there's a few building blocks that like, I would probably also give us advice to other people that I think have worked for me. So I think one of the things that I discovered early on, and I can't remember who it was through, I worked with Dan north, for instance, and he talks about this quite a lot. But also Liz Kia, and a lot of people who were as part of the stream Tuesday, community group said, say STC London, is what it's called. And one of the things that I picked up somewhere along the way, was like this thing about learning models. And so I think the thing that you practice as an engineer is, obviously you write code or tests and you build systems. But the thing that is constant in our industry is real change, like rapid change. And I think the thing that is, you know, that you kind of practice at a meta level is actually learning how to learn, right? So, you know, it's the same sort of thing is that, you know, if I end up with a new tool, the first thing I'll do is like, I'll Google about how to use this tool. Well, like, what how do you do it this way? How do you explore this tool? How do you understand what it does what it doesn't do? Before sort of saying, Oh, this tool doesn't do anything. And I kind of contrast that to a couple other people. So I won't say who but like I was talking to someone recently, and they came from a world of using a different type of email client. And I'm a big fan of this of Gmail. Because of like, you know, keyboard shortcuts and all this sort of stuff, and they're like, oh, but I was really productive and this other type of client, I was like, Well, have you looked at how those things happen in this util? Like No, I say, Okay, well, I can walk you through that. But like, you know, that thing over there? What are you missing? Okay, this Well, that's this concept in this tool. And what about this thing? Well, that's this concept in this tool, and, you know, and, and then they're like, what else is there? And then, you know, well, there's other features that maybe you don't know about. And I think this is the interesting thing that I've learned with software is, it's like, learning how to quickly discover information, learning how to put that into practice, learning how to use that, so you can be more effective, productive, and know where your gaps are. And I think that's a really cool skill to develop, because I think it's one of the reasons why a lot of engineers come into software is that you solve problems that you haven't solved before, and you learn something in that process. And for me, it was interesting, because one of the benefits that thoughtworks gives you when you work for them after 10 years is a three month paid sabbatical. 12 weeks paid sabbatical, I ended up taking a whole year off. And I kind of put this learning principles into practice. So I think I think at that time, and probably played around, learn about five or six different programming languages, so done Perl and Java, and dotnet, and Ruby, JavaScript and a whole bunch of other things. And, you know, I was like, let's learn a real language, like, I live in Europe, I don't speak another language. So like, this is a really good opportunity to do that. And I ended up taking 2014 off, move to Berlin for a year, and then I just focus on learning German, and try to put all those things into practice, right. So put yourself into uncomfortable situations like to Carter's or exercises, like, force yourself to push yourself a little bit further and further each time, and then develop those habits. And, you know, I think, I think my German way back then was much, much better than it is now, for different reasons. But, you know, I got to a point where it was like, fluent, and I could converse with people, I started reading books in German, you know, like, it was, it was, I was very happy with the level. And, yeah, and for me, it's like a good example of that meta lesson of learning how to learn. And that would be something that I think has really helped me evolve with different roles that I would also impart as advice.
Tim Bourguignon 32:31
And how would you, would you advise somebody to, to to do this, just jump in the in the cold water as the German saying and do it? Or is there another trigger?
Patrick Kua 32:43
Yes, yeah. So there's a couple of
Patrick Kua 32:47
models,
Patrick Kua 32:49
descriptions of how to learn. And I think it's definitely worth exploring a couple of them. So there's one that Alistair Coburn talks about a lot. And this is Xu Hari. So I think it comes from Aikido or something from a martial art of some sort. But like, there's three levels shoe than ha, and then re, and it's interesting, because shoe is kind of this thing about, just follow the rules, like obey, right. And this is exactly, I haven't done any martial arts. But this is exactly kind of what you do. It's like, when you're learning something, it's like you follow that you talk, like you play by the rules, and then you understand about, okay, you start to learn the patterns that come along with these rules. And then the second level of srihari is the HA, which is sort of the degress, right, which is the whole, okay, like now you know the basics, and you understand how they fit together, you start to understand where they break, right? And this is where it's the Okay, if I do this, at this point, it feels wrong. And I think I want to try something different. Right. So this is where it's the Chris. And then the last level, which is like a re and srihari is the leaf will separate. And at this point, it's like where the youth you can't describe the rules anymore, right? So like, I learned all the German grammar rules, but like, I don't really think about them now. And you just do what comes naturally. And sometimes you mix things up, because it's things that you haven't really explored before and you just try stuff out. And you know, this is often where the innovation types comes from. So I think concretely, for advice. It's like when you're learning something, it's like don't try to set an overzealous goal. That's like something really ambitious start with basics like, like, do the tutorials. So like, for instance, we have got an attorney recently about adopting kotlin. And this is something that I wanted to learn because I haven't played around with it. So what did I do? I sat down and did all the kotlin Cohen's right so I downloaded the Colin's file and then just play played around. With exercises, and it's really great because it's like, you know, okay, here's how this collections work, here's how decision kind of things work, here's how you use higher order functions or different types of libraries. And before I try to do anything really complex with it, then you just have to learn the basics. And I think that's the first step, right? So for every new skill, you have to realize that if you don't know this stuff, then you have to accept that you don't, and then start with those just following the rules. And then as you get more confidence practice, and you stop thinking about which rule and how to do this, then you can actually start thinking about the experimenting and then saying, what happens if I do it differently over here. And, you know, I think that's a good level for most people to get to, a lot of people don't really get to the real level, which is really about the mastery type stuff. And this is where it's like, we're just coming really fluidly with things. And you know, you don't need to get there for every level. So I think concretely, it's like, when you're learning something new, like, look for those tutorials, build up that practice fine, like do the deliberate practice of just going through the motions and sort of making those rules become part of your own sort of person without you having to think about it, and then start to think about more advanced stuff after that. And then that stuff will be a lot easier.
Tim Bourguignon 36:18
Fantastic. That's great advice. That's great advice. If you could travel back in time and give yourself one advice other than these srihari. What would that be? Oh,
Patrick Kua 36:30
if I could travel back in time and give myself advice, what would that be?
I think one thing, I mean, everyone is a little bit different. But I think one thing that I have found, and particularly useful in my current role, is really having a support network. And maybe this is about a leadership thing. But like, you know, it depends on who you have in your friend network or your colleague network. But it's something I didn't really develop, where I didn't really explicitly focusing on developing very early on. And I think maybe it's because it was just like, naturally, but like, it's not something I really explicitly focused on, I think I would say if I should be build your own support network, because when you have issues to deal with, it's helpful to have somebody who listens to that, that isn't your partner, that isn't a close friend, who can give you sort of neutral advice. So it kind of depends, because like, it's helpful for them to understand like the industry that you're in or the situation, they can't be too close to the problem, and you can't have too much of a personal relationship with them. And I think this is where like having a professional support network to hash out ideas is really useful. In a way, it's kind of actually like, how pair programming works really well in a good dynamic, right. So it's kind of like, you want to talk about this problem. And then you have somebody you can just sort of problem solve with and you come up with different ideas together. And I think that would be a piece of advice I would give to people, which is like, you know, if you're looking at switching careers, or going into new fields, like, bounce that off the support network, and build up that support network, so you have more people to talk through. If you're having a difficult conversation with your manager or somebody on your team, use that support network to problem solve, and, and develop through that. If anything, hopefully you discover new things, or that everyone is struggling with the same problems, which is also just as helpful. But I think that would be advice I would give to my for myself.
Tim Bourguignon 38:40
Fantastic. Fantastic. We're slowly reaching the end of the time box, unfortunately, that's Time Is Flying by, um, what do you have on your plate in next month's weeks? What's important to you right now?
Patrick Kua 38:54
what's important for me is about how I scale up myself. So I think the thing that I was asked myself all the time is, how do I focus on what I need to do next, that brings the company forward. And that plays to my strengths. And that allows me to focus. So as I said, the role keeps changing and growing. And, you know, the thing that I have been trying to do is build the team to sort of focus on different areas. And I think that's the that's my next challenge, which is how to scale and grow and change myself.
Tim Bourguignon 39:29
Given the next book on you're already in the pipeline.
Patrick Kua 39:33
It's a good question. I have lots of ideas for books, but I don't have the time at the moment to necessarily write anything that I say no, yet.
Tim Bourguignon 39:42
I understand that. Well, thank you very much. This has been a thrill to you to hear a story.
Patrick Kua 39:50
Thank you as well. It's been a great pleasure talking to you.
Tim Bourguignon 39:54
And this has been a new episode of developer's journey, and we'll see each other in two weeks. Bye bye.
Dear listeners, if you haven't subscribed yet, you can find this podcast in iTunes, Google music, Stitcher, Spotify, and much more, head over to www dot journey dot info to read the show notes, find all the links mentioned during the episode. And of course links to the podcast on all these platforms. Don't miss the next developer's journey story by subscribing to the podcast with the app of your choice right now. And if you like what we do, please rate the podcast, write a comment on those platforms, and promote the podcast and social media. This really helps fellow developers discover the podcast and those fantastic journeys. Thank you