Today I had the pleasure of interviewing Patrick Akil. Patrick is a software engineer, consultant, and host of the @Beyond Coding Podacst. In this episode we learn about Patrick’s unique view on taking risks early in your career, we also learn some best practices for having difficult communication with your bosses and peers, and finally we learn about the very opportunistic way he was able to become the host of the beyond coding podcast. I loved this conversation and if you want to hear more of us talk, I was on his show a few weeks ago and that episode is linked in the description. Now on to our talk.
Connect with Patrick here: https://www.linkedin.com/in/patrick-akil/
Today I had the pleasure of interviewing Patrick Akil. Patrick is a software engineer, consultant, and host of the @Beyond Coding Podacst. In this episode we learn about Patrick’s unique view on taking risks early in your career, we also learn some best practices for having difficult communication with your bosses and peers, and finally we learn about the very opportunistic way he was able to become the host of the beyond coding podcast. I loved this conversation and if you want to hear more of us talk, I was on his show a few weeks ago and that episode is linked in the description. Now on to our talk.
Connect with Patrick here: https://www.linkedin.com/in/patrick-akil/
Even if you're a senior and you make a mistake, right? The worst thing you can do, worst thing is try and cover it up and make sure that no one sees what happened and people will find out, right? And it will look bad on you. Owning up to it allows the people that look up to you to see, Oh, this is a safe environment, right? And I'm not the only one that makes mistakes. It happens to other people. Other people I look up to as well. And it creates that safe space and allows people to right, learn from their mistakes. I. The best thing you can do when a mistake happens is share what you've learned or share in any way how you recovered from it, so other people also learn from that, right? I think if you have a culture where it's safe to make mistakes and you share when it happens, it'll be a great culture to work in as well. This episode of Ken's Nearest Neighbors is powered by Z by HP. HP's high compute, workstation-grade line of products and solutions. Today, I had the pleasure of interviewing Patrick Akil. Patrick is a software engineer, consultant, and host of the Beyond Coding Podcast. In this episode, we learn about Patrick's unique view on taking risks early in your career. We also learned some of the best practices for having difficult communication with your bosses and peers. And finally, we learned about the very opportunistic way he was able to become the host of the Beyond Coding Podcast. I loved this conversation, and if you wanna hear more of us talk, I was just on his show a few weeks ago, and the episode is linked in the description below now onto our talk. So Patrick, thank you so much for coming on the Kens Nearest Neighbors podcast. Obviously you host the Beyond Coding Podcast and before you say anything, People understand why, because you have probably one of the best podcasting voices I've heard in. You think so? Oh yeah. Absolutely. Are you kidding? Thank you, man. I appreciate that. But you know, obviously, you work as a software engineer in your, in your, in your day job, and you have a pretty interesting story breaking into the field. Also, we've talked quite a lot on personal philosophy and personal growth, and I'm really excited to one, hear your thoughts on that area of your life as well as explore some of them with, with the broader community here. So again, thank you for coming on the show. Excited to be here again. Thank you for having me. Amazing. Well, so one of the first things that I like to do to get. All the listeners familiar with the guest is to hear just a little bit of a story from you about where you first got interested in coding. So in coding, was there pivotal coding or software engineering or sort of the technical domain? I think there's usually two routes. Was it one where there was this pivotal moment where you realized that this was really interesting to you? Or maybe was it more of a slow progression over time. It was, it was kind of slow. So as a, as a kid, I was really big into video gaming, right? I come from a pretty strict background, and when you're quiet and you do what you're told, that's good. You have a good kid, an decent kid. Well, that's usually what people said to my parents when I was just in a corner playing video games. So video games were a big part of my life. Because of that, I always wanted to be a game designer, a game developer. I wanted to create the video games that I was playing high school. In the Dutch educational system, you have distinct courses that you select. And the courses I had selected unknowingly, I don't know exactly. But I couldn't pursue that anymore. So then I was like, Okay, what is after high school? What is gonna be my path to that? Or, and I have to realize if I actually want that, because coming outta high school, I had no clue what I wanted to do. For me, an adult job was, Okay, I'm gonna select that, and that's gonna be that for the last, the next 30, 40 years. And that's gonna be that I have to be happy about my decision. I didn't think about the progress or how, how I could evolve that. So I chose a university bachelor's degree based on how broad it was. I did information studies and throughout that you learned partially computer science. And on the other side a lot of business studies as well. So we did a lot with startups, a lot with business theory, how to structure your organization, hierarchy plus sides and downsides with regards to that, as well as some software engineering fundamental. Mostly Python and data science related topics. But for example, I had a four week course where the assignment was, alright, you have these choices of creating a website, a forum I forget the other one. So I just remember forum cause that's what we actually chose. But then you had to teach yourself in a group setting how to get that done. And it was with HTML, CSS, and PHP. Now, I really enjoyed that. To me, creating logic on my computer and then making something work. The visual output, whether it's CSS or the logic that's in there, whether it's php, I really enjoyed solving puzzles in that way, cuz that's what it was initially. Solving problems, solving puzzles, getting stuff done with these tools that were handed to me. Right. And then it was initially the website and when it was data science, it was more Python related things, doing a data analysis. On the data sheet that we got, but I never knew if I actually wanted to pursue that. So when I had my bachelor's degree, I still exactly what the same question was. Like, what am I doing now? Cause that choice, that huge life choice that I thought I had to make, I still had to make that. So then as a first step, I in interviewed for a lot of positions, even though some of the positions were not what I thought I was gonna. I thought, I'm really young. I was 21 when I graduated. I'm just gonna do all of it. I'm gonna interview and I'm gonna learn through that. So then I actually landed quite a few jobs. I picked one of them, which I thought would be the broadest, which would give me an introduction to the field of it. I joined as a technical junior technical operations manager, which basically means, alright, we have these landscape of applications and me and my team are responsible. There are various applications. I think I got a sheet with like 80 applications, and so some are more crucial than others, but that's how we started. And then I was like, Okay, we figure out how one application works and then the next one and oh, this has a database and this is connected through a vm. And I learned throughout doing that, and when there was an issue with an application, I knew kind of throughout my history how I could solve that. I wasn't responsible because that was the job of the software engineers. And then I read online these, these theories about DevOps and that was more of an up and coming term back then. And I was like, yeah, that's me. Cuz I already had the operations part down after a few months, after a year, I thought I wanted that software development experience in there as well. So once I had that realization, I went to my manager, I said, listen, I know we're doing software engineering somewhere. How do I get there? And I don't even care what it is. I just. I just need to plunge in. It doesn't matter what it is. I want to create software as well as maintain it in an operation sense. So that's kind of how I got the ball rolling and they were like, fine. Okay. My manager left, I had a new manager, and in two weeks I said the same thing to him, but he immediately made work of it. Yeah, I really appreciated it for it. I really appreciated him for that. And I joined as an enterprise service bus develop. That's actually not what I did though, cuz I was like, Okay, this is a thing. I don't even know what it means. The guy that was supposed to educate me on what that means was only available twice a week, which is not a lot. And then I joined the e-commerce dev team. Within that I did a lot of operational stuff and then finally I met the people that were responsible of everything, e-commerce, software development related as well as the operations. And I got the ball rolling from there. I started in there. Everyone knew I wasn't novice. My manager told them, all right, you guys are all consultants. You're way too expensive. Patrick's the guy that's gonna take over. Make sure you transfer all the knowledge that you have. There you go. Keep or start with that. Yeah, I think long answer to a simple question, but that's kind of how I got the ball. You know, I'm chuckling because there's a lot of similarities to how I got into data science in your story. So, awesome. I started in management consulting because that was the career that I thought was the, I had no clue what I wanted to do, and I was like, Oh, tons of great exit opportunities here. I eventually was working in essentially software development, life cycle consulting, and I'd never written any code like, and I. Why the hell am I doing this? Like, I'm presenting to CIOs of organizations and like VPs of engineering and I have no clue what I'm doing. I've never, I don't even know what software engineers do, how, how could I possibly give them advice? And I was like, I should probably learn how to code. I should probably like go back and approach this system. This is very interesting to me. And that's when I went back to school. So I, you know, you transitioned within your work, whereas I transition. You know, through, through like a third party through education. But, but to me that's such like, I think at least in the very small sample here, it shows that it's not abnormal that people don't know what they want to do. And I think in some sense, it's actually kind of a good thing to make decisions with that are open-ended, that, that leave the future in mind. I think the entire domain is actually pretty open-ended. You know, if you go into software engineering, you can pivot to something else. You, if you go to data science, you can pivot to something else. If you really hate it, like the skills that you develop are quite marketable, which is a very, oops. A very, very powerful thing. You know, you, I think, actually have a very unique knack for moving and finding positions within the organizations that you're at. and making them your own I'd love to hear more about that. So perhaps your experience moving from your first role into your second role, and then also carving out the very unique podcasting experience that you, that you've created at your current company. Yeah, so when I, when I started out in operations, because I didn't know what I was gonna do and because I felt like, Okay, I'm 20. The youngest here, probably one of the youngest hires there. I'm kind of a wild cart, right? I can do a lot of things and make mistakes, and if they kick me out because of those, I'm gonna find another job. Right? I'll, I'll get back on my feet. Not to say that I'm gonna be careless or I'm gonna make intentional mistakes, no, I'm gonna try my best, try my hardest. If people say, Oh, this is not how we do things, or This is not why it doesn't work, like, I'll be like, why? Why can't it work like that? Because in my mind, it should be simple. It should be doable. One of the first things that happened was, Okay, I joined this company and they had this manual process, which I already didn't like because I didn't foresee myself doing things manually week in, week out, doing the same thing. But sure they had this thing and they said, Okay, well you're not part of our team. You're gonna do this manual thing as well. This is the procedure in there. You go here, do this. You copy this over, blah, blah. And I was like, Okay, how often does it happen? And they were like, doesn't happen that often, like once or twice a week. But yeah, it is an issue because down the line it actually impacts our customers, our our end users. And I was like, Okay. So then I did that. And day one it was fine, right? I went through the procedure, I did the thing. Day two, it was like, Okay, this is still a thing. And it happened three days in a row. And I was like, this is enough. All right. Why? Why is this happening? I really don't, I really don't like manual work. I really don't like doing the same thing over and over again. I don't know where it comes from, but that idea of doing that aboard engineer, I just didn't agree with it. So I asked a bunch of questions. I said, who's, who's even, where's this output coming from? Who's responsible for this output? Like it's the, it's the web team over there. And I was like, did we ever talk to them that we have this thing, that we have this manual? No, we're all kind of new in this team and we don't really know each other. I'm like, I'll just, I'll just go up to them, introduce myself. I'm new here. Anyway. It's good to make introductions. So I did that. I said, well, I am Patrick. I'm new here, yada, yada, yada. This thing we're doing, I don't really like it, but it's based on the output that you have. It impacts customers down the line. I basically described the situation to them and they were like, huh, it's not supposed to work like that. I was like, that's what I. We have a problem here. So they went through the database and they were like, Okay, this is old data. We can fix this within half an hour. We'll just run a query. We'll straighten out the data and it'll be fine. And we did, and we never saw those problems again. For me, that was kind of a kickstart to the whole, how do you say that? It was a cascading effect, but to me it was so simple. Just the conversation solved that problem to. that the work that I was gonna do, I was gonna simplify a lot of things. If things were gonna be complex, I was gonna ask questions to hopefully understand what's going on and hopefully simplify it for others as well. Because I don't think a lot of things are inherently complex. I think a lot of things we make complex. So whenever I picked up a new topic, I asked the questions because honestly, I didn't know I was new. People expected me to ask those question. But what it allowed other people to do is listen in or explain and hone their own skills when it comes to simplifying things, to have a shared understanding as a team of what we're doing. And throughout that, I got more and more comfortable being direct in my communication. If I don't understand something, I'll tell you. If I expect something of you, I'll tell you. I expect you to tell me as well what you expect of me. That's kind of the basis in US collabo. So I've always, well that's kind of how it started, had this direct communication style. So even then, when I was comfortable in what I was doing, I wanted to grow. I really wanted to grow as fast as possible. I don't know where that comes from. I think it kind of is, is parallel to the not wanting to be bored. But my manager at the time, which was my first manager, said, you can always come to me whenever you want something new. Whenever you want something different, I want to be. And I'll help you in every, every sense of the way. So every time I wanted something, every time I felt comfortable or felt like I was trending towards boredom, I went to him. I was like, Okay, this is something I don't have any area of expertise in, whether it's networking, storage, database management. It was really traditional operations. I went to him and I was like, can I do anything in this? Can I double my foot in this so I can figure out if this is what I actually wanna do down the line? Because I thought if I really find that I can dive deep, right? I can make that my profession, I can do that 30, 40 years down the line. So I, throughout that, I did a lot of things. I did database management, I did storage, I did networking. Until I got to the point where I was like, I want software engineering. That is my next step. That is what I wanna dabble into. And luckily my manager at the time had a big reorganization, so I got a different manager. They left. So I got a new manager, but still I really appreciate him for that. He made it happen. He basically said, Okay, I hear you Patrick. We have this position that was the enterprise service bus developer and a position. And when that wasn't working out, when I wasn't really getting to sink my teeth into something, he made sure I got the opportunity to do so with the e-commerce team that we had there, which is really cool because once. I have the inherent drive to wanna try things out. I think it's inherent curiosity as well might be why I started the podcast down the line. But for me, that's always been a driver trying things out, not being afraid of making mistakes. And I got really lucky that it was an environment where I was allowed to make mistakes and learn from those and just grow through that as well. I think it really helps early on in your career if you find the environment, if you find what drives you, curiosity. Yeah, I think it'll, it'll bring you far in that way as well. Then. I absolutely love that you gave yourself not an excuse to make mistakes, but a, an acceptable tolerance for risk in the questions and the decisions that you made. Because the risk is only just perceived on your end. As you mentioned, everyone is expecting you. You know, dumb questions. Everyone's expecting these things from a new person. Just giving yourself the freedom to do those and not try to be perfect and give yourself some wiggle room is something that I think could help anyone on in their first job or even in a, in a new role, is that it's okay to ask these things. It makes everyone else better, but a lot of people are scared to look silly or any of those types of things. Some of the most impressive people that I, that I met, that I've interviewed, that I know they try to ask. Overly simplistic or what they would consider dumb questions because those are the ones that don't get asked enough anymore. Right? We ask these complex questions about all of the systems and the infrastructure that's in place, but we like don't even ask why we're doing something. A lot of it exactly, and to me that is such a refreshing take on starting out a new career is you have more bandwidth, you have more wiggle room to ask these questions. It's sort of built into the position, you know, that's something that, that is expected of you. You should absolutely capitalize on that. You shouldn't go the other direction and be scared to do those things, but it's still, it's still obviously feels wrong to a lot of people to, to, to do those types of things. How, how do you get over that fear early on of asking those questions? Is it just like, not in a bad way, but is this just like selfish desire to, to learn and realize? You know, yes, it might be silly, but everyone's, you know, I'm at least gonna get better because of this. Or is there some other mechanism that that, that makes you more okay with that? This episode is brought to you by Z by HP. HP's high compute, workstation-grade line of products and solutions. Z is specifically made for high performance data science solutions, and I personally use the ZBook Studio and the Z4 Workstation. I really love that Z workstations can come standard with Linux, and they can be configured with the data science software stack. With the software stack, you can get right to work doing data science on day 1 without the overhead of having to completely reconfigure your new machine. Now, back to our show. Yeah. So the reposition came a bit later. I did join the position and I expected myself to make mistakes, but the whole joining the position was to learn from and figure out what I wanted to do. Throughout that, I was, I mean, I think kind of an introvert, especially at the beginning when I don't know people, I kind of isolate. I figure out my things before I say something, but because I said something and something positive came out of that, I had this kind of positive feedback throughout that that that was a really good thing. I got a lot of good feedback from my manager, from my team that we didn't have to do this anymore. So it's like, Okay, so it can be that simple. It doesn't have to be that daunting. And I was lucky that within the team I had a really good mentor as. Which I've had many conversations with him, late office hours, just, just brainstorming, just reflecting, and he really molded that, just openness within the culture in the team as well. So I felt comfortable asking questions. I didn't really feel that there was any danger in me doing so, but that was gradual. So I did it a few times and I got good feedback, or I did it a few times and I made mistakes. But the way other people interact, when you make a. That is make or break because I made, for example, I made a huge mess outta production, and that is in operations. That's like the worst thing you can do, like actually impacting customers. I got a phone call and then my heart started beating real fast and I thought about not picking up because I exactly like I messed up and I know they know I messed up. Otherwise I wouldn't have been getting this call. So yeah, I picked up the phone and they were like, well, we see this happened. What? What happened? I explained exactly what I did. They were like, Okay, well we'll fix it and we'll get back to you in a bit once it's fixed. And I thought, well, this is how you get fired. Yeah, this is this is the thing. And then it was still, we were all back at the office. The guy came up to me, he was on the second floor. I was on the first so I really got to see him and he was like, well, we fixed it in this way. I'll, I'll schedule something. We'll go over how you fix this in the future so you can be aware of it as well. And yeah, that's that. And I was, Hold up. Like what, what do you mean that's that? Like, I just made a huge mistake here. I messed up. Like I seriously messed up. I haven't seen anyone else make a big mess of this. Like it happened and they were like, what do you mean? Like everyone has this, everyone makes mistakes. And he shared his personal story and when he messed up years before and he pointed to someone else and when they messed up and everyone started sharing and I felt such a relief in that it is allowed to make mistakes. And it's how you recover from it and how you learn from it. And we have these procedures that when a mistake happens, we can roll it back up or we have these procedures in place so that the impact is minimal. That's why we have them. It doesn't mean you're shackled and you should be afraid of making mistakes in that way as well. I think that just, it really reinforced this mindset of, Okay, you can be open in your communication. Honesty and transparency is what I really appreciate. So that's what I try and expl. And making mistakes is part of the journey there as well. I think mistakes are so important for the learning process. If I go back and I think about any of the best learnings that I've had, you don't, if the stakes are high, you don't make the same mistake twice and that saves you can save you a tremendous amount of time, money, effort, whatever it is. We were talking before the podcast about how one time I forgot to record. Or start recording the podcast. And I have to say to a guest who, whose, whose time is valuable, essentially, Hey, we have to start, start over because I screwed up. And that's not a mistake that I believe I will make ever again. also because I tell that story to every guest as I do it. So it would feel weird if I didn't. But you know, it's one of those things where it's like, Okay, that happened once. I don't want it to happen again. Obviously wasn't the end of the world. Like worst case maybe. the guests thinks I'm incompetent, but, you know, at the end of the day, that's not like that bad. It's not like I, exactly. You know, but it's also interesting, and I think you said this to me offline, is that early in our careers, we have a lot more, the stakes are lower for the mistakes that we.. You know, if you've been working at this company for 20 years and you should know better and you make a mistake, that's probably a fireable offense. But if you're a new person and you're learning and you know you have the right atmosphere, and it's actually a good company you're working at, if you do something, if you make a mistake that makes you a better employee in the future, like the ro, your roIf you can learn from mistakes, actually goes up every time you make a mistake. Rather than completely detracting from things, which, which is maybe a very different way to look at these things. I wouldn't recommend just going around making mistakes on purpose, , but, but, you know, take, take some risks is, is probably the, some calculated risks is probably the where, the direction, the advice goes. Yeah, I agree. I mean, even, even if you're a senior and you make a mistake, The worst thing you can do, worst thing is try and cover it up and make sure that no one sees what happened and people will find out. Right? And it will look bad on you. Owning up to it allows the people that look up to you to see, Oh, this is a safe environment. Right? And I'm not the only one that makes mistakes. It happens to other people. Other people I look up to as well. And it creates that safe space and allows people to right, learn from their mistakes. I. The best thing you can do when a mistake happens is share what you've learned or share in any way how you recovered from it. So other people also learn from that, right? I think if you have a culture where it's safe to make mistakes and you share when it happens, it'll be a great culture to work in as well. You know, I think a lot of this conversation is centering around communication, like transparency. Directness of the communication style that you had described. Something that I think a lot of people struggle with is pushing back or giving feedback and I, you know, it was either earlier in this one or in my episode on your show or we talked about actually giving constructive feedback. Do you have any thoughts on how you can push back effectively or how you can give criticism constructively and effectively? Especially when you're, you're talking to people who are, you know, quote unquote like superiors or have been there longer, that can be really difficult for people. I feel like you're someone that would be really good at that. Yeah. There's, there's two things and I see them as separate criticism and feedback is a, is a separate thing from kind of pushing back on things. So I'll zoom in on the, on the pushing back cuz that's something I had to get more comfortable in doing as. Throughout your career, you experience things and that experience you take along with you until you come across a case that is similar or near similar. Right? And then you kind of have that gut feeling that's like, Oh, I think this is the right way to do it, or this is the right way to go. And when people oppose that, then we have a dialogue about that, right? I've always seen myself as some someone that's very stubborn, but what I don't like is being stubborn because I'm being. I can be stubborn, but if you convince me, I'll happily come over to that side and I'll learn from that. Right. But if there's no argument for it doing one way, and the argument is we've always done it that way, then I will challenge that because then I wanna know why we've always done it that way. Right. And if I can argue why the one that I'm advocating for, the way that I'm advocating for is better than I would expect someone to listen to that as well. Right? We put all the arguments on the. And the best choice, the best way in the end of the day wins. Ideally, and this is something I realized because I had a conversation with Jessica Kerr. She said, ideally we would pick both ways. If time wasn't an issue, money wasn't an issue. We would pick both ways. And then yeah, we would see how far these paths kind of go and one would go faster than the other. And one, we would see the benefits based on both paths. And then we kept make a more educated decision on which path is a better. Because we don't have that. We have to make those decisions upfront and we have to have that discussion based on that. I've had many conversations where, out of principle, maybe principle is the wrong word, but there was a task which we needed to do, which was so detrimentally opposed to how my kind of vision of reality works that I said, this is such a bad thing, we should not do this. And we had a conversation about. They really tried because they also, throughout their stakeholders, this was a conversation I had with the product owner just to set the seed. And one of the stakeholders told them, we need this implemented because otherwise the project can't continue forward. Like this is a bottleneck. We saw it last minute, we need this resolved in this way. So that's what we got as well as the software engineers, as the team, can we resolve it in this way? And I was like, why does this happen in the first. Well, so on and so forth. And I was like, well, they shouldn't, they probably shouldn't be doing that. So we also need to we don't have to implement this. Basically, I think the best piece of software is where you don't have to implement something and you can just fix it without creating a piece of software. Right. Fix it in your process. Fix it in your way of working. So that's usually what I advocate for. We don't have to build a feature to accommodate for a weird process that we have. We just fix the process. Then we don't have to feature either. And they. I have this project manager that really wants this implemented, so I would love it if we can actually do this. And I said I completely get it, but we need to talk to the project manager cuz this way of working, it's not gonna work long term. It's already faulty as it is now. And we have like the residual damage is gonna reflect in the code base. You don't want that cuz long term it's gonna have diminishing returns in that way as well. Yeah, they really didn't agree. Absolutely. And I said, I'm not gonna do this. Okay. I think this is so detrimentally opposed. I would love to talk to the project manager myself if we can't do this. I have an IT manager like this point, like I feel like I'm advocating for the company as well. The things that I'm building should be beneficial to the company. And this was so detrimentally opposed that I felt it was rightful for me to go to my manager and have a conversation about this cuz I really thought we were taking a wrong turn in implementing this. So through. I'm open in my communication. If I don't know something, I'll tell you, but I expect the same from you as well down the line. What happened was I did go to my IT manager, they went to the director, and I had already worked up quite a reputation within the company that the director knew my name and they knew this kind of situation and they heard what the process actually was and they had the same exact realization that I did that this process was. We didn't need to implement something, some feature in the code that we actually needed to fix this process, right? So he picked up the phone, he called the project manager, and the project manager also realized the mistake he was making, and we actually fixed that process, right? It was costing us money down the line Anyway. We fixed the process, which was not software related. We didn't need to build a feature. So it was just win-win all around. But because people just take what they. Pay it forward, push forward. Don't ask questions, don't really see where the company's going or what the side effects are through that. They just do it and they implement it. Yeah. You have some difficult conversations sometimes. Yeah. Well, it seems like it really does. They can really pay to stand by your principles, right? if your principals align with the value and the, and the, and the benefit to the company. It's pretty hard to go wrong, right? you can almost never fault someone for, for doing what they think is right with within the organization or for the business. And if it means a couple more meetings, if it means, you know, as long as you're handling it in a mature way and you're, you're being transparent about it. The downside is, is relatively. Maybe worst case, you're forced to work on something you don't really enjoy if you're wrong, but, you know, you don't seem like the type of person that's gonna throw a hissy fit and walk out of the office or anything along those lines. Right? Yeah. You know, something that maybe it's changing gears a little bit, but I really want to hear. Some of the opportunities that you set yourself up for from advocating for yourself within, within your organization. I think the podcast is definitely one of them. and your story of how this, this podcast started to me is, is fascinating, right? I mean, it, it was an opportunity that you, that you jumped at very similar to, to you taking a stand, you know, for example, against a system or a proposed project that you didn't believe in. This is kind of the opposite of that, right? It's your, well, similar and opposite are, are, can kind of be the same thing in the scenario, I guess, but, but, but where you're advocating for yourself, you're jumping at an opportunity rather than you know, disagreeing with, with a process. Can you just walk me through the sort of the origin story of, of the podcast? Yeah. So the podcast originated, I'm a, I'm a consultant at Xabia software consultancy company. And I'm in the unit that is responsible for software consultancy. We're in a call of about 50 consultants and we have a management layer as well, but we have a really flat hierarchy. So we have biweekly calls where it's just updates about potential projects, which just awesome stuff that's, that's going on about in the unit that we have. So we had a new marketing guy, relatively new, and he. Well, one of our principles as a company is knowledge sharing. It's something that we do biweekly. Every other Tuesday we take a few hours off, which is really cool cause we don't have to be billable. And we kind of set these, it's similar to like a university course or someone prepares something or sometimes it's not even prepared. People join that session and they learn something about something. Can be software related, can be data related. I joined a talk that was like Chinese for beginners one. The guy had done a bachelor's degree in Chinese linguistics and he was just sharing the, it was fascinating, but I won't, I won't delve into that that much. But knowledge sharing is inherent in what we do. That's also how he advocated it. And he says, I'd like to do a podcast. I think we have so much knowledge in house. We could really make an awesome podcast in a way of broadcasting that knowledge and just have a really cool kind of frame for it as. And I thought, man, that'd be really cool. At the time, I'd been listening to podcasts for about 10 years. This was a year and a half ago. I've always listened to podcasts. I told you in the beginning, I was big in gaming. Gaming sometimes gets a bit mundane, so to really still stimulate my mind and make it seem like I'm doing something useful, I was listening to podcasts while gaming. That was my, sometimes all of my summers. So I had always been listening, but I was never part of the. Every part of the conversation. I always thought it would be interesting, but I never saw myself taking that step to actually creating a podcast. So one thing he said stuck with me and I obviously, I took that and ran away with it, is he said, we'll facilitate anything you want, anything you need, you can pick your own format, you can pick the cadence, the consistency. We'll we'll be there to facilitate. And that was really like the kick I needed to get started with this thing. The beginning is hard, right? There's so many things you need to figure out. So many things you need to think about. So having someone that joins you on that journey is very valuable to me. That really helped me in being like, yeah, I wanna do this. So he mentioned that in a call we had with about 50 people, no one replied cuz it's a call with 50 people and it's kind of awkward to reply sometimes. He just said, hit me up afterwards and I'll we'll make it happen. So I did that The next day I hit him. Because he didn't get any feedback. He already went to my manager at the time and he said, listen, I didn't get any feedback. I really think this podcast is a good thing. We can do this. Can you give me a list of consultants that you think will be great at this so I can reach out to them and we can see if we can make that happen? And my list was, Oh, my name was on that list, but it was also on top of the list. My manager was like, Patrick said the guy you need. And coincidentally, I hit him up before he got the chance to reach out. I did say I have some preconditions I wanna do in English, cuz I want it to be as diverse as possible with regards to guests. And I want to be able to broadcast this globally, so not just in the Netherlands. If we were to do it Dutch and I also wanna do it weekly. I think if we, if we do it consistently, consist consistently, if we have a good cadence with it, I want it to be weekly. I think that's how I can get better at it Biweekly. I didn't really have a good feeling about that. I think weekly was the perfect cadence, and those were kind of my only two terms. I also wanted it to be an authentic conversation in the conversation that I was gonna have with the podcast. Not really edited down, not really too much about coding itself. So that's how it kind of came to be. We got together, we recorded the first five episodes without broadcasting anything. Once we hit that five episode mark, we started broadcasting everything. And yeah. That was a year and a half ago, still going strong to me. That's so cool. You know, there's this opportunity that presents itself and you are the person that capitalized on it. You know, it, it might have been preordained because your, your boss had put you up and it, it's very cool that your manager also, knows you well enough that, that they would know that you also would really enjoy this, this opportunity. But yeah, I really appreciated that. I think at a global perspective, there's so many opportunities that present themselves in work or in our lives that we don't necessarily see as opportunities or that, that we don't necessarily see as something for us that totally could. You know, there's 50 other people in this call where they could be the person hosting this podcast if, you know, I feel like you almost a hundred percent do a better job than pretty much any of those other people. But you know, the idea is that if you're capitalizing on these opportunities as they present themselves, you can do some pretty, pretty cool shit, right? Yeah, exactly. and they're a lot more common than we think. Have to be able to identify them and see them, you know, this was evident to you because you've been listening to podcasts for a long time. Yeah. But you know, maybe people are, are, are glazing over in these meetings. Hopefully not. But, you know, they're, they're not thinking about the opportunity. They're thinking about the work and the, and the other things that are going on. And when you start being able to identify opportunities, , you start being able to capitalize on them more effectively. And I think that your awareness of podcasts made this opportunity more accessible to you. So if someone else is, you know, they're like, Oh, I know there's some people that do podcasts, but I don't really understand what it is. Like people talking to a microphone, maybe they interview people, whatever. You know, like their awareness or, or their aptitude for this type of opportunity is lower. But you've put yourself in a position where essentially like a podcast opportunity is in shining lights for you compared to dull lights for, for someone else. And I think that that's really interesting. Like we, we sort of have this superpower to self-select and work on things that we find most interesting. You know, there's this I... there's a really good name for it. I forget what it is, but you know, if I go and buy a red car or a red like Volkswagen Beetle or something like that, when I go out and drive, I start seeing them everywhere because it's in my realm of awareness now. And I think that this is a very cool example of you having this opportunity at work and podcasting, being in your realm of awareness and you being able to capitalize on that because of it. I also, on a broader level, there's a lot of cool opportunities at a lot of companies that we just don't necessarily see. Yep. Or we don't think, you know, who reads all the company emails that go their way? I certainly wasn't one of those people. But, you know, sometimes it can pay to, to open your, open your horizons and be, be also open to working on different projects. Finding things that you might be interested or self-selecting within these organizations into things that you're entrusted in. Yeah. Yeah, I agree. There's, there's two ways you can go about opportunities, right? Sometimes an opportunity presents itself towards you. There's a new position opening up, or there's this thing we're doing and you can participate or you can take ownership of that. The only thing you need to be you need to do then is take that step, right? Take that plunge towards that, say yes, and then try things. Sometimes you also have to create an opportunity for yourself. If there's something you really want to do, you really wanna do it within that company. Say so, right? Tell your manager, tell other people. Try and create this thing. If you miss, like if you see a void in a position that needs to be fulfilled and you want to fill that void, by all means do that. Right? If you can advocate for yourself in that way, if you can convey that it is a problem, and you can be the solution towards. You can create an opportunity for yourself as well. And I think a lot of people, a lot of times I hear, yeah, that's not how it works here. It would never work here. It can't work here. And I think it's a real shame because I think if you start that dialogue, if you start advocating for yourself as well, make it aware of what you want and where you want to go. People will help you. People will make sure that you get to that position. Right? Everyone is helpful in this kind of organizational sense cuz we're all doing it. So making them aware of where you want to go makes them able to help you as well in creating that opportunity for you. Yeah, and the worst thing people can say is no, I don't think exactly too many people have been fired asking to do more work at their job or a slightly different type of work at their job, right? I mean, it worked out clearly very well for you with software. Where you were able to make that transition because you asked for it. Has there ever been a scenario where you asked for something and it actually didn't work out for you? I've had some rough conversations when it comes to salary, especially in the last few years, right? Because throughout COVID we've seen an enormous salary increase when it comes to software engineering in the market, in and of its. Yet some organizations mine somewhere, somehow included as well, have this traditional way of compensating. Right. And it's a year over year thing and they kind of have these ranges that you fall into. But yeah, I've been an exception in those. So I also advocate that I am an accepts in those. But it's still a difficult conversation. It's always gonna be difficult conversation cuz you're talking about money. And at the end of the day it is some, somewhere, somehow transactional. This kind of job that you have in such a way as well. But I think those are the, yeah, probably the most difficult conversations you can have when you don't feel appreciated. Right. When you don't feel compensated for the work that you're doing, you have to make that known. You have to. Make that aware to the people. Cause the worst thing that can happen is you sitting with that feeling also from an organizational point of view. Yeah. And they don't... I'm not being aware. Exactly. And then you leaving at the end of the day cuz another opportunity passes by and you think I can do better somewhere else. Right. That's a, that's a miss on both ends cuz most of the time I feel like employees don't wanna leave. They leave. If there's a better opportunity with regards to their future career that they. If that position, they can't create it internally, they see it somewhere else, so they jump for the opportunity, or if they feel that they're being compensated unfairly with regards to either colleagues or with regards to the market that's outside there. And the worst thing that can happen is the organization doesn't know, so the people leave. I think that awareness is that you described as something that's so important and so overlooked. I. When I was, when I was still working more, probably a more traditional job, I started YouTube at the same time and, you know, I'd share my videos with the team and they thought was funny and I said, you know, this is something I enjoy doing. I wanna make more of these. And they were the biggest advocates of the, of the, of my videos. Like, watch 'em all, they'd, you know, make funny comments. They'd do whatever. Yeah. And that was really a launchpad for a lot of the success that I've had over time. People that were, were around me that were willing to support what I was doing. And companies want you to be happy. Companies want you to feel fulfilled. If you tell them what you want, they're probably gonna try to at least, like, meet you somewhere in the middle or, or, or deliver those things for you. They don't, they don't want you to leave. It's very expensive to hire new people Exactly. And to train them and do a lot of these things. And your peers want you to be happy. They. Hopefully want you to be not in just like a crummy mood all the time when you're around them. And so, you know, if you're actuating and putting stuff out there, it's surprising how much other people are willing to, to support what you're working towards. And I think a lot of people look at, look at the world in a different way. They're like, Oh, this person wants. They think, Oh, if I tell everyone that I want this, this new role that just opened up, they're gonna want that role too, and they're gonna be after me and whatever it is. On the other side of that, if you're the first person that says that you're interested in the role, you're gonna be the first one that people think of, right? I mean, it's one of these things where you can speak a lot of stuff into existence. I mean, I've gone on camera and said what some of my goals were, shared it with an audience. People on YouTube, people in my friend group, people in my community, my parents, all these people, they're, they're more than happy to do whatever they can to, to support that goal. I mean, the thing that people are drawn to is like the pursuit of something people admire or respect people that know what they want and they strive towards it. They're willing to help other, you know, help you in that pursuit of the thing that you want. What, what people, I think in general can't stand is if someone doesn't know what they want, it's really hard to support someone who is, is lost or whatever. I mean, friends and family, I think that that might be a different story, but it's really hard to get behind and support someone that doesn't know what they want, because how do you actually provide support for that person? By saying, telling people what you want and what you're interested in, you make it easy for other people because you've clearly articulated what you want and they just have to help you get there to, to add value to your life. That, to me is like, it's something we, again, overlook so much. Yeah. Yeah. I agree. And also the opposite of that is true because you are able to try out a lot of things you might not learn initial. what you love doing, but you know what you don't like. And I think knowing enough of what you don't like will trend you towards something you actually do. Like making people aware of what you don't like is also important. Yeah, I mean, I agree a hundred percent and you hit it on the head. I mean, I learned a lot of what I don't like from my , my past. Yeah, me too. In my past work, and that's how I've shaped a lot of the work that I do now is, you know, I every. Month every, well, maybe not every, not every month, every year I do more of what I like and less of what I don't like for my career, and I just slowly try to cut out the stuff I don't enjoy. Or it's hiring people, whether it's, you know, hiring people is a big portion of it, but or whether it's just, you know, like turning things down and taking opportunities that are more in line with my value system. I think that that's how you iteratively build the life that you. Which is I think what everyone is, is hopefully striving for. Yeah, I love hearing that. So my last question, I mean, obviously you've interviewed, well, last series of questions. Obviously you've interviewed a lot of people on your show. I'm wondering what your biggest takeaway is from interviewing so many people in like a technology driven domain. Is there like an archetype you've seen? Is there just any common themes that, that were surprising to you? Yeah, I hadn't thought of that earlier, but the biggest thing, the first thing that springs to my mind is we don't talk often enough to each other. Weirdly enough, a lot of the technical issues are not that complex, right? Sure. You need to figure out how to start initially and you gotta make some choices, which will have consequences in the long run. But we, as an organization or because of the processes that we. Can make software really complex. I don't think software inherently, sorry about that, needs to be complex. I think people make it complex and mostly it's because of miscommunication or weird processes, and if we can kind of figure out why those processes are in place in the first place, if we can simplify them, then our code, our software, the thing that we create becomes simpler because of that as well. Software is always gonna be around, right? You might start a proof of concept and it's a success, and all of a sudden you have to scale that proof of concept while you make some choices, which might not be the best to scale yet but it's because it's always gonna be around. And even though you might think, Oh, at some point we just throw this in the trash somehow, some way it becomes incredibly valuable to an organization, so you'll never actually throw it away. So making things initially as simple as possible. Has the biggest benefit in the long run? I think if we really focus on communicating what we need, making it sure that we have a mental understanding or a mental model that is aligned throughout the organization, throughout the team that makes sure that's minimal miscommunication. I think miscommunication is always gonna happen. We just need to figure out how to minimalize it. It makes it simpler for your software in the. I like that so much. I mean, it's just less things are technical issues than human issues, and it's really hard for engineers to to, to see that. Right. But I mean, for, from my perspective, like, Oh, everything is like we can automate that. That's a coding problem once this and that, and it's like, why are we, you know, why are we even asking this in to begin with? Why are we building this? Why, why do we have this process? Is that. Do we get to that from just asking questions? A lot of why questions? Or is there something maybe even simpler to, to get to the, to the bottom of a lot of that issue? I mean, initially you wanna do that in your own sphere of influence, right? Making sure that everyone has that understanding of, Okay, what do we wanna do and why do we wanna do it? Right? And initially you start with the why, because then you can derive what you actually need to do it. What you actually need to do in the first. And lower than that is how the easiest thing is focusing on yes, we can solve that. Because that's like a, it's like an adrenaline boost, right? You solve a problem, people are happy onto the next thing, and you keep doing that. You keep doing that, you keep hitting that. Maybe adrenaline rush is not the best. Maybe it's like a sugar rush. But that's all short term, right? And yeah, in the long term, software will become worse of it because you've made so many, like minimal fixes, so many. Positive wins in the short term. That in the long term things get complex and then all of a sudden your product owner is like, we used to be able to do this real fast. Why is it taking this long now? And you have to communicate like, Oh, we made some choices and we have to refactor, or we have minimal tests in place. Like that dialogue starts happening at the end. While it should have been upfront, right? Why are we doing this? What do we need? And then we can figure out how to do this. I think if you do that in your own sphere of I. You can also try and make sure that other people do that right, because they will see the benefit of that, and that benefit will be residual. They will pay it forward. They will ask the same questions. If I ask you a question and you don't know it, you're gonna ask someone else because you wanna be able to respond to me as well. If you are aware, you're gonna feel accountable, so then you're gonna make sure the information is transparent or is in order to be able to communicate to other people as well, right? But it all starts kind of small, kind of with awareness. I think it's a big shift in mindset, especially for software engineers because right, if you are in an environment where everything is, is well thought out and you just get what you need to build and you can focus on how you need to build it, you never have to ask why questions at all. In a bigger organization, you can just coast along through that and do your thing. That's not a problem. But if the organization is smaller, right, and things are a bit more dynamic and. You can do 10 things, but the value differs. You have to be like, why are we doing one out of nine? While I think this thing will deliver more value down the long run, you have to have that dialogue because you wanna deliver that value as soon as possible. Right? Being able as a software engineer to have that dialogue doesn't have to be with your product owner. It can be directly with the stakeholders, I think is invaluable to you being within that organization. I agree. And something really small that you, that you alluded to in that, is that I think a lot of people can found being busy with being effective. Yeah. And we can fall into that trap of like, Oh, we just put out all, you know, I put out new feature, new feature, new feature, new feature, great. And then we never think about if they're actually creating positive impacts from all the new things that we're putting out. Right. It's really easy to feel excited about all the progress you're making. Even if that progress isn't necessarily aligned to a broader goal of a company or a team or an organization. And, you know, getting to the bottom of it locally and having that understanding as a group and as a team, I think is really important. And also that probably is, is relevant for, for good managers and good people who like grease the wheels of communication on a team. Yeah, yeah, absolutely. And your why or the answer to your why question might not be what you wanted to hear. And in a startup where I didn't really agree with what we were working on, but that was the only financial lifeline that we had, so it's kind of, ah, we do this, or, or we die off as a startup. And I'm like, well, I might not like it, but I can accept it, right? Because I believe in this vision that this startup has. So we will do this and then we will focus more on value, right? Sometimes some decisions might not be what you, but everyone in this thing, right, we're all people. We all have an understanding. We can all accept some things as reality. The worst thing that can happen is not being transparent about the reality that's actually out. Amazing. Well, Patrick, this has been absolutely awesome. I think we'll wrap it up here. I'm fading fast. This is the latest I've ever done a podcast 11. I'm sorry man. I really appreciate it. No, no, no. I don't mind. I don't mind. I'm really happy we made it possible. Me too. With the difficult time zones. Mostly on my end, I think is the, is the challenging time zone. But I, where can people learn more about you? Learn more about the podcast and is there any, Final thought you wanted to share? First for, well, people can find me, it's Patrick Akil on Twitter and on LinkedIn. If you wanna check out the podcast, it's beyond coding. I think if you type that in on YouTube you'll find our, our actual visual episodes as well, or on any other podcast platforms. I really love this conversation normally. Speaking that much, obviously, cuz I kind of am in your seat, but I really enjoyed you being in the driver's seat and me just kind of tagging along. I had some thoughts here and there, but I feel like I had been rambling a bit too often. So I slowed things down. But you picked it up great. So thank you so much for doing this. I enjoyed it too. I hope, I ... See, I was worried about being too ramly. So, I think we were, it was, it was absolutely incredible and everyone's gonna get a ton of value out of this one. Awesome, man.