JT25 | Paolo Garde On Transitioning From Operations To Software Engineering

Looking at the salaries, demand for Software Engineers nowadays, have you ever wished you had opted for computer science or some sort of programming course, rather than following your current path in operations, marketing, HR, or anything other than software engineering? Well, the good news is that you can actually make that transition even now, even if you are mid-career, and you might not even need to go back to college to make it happen.

Welcome to another episode of JobTok. Today we are speaking with Paolo Garde who made the transition to Software Engineering after eight years in F&B which is the food and beverage industry and in operations. He’s going to help us understand how he went about making that transition, and what to expect if you decide to go down that route as well.

Discussion Topics: Paolo Garde On Transitioning From Operations To Software Engineering

• Progressing in software engineering
• How did the transitioning to different department happen
• safety net thought process and planning
• application orientation and learning process
• approaches you can implement to transition to software engineering

Transcript: Paolo Garde On Transitioning From Operations To Software Engineering

Amit: Looking at the salaries, demand for Software Engineers nowadays, have you ever wished you had opted for computer science or some sort of programming course, rather than following your current path in operations, marketing, HR, or anything other than software engineering? Well, the good news is that you can actually make that transition even now, even if you are mid-career, and you might not even need to go back to college to make it happen. Today we are speaking with Paolo Garde who made the transition to Software Engineering after eight years in F&B which is the food and beverage industry and in operations. He’s going to help us understand how he went about making that transition, and what to expect if you decide to go down that route as well. But before we begin, a couple of quick reminders, please do subscribe to our show, so you don’t miss any of the great guests that we have coming up. And if you need notes from today’s session, please head over to CrazyTok Media to get the entire transcript. So with that, Paolo, thank you so much for joining us today. And maybe for a start, would you like to share with us a little bit about your journey, and your career so far, it’s really interesting that you came from an entirely different industry, food and beverages into technology. And now you’re kind of getting deeper into the tech space. So yeah, please do share a bit.

Paolo Garde: All right. Hey, everyone, Hey, Amit, it’s been a while. Good to catch up with you again, my name is Paolo. I have had around eight years of work experience in the startup field. I actually accidentally got into the startup industry without really knowing what I was getting myself into. So that might be its own story in and of itself. But yeah, before that, I was actually in the food and beverage space. But in the startup space, my first startup job was at Uber Philippines in 2014, we helped build Ubers first offshore functions, then I moved to Australia. After around four years total at Uber, I moved on to become the head of operations at Food By Us, an Australian startup in the food and beverage space, there’s a combination of my life’s experiences up to that point. In 2020, I joined another Australian tech company, this one with the goal of being the Assistant to the home, I initially joined in an Operations role, which I did until around the end of last year 2021. Around this time, last year, I actually decided to take a bit of a huge gamble and try to make a career change, enrolling myself in a six-month intensive coding boot camp and successfully transitioning to Software Engineering, just at the start of this year.

Amit: Wow Paolo, that is quite something intensive coding boot camp are not three words that most people would want to kind of indulge themselves in as a side hustle, but good for you. And we’re gonna talk more about it, you know, subsequently in this conversation. But since you talked about accidentally falling into the startup industry, do share how that went about.

Paolo Garde: Yeah, back in 2014, I was working in… it’s actually like a bit of a beverage company was what we turned ourselves in. They were like a hybrid coffee roastery, cocktail making distillery, we did all sorts of beverages. And at that time, I was just referred by a friend of my cousin into this thing called Uber. And this friend of my cousin, he really was into these referral shares that Uber used to offer back in the day. And so he was like, taking all of his friends with his friends. And I just happened to be one of the people who received an email. And our Shared Manager at that time, actually was a customer of that cafe. So I’m not sure if he never knew that cafe. I’m not sure if I would end up at Uber or how much that came into play. But I think because I had a bit of like, customer service background for my days in food and beverage, and we were still a startup as well in the F&B so it involves a lot of just figuring things out, building spreadsheets, building forecasting models for roasting. It’s actually a bit more technical than I thought it would be. I’ve somehow passed the interviews and I had no idea what Uber was back then. I think we were all on, like, very short term contracts. But I was a naive 22 year olds, so I didn’t really know anything about job security back then. So I took the plunge and then yeah, really, it was a life changing moment for me there. That kick started my career in tech.

Amit: Yeah, great. And that’s a really great story Paolo, and I think the good decision made overall. So speaking of changes and kind of stuff, let’s talk about this particular one. I mean, you, was it sudden that you decided in the middle of last year to do this coding bootcamp and what were you trying to actually achieve with it? Why did you choose to try something so different?

Paolo Garde: Yeah, I think it’s a couple of different factors, I think part of it is a bit of self-realisation on my end, and like my own journey into knowing a bit more about myself, historically, I was always hyper competitive and very, very insecure. Partially, I think, because of my non-traditional background, moving into tech, I always had a chip on my shoulder that I had to prove myself, in terms of like, competing with my colleagues who had all these fancy degrees MBAs, ex management consultants, I was a guy with a hospitality degree and who knew how to make really good coffee. So I had to be able to be competitive. And at the start, that meant I had to work double, triple the time to achieve the same outcome as my contemporaries. But somehow, I was like, always making it through the next __ (06:09 inaudible). So I’ve always carried a lot of impostor syndrome, especially very early in my career. And while that’s led to me ending up where I am now, which is, I’ve had a fairly successful operations career, it hasn’t been without its challenges. And without it sacrifices, especially to my mental health, my overall work life balance, the time that I’ve spent with my family, I think, actually, a turning point for me was in 2019, unfortunately, my grandmother had passed away, who, up to that point over the past few years, I never really made time for her because I was so busy with work. And I think that was a really big turning point for me, because actually, like, it got me into a really dark spot, because I would always see, she would message me at random things, and I would just never have the time to reply. And I think after that point, I was like, I would never put work in front of my family after that. So I think that was one aspect which led to a lot of introspection on my end. Because initially, with my career, I was always destined to go down this operations leader CEO pathway. But I think I realised, at some point, the linear path wasn’t for me, while I was pretty good at certain aspects of operations. And it really helped me get to that point. At some point, I stopped enjoying a lot of the work that came with the increasing levels of seniority. Because I guess you would know this as well Amit like, as you get more and more senior, you get a bit less hands on, especially as the company grows, you get a lot more involved in strategic direction, and a lot more time spent on meetings. Unfortunately, it also comes with a bit of politics as well. It’s just natural in any company. And I got to say, I sort of didn’t enjoy that as much as the journey getting to that point.

I think another thing is that after so many years of just prioritising my work, I’ve just come to terms with the fact that you know, my work isn’t my identity. And I just wanted something which could lead to a bit more flexibility. Heading into my 30s, I’m talking like this, like an old grizzled veteran, but yeah, I’m turning 30 this year. So I’m like, maybe this is the time where I want to just take a step back and just reevaluate things a bit more. And when I sort of just thought about where I could maybe take my career, Software Engineering just popped up as something which could take a lot of these boxes. I think some of the factors are that, one it has, I think, a higher salary floor than other fields. Regardless, if you’re an individual contributor, or a people manager, the floor that you can make as a Software Engineer is quite high as opposed to say, in an operations career where you’re almost always going to be a people manager, say past the entry level point, that’s always the next step.

Software Engineering aligned with my love of tinkering with things figured out at some point that my work, I guess, superpower, was being able to figure pretty much anything out when needed. That manifested in me being the person who was always the first to understand new tools, new systems. Somehow I always inherit being a system admin for every tool out there, even though it wasn’t what I signed up for. But I figured out that was like, constant with every job that I joined. I was always the first person to just understand the semi techie side of things. Part of it as well is just that Software Engineering jobs nowadays, most of them are pretty flexible, let you work 100% remote or in a hybrid environment, and I think over the past two years, that’s just something that I’ve come to really like that sort of flexible to work anywhere and switch things up, if you want to come to the office for a bit of a break, you can go there but not being held down to one spot.

It also gives me a lot more flexibility. Later in life, if I do want to decide to maybe move to a, maybe to back to the Philippines or to a lower cost environment, at least I’ll be able to find a job anywhere in theory. And then lastly, I think it gives me career flexibility as well. Because even if I didn’t end up being a Software Engineer forever, let’s just say, I ended up hating this career or just not liking it or not being very good at it, I at least have tried, I at least would have had experience in it. And that could maybe lead to a shift into product management. Maybe going back into operations, like being an operations person, but actually understanding Tech, I think, will give me a bit of an edge there. Or maybe even found my own thing if I do find something I’m really passionate about. But with a much more well-rounded skill set.

Amit: Yeah, I think there’s a lot of good stuff that you shared there, Paolo. First of all, I think you’re in a moment of realisation in 2019, it’s something all of us I think are guilty of, which is, you know, family member’s messaging, then ignoring the messages, because you’re doing other stuff. And you always rationalise it with, Oh, let me just finish my work now and then I’ll get back to them later and we never really do that. So, thanks for bringing that up. And thanks for sharing that anecdote as well. I think it’s something everyone will identify with in some shape, or form. And it’s a good wakeup call I think for all of us in that respect. I also think, you know, the way that you’re thinking about this whole process, which is if you’ve done the operations, which is let’s call it the front end part of what is happening, which is with the customer, and then you’ve done the Engineering, which is the backend part, which is making the product and enabling all of this stuff, it’s true, you can actually move back and forth between them quite well. And it makes you a very valuable, well rounded kind of person, because an Engineer who understands operations is beautiful. And if you were to take up something in the middle, which is your whole product role, like you mentioned, then you do understand both sides of the equation well enough to be a very good Product Manager. And that’s a very valuable skill and roll in itself.

So I think the way that you’ve thought things through seems about right. Also the age of 30 Yes, you’re not a grizzled veteran, but 30 is really a cutoff time, I think a lot of people start thinking about things at 30. And then again, at 40 a different way, because then maybe you have a family or more responsibilities or whatever at home. So these are natural cutoff points when people think about changing their life or what they should do with their life. So it does sound very natural and familiar in that regard. But how you are looking at it is actually quite interesting. So tell me a bit more about the whole Software Engineering element that have you’ve moved into. I mean, you’ve only just started I guess, it’s been a few months. So how’s it been so far? Do you find yourself progressing? Do you think it is what you thought it would be?

Paolo Garde: So I officially made the transition in January of this year. And my Company has been nice enough too. So I’m not sure if I mentioned but I did an internal transfer and my company knew about it for a long time, so we can chat about that, I guess a bit later about that process. But on my end, I started January 2022. I was eased into it a bit where I was sort of added to a new team. And then I was given the easier tasks at first as you do. I think where I’ve been able to at least contribute is because I come from that operation space within the same company, I could at least understand a lot of the customer pain points, both internal and external that we were trying to solve. And at least I was able to contribute in the product discussions, in the sprint planning. Even though my coding skills are still a bit of a work in progress. At least I’m able to feel net positive there. I realise it wasn’t as much of a massive transition in some aspects. Because I did have some transferable skills already. I cut my teeth at Uber as a Data Analyst. Very, very heavy on just generating a lot of SQL queries. So that’s definitely made me a bit more comfortable transitioning into working with databases, and a lot of the projects and just managing projects and ops, working in a high growth startup environment a lot of those skills are actually pretty transferable in agile.

Agile has a lot of branding and buzzwords attached to it. But at the end of the day, a lot of it is like fairly similar principles in terms of building something iterating on it quickly deploying, when you can, and then testing and then just iterating. So a lot of those, even though it has a different brand, I feel it has been quite similar and has been a bit of a smoother transition. I’ve only been at it for four months. So I’m not sure yet if I want to do this forever. But at this point, I definitely don’t regret having tried.

Amit: Yeah, that’s amazing. And let’s talk a little bit more about how you went about doing it. Because this seems like a big one, right? It’s not like an ops person moving from one team to another, with the company obviously thought they were hiring an operations person, but now this person wants to do Software Engineering. And it’s not something that they’ve done before, whereas maybe they should be hiring from outside someone with this skill set. So how did you prepare for this transition? How did you think it through? How did you convince your Company to give you this chance?

Paolo Garde: Yeah, so I think the first thing I did was actually to find people who’ve done it before, and try to reach out to them. Unfortunately, there wasn’t anyone I could find. Because, there’s a lot of people who did career transitions into Engineering, but there’s not a lot of people who did it from, I guess fairly senior operations roles into, I guess, a fairly, entry level engineering role. So I realised I had to make my own path. So around the start of last year, I just set myself this audacious goal that I wanted to be a Software Engineer by 2022. And I started off just researching how people normally transition into Software Engineering from scratch. The two main routes are to either go self-taught or enrol in a boot camp. You could also enrol in a university degree, but it’ll take you two to four years, depending on what you want to do. So that was out of the question for me. My tip for anyone here starting to consider this is just self-reflect on what your learning style is, like, are you the type who can do it self-paced, because everything there is on the internet, you can do it all yourself. But also it requires so much more discipline. I took the boot camp option, because I’m pretty lazy. And I can never really self-motivate myself to do something. And having paid a pretty hefty sum to start a course that’s pretty big motivation because prior to that, I’ve had this huge stack of Udemy courses that I haven’t touched for years. I think I have a web developer boot camp in Udemy from 2016 that’s been like, in the intro stage. I haven’t ever gotten passed it. So yeah, I took the boot camp route, I had to obviously figure out how much time I would need to put into it. I did my research and I guess the consensus is that you would have around 10 hours of classroom time in this boot camp, but you need to put in around 10 to 20 hours on top of it just on self-study and completing homework. So yeah, that was around 20 to 30 hours a week on top of my day job that I had to mentally prepare for.

Luckily, the boot camp I chose had all of its hours past 6pm. So I had a chat with my Manager then that I would be unavailable for work between 6 to 9 pm, three days a week, and she was supportive enough there. I guess that goes to the next question of how did I work with my company on this? I flagged it super, super early on around this time last year, actually, that I would be going down this semi midlife crisis, this discovery phase and that I wasn’t 100% sure yet. And I told them that as well that I would be doing this boot camp. But there would be a world where I might have hated it, or I might not have enough time, or I would just suck. And that would not have been a pathway for me. But I did say that, by the end of the year, if there was an opening in my current company, I would love the opportunity to apply for an Engineering role for 2022. I think flagging this super early allowed us to consider this factor of me leaving and consider hiring my backfill and rebuilding the org when I was still around, which is not a luxury that a lot of companies have when senior leaders leave. So I think that was a bit of a win, win all around there. In terms of convincing my boss and ultimately tech leadership because my boss was the VP of Operations at the time. She didn’t really have the final say here, I guess it was the tech leads who would have the final say. I think it sort of happened organically. I was actually pleasantly surprised because there wasn’t a lot of pushback. They were just like okay, you get transfer next year.

And I was like, Oh, wow, do they even know if I’m good or not. But I think maybe just looking back at it, I think it’s because I had a good track record within the company, I built good relationships in and out of operations. And I had proven myself to at least have a chance at making it. Because one thing I figured out about myself is that I’m pretty resourceful and I’m good at tinkering and figuring things out, which is a lot of what being a Software Engineer involves, at the end of the day. And our current CTO was very clear with me that we will give you a trail, we will give you a couple of months, we will deploy you straight into engineering team, if you suck when you’re out, and you go back to offs, but if you if you’re good, then you will stay. And I’m still here. So I think I at least don’t suck too much, which is good.

Amit: But this is interesting, because they would have planned for the backfill right during the year. So I’m assuming they’ve backfilled your role. So what would have happened if you actually had sucked and then they wanted to send you back to ops, but your role wasn’t there anymore?

Paolo Garde: I’m not sure I haven’t gone down that thought process yet. But, yeah.

Amit: Is that something you considered in this whole planning process?

Paolo Garde: I guess it’s a bit of a bit of hubris on my end that I would have been like, look, if I didn’t make it an Engineering, then there might still be a role for me within the company, and that sort of what they said as well is that my company was supportive enough to say that, we’ll give you this shot in Engineering if you don’t make it, then there might be other roles for you. I guess, luckily, as well and I didn’t notice when I had started last year, like we were in the middle of a fundraise, and we were able to raise Series B. So I guess at that time to start the year, this year, then the company is in growth mode, there would naturally be some opportunity for movement there because we are looking to grow so much this year. But honestly, I’m not that good at planning. So I didn’t really think all that deep through that process.

Amit: Yeah. Okay, got it. But I think some of the factors that you mentioned, right, which is that your track record of the company has been good. And more importantly, if it’s in growth mode, it would be a bit silly for the company to let somebody could go just because they tried something new and it didn’t work out. And so therefore, there was, I suppose at the back of your mind, in any case, there would have been this kind of a safety net thought process. So that’s great. And now that you made this transition, what are some of the ways in which it’s been you know, what you expected, what you hoped for and in what ways has it maybe been a surprise or, maybe not as great as what you would have liked?

Paolo Garde: I think I expected that I would struggle a bit on a lot of the core concepts of Engineering because my contemporaries are people with computer science degrees who’ve really studied like, they probably understand ones and zeros. And once you understand the core fundamentals of how computers work, and how networks work, that will give you an edge over someone who’s studied six months in a coding boot camp, because even though this coding bootcamp is super intensive, a lot of the learnings here are spent just straight up coding without really understanding a lot of the fundamentals. Like sometimes I know, I just sound super dumb when I’m trying to explain something. I was speaking with one of the engineers last week about this work I’m doing on just network requests and optimising them. And I’m just like, explaining it, like a five-year-old, where I’m like, I connect this thing to this thing, and it goes faster. What are you talking about? So yeah, definitely, that’s something I need to brush up on more, because the thing about Engineering is, these frameworks that I know today, these languages that I know, today, those might not exist, or those might not be popular five years from now. So that’s, I guess, the downside, or the challenge of being a Software Engineer is that the code or the popular frameworks change over time, and you always need to be learning. And being a computer science major, or having a better understanding of the fundamentals makes it a lot easier to transition from language to language. Whereas for me right now, I would say I’m like, more of a JavaScript person. But if someone were to tell me, Oh, now we’re switching to Python, it would be so much more of a learning curve for me, versus maybe someone who has a bit more understanding of CS fundamentals, they would be able to switch faster.

Amit: Yeah, I think that that’s a valuable point. I mean, you know, like, maybe there’s a level one knowledge, and then there’s a level two knowledge, which builds on that. And level two is what is going to change over time. But the level one, which is fundamentals of computing, or how to interact with the computer, are going to stay the same. And so it may be easier for a person to just mentally transition, okay, the way I define variables in this language is just going to look different in this other language. But the way variables work and how they’re allocated to memory are exactly the same. So it makes it may be easier for them to kind of keep transitioning. Whereas for you, your entire worldview is this level two thing. And if it changes to a different level two thing, it’s like learning everything from scratch. But I think over time, you will build that, you know, the mental model, I guess, and then it will become easier for you as well.

So what are some of the positives? So I get it. So, you expected that you’d struggle a bit, and are struggling a bit and I guess that makes sense. So what are some of the ways in which we find you’ve actually, you know, maybe doing better or it’s been a positive surprise?

Paolo Garde: I think it’s an interesting contrast, because while I’ve struggled a lot in terms of understanding the core concepts, and they’re aspects of the job, which are reliant on that a pretty heavy aspect of Software Engineering, I guess, in my Company, or in similarly sized scale ups where there’s a bit more infrastructure setup, and there’s a lot of code already built is that you can just come in and watch help people have done in the past, and then just adapted. And I think that coincides with a lot of my learning style, which is, I’m pretty good at copying people. And just adapting design patterns and figuring out what’s worked in the past and reapplying it. And it’s also been fortunate that the tech stack and my coding bootcamp, completely coincidentally, because I was a poor planner. And I’ve never even considered this. But our tech stack is exactly the same as what I studied in the code boot camp. So at least, that’s made the transition a bit easier. The other part is because as I mentioned earlier, because I have some business context, it’s made the developing process a bit faster, because even though I might be slower at coding, I’m a bit faster at understanding the problem. So maybe, if you sort of extend that to like, a week sprint, I might be able to get to the answer faster when defining the requirements with the Product Manager, even though I’m a slower coder, but it nets out as neutral or that’s how it works in my head. That means that even though I’m not an amazing developer by any means, I’m still good enough in other aspects where I’m not a burden to the team. And I think like for me, that’s already a huge win coming from my background to not be a burden.

Amit: No, I think that that is a really good insight as well. And you know, oftentimes things are lost in translation. So let’s say the Account Manager or the customer support person actually sees what the customer is trying to do, and what’s going wrong, then they go and explain this to the ops person who’s one level removed, then they explain it to the Product Manager, then that person explains it to the Engineer, or rather, actually to the Engineering Manager who explains it to the Engineer. And by the time the person who’s going to actually write the code has figured out what is happening, it may not actually be what exactly is happening, it will be a little bit of that whole thing. Whereas in your case, you’ve got experience from much closer to the frontline. And so you can actually build to what is needed on the ground. Even of course, you’ll be working to a spec and requirements and all of that, but you fundamentally know what you’re trying to achieve, which I think what you’re saying is right, if you know that, then you’re probably gonna head in a straight line to wherever you need to go versus going in an iterative process, trying to get to the same place. So this is good insight, Paolo.

So, tell me something else. Now, we’ve talked about how you plan this transition, we’ve talked about what’s happening in the few months since you made the transition. And it all sounds fairly positive, actually, overall, given that it’s something which is so different from what you were doing in the past. I have a small question first, before we kind of move on, which is, how much of this do you credit to the fact that you were always, like you said, like, the system admin, or the person who was tinkering with the tools. Has that helped? Do you think it has helped substantially in learning to code and then in contributing? Or do you think even somebody who hasn’t really been even doing that could actually try to make a transition like this?

Paolo Garde: I don’t think it was necessarily my experience with being a system admin or being on the technical side, it was more of me knowing how to ask Google questions, or knowing how to find an answer to something in a fairly independent way. Because I had always had an interest, tinkering with things. But it was interesting, because I always liked tinkering with things, but I never went really deep on it. So for example, like, a few years ago, I really started this hobby of just building my own PCs and stuff, and reselling them and flipping them on Facebook marketplace, that was a bit of a hobby of mine. I was good enough at it, where I could build a PC and sell it, I couldn’t really tell you how it was actually all working. So it was weird in the sense where I always knew I like to tinker to a point where I’m useful at it, but I never went super deep. And so that’s how I feel that’s helped me a bit with engineering is that there’s always so much there to learn, but I could at least Tinker my way through it where I’m useful very, very quickly. And maybe that’s the takeaway there is not necessarily like, Oh, you need to have had, you know, the experience of working in a tech company. But with engineering, it’s more about from what I’ve seen, it’s more about being faced with a problem. And then knowing how to navigate through the various online resources, to then be able to solve it on your own, whether that be going through Stack Overflow, going through some YouTube tutorials, reading the documentation, being able to piece all of that together, and then iterating at it until you’re able to come up with something. I found personally that’s how I’ve been able to navigate through the first few months because, yeah, like when they dropped me and I had no idea what I was looking at the start, and it did require a lot of self-paced study.

Amit: Right. I think what you’re describing sounds to me, like, you know, an application orientation. So maybe given a problem, you aren’t going to bother about getting down into the fundamentals and the theory of all of it, you’re going to look for how do I assemble the pieces in front of me to get to actually solving that thing. It’s something similar to what you described with building computers, like you don’t need to know how the bus operates or how that chip is making any difference. But you can wire together the motherboard and maybe the graphics card and the thing will just work and you figured out how to do that. And I think that makes sense because I think also, maybe programming nowadays is not so much about getting down to that lowest level stuff. I mean, any case, nobody programs in ones and zeros or assembly language anymore, they do it in fairly visual interfaces, I guess. And with more pre developed code being assembled together. So perhaps it sounds a little bit like, you’re great at assembling things towards an application.

Paolo Garde: Yeah, I mean, I wouldn’t really recommend this approach long term. Your engineering listeners will kill you for saying that it’s all just like visual, though. But I think I’m able to at least get to a point where it’s useful. And like, the downside of that is that you can really accumulate a lot of tech debt along the way, because you might not be building things in the most efficient way. Because I think for me, sometimes, I just sort of hack it together until I get to the right outcome needed at the time, but I might unintentionally add layers of complexity that might not be there. Like, so I do say that, it’s still quite important to, maybe you’re figuring it out, and you’re able to deliver the output, but make sure you go back at it and actually start understanding it. And I feel like personally, that’s how I’ve learned is that I initially do it just by following a tutorial. And then it takes a while for it to then eventually click, and maybe it’s in the next application that you try to do, or the third time, and it’s like, oh, now I understand it. And now I’m not just following a tutorial, but now I actually understand it enough where I could put my own spin on it and I understand that underlying principle.

Amit: Okay, that makes sense. And I think that’s a good way of describing this whole learning process as well, which is, initially you are going to be paint by numbers kind of thing, look for the pieces, stick them together and hope it works. But as you understand how it is happening, then you will be able to do more of the development yourself, or at least do it in a more streamlined, efficient sort of way, versus just pasting together stuff. So, with all of that said, let’s say somebody’s listening to this, and hopefully nobody from engineering is listening. To it. But somebody who’s not from engineering listening to this who wants to try, going down this path, what’s a practical way that they can get started or implement all kinds of approaches in their own career?

Paolo Garde: So I think if you’re modelling a career change, especially a bit later in your career, I think start learning more about yourself, and what makes you tick, that’s the most important thing. This will come in the form of many different ways. You can just think about it by yourself, it can come in the form of guided meditation. I find speaking with your peers, and your managers who you really trust to know you well, is really important. But the first part is just really understanding yourself. Because once you do that, that will let you really establish why you want to actually do this thing, or why you want to change careers. I think you also just want to tell yourself here, like there’s no real shame in working for money or optimising work life balance, or like if your dream in life is to somehow work four hours a day, but earn a six figure salary, then go for gold, right? So that’s a big factor in me choosing to go down this more technical pathway. And I think another big part of this and something you need to check yourself for, is just try to ask yourself if you’re striving for something because you want to feel validation from others, or if you’re really doing it for yourself and your loved ones, because I think for me at the start a lot of what drove me, and it’s a bit of a double edged sword because maybe I wouldn’t have gotten this far in my career. But a lot of what drove me to where I was at the start is competition and wanting to do better than my peers and being a bit jealous because especially where we used to work, like you would have someone like 10 years younger than you suddenly ending up in the same position as you and you’re like, how did they do that? And why am I not there yet. So I think it’s definitely like a big thing to realise when you’re just doing something out of maybe envy or out of jealousy, because the reality is that someone is always going to end up maybe a bit more accomplished, a bit smarter, paid a bit more than you at some point in your life. And if you’re always benchmarking yourself against someone else, it doesn’t really lead to a healthy career balance or a healthy mental state there with your career.

The last part for me, and a big part of this decision is establishing your risk appetite, both from a financial sense and also a career sense. From a financial sense, I think I’ve figured out along with my fiancé, like our I guess, financial situation, and what sort of money we need to earn to sort of live a happy life. And what we realised is that it’s not like super, super high like we have never dreamed to have like a super yacht, or fancy cars, or Rolexes, and all of that. And so that’s where I’ve figured out that, hey, there’s a bit of wiggle room here, where I don’t necessarily have to be like, you know, C suite by age 40. Like, I can sort of survive and still live a fairly happy life at a certain level. And so once that pressure is out of the way, and yeah, money is definitely a big source of career pressure. Once you’ve sort of established that, then you’re able to make clear decisions, I feel. The other thing is, within your career, what I did here was just really look at what are the worst possible scenarios, if I ever did do this, like some of the things I listed were things like, if I transfer within my current company, but I don’t like it or don’t do well, my current company was pretty open with me that, I could maybe go back to operations, or there might be still a role for me here.

If for some reason I lose interest during my boot camp, it’s like nothing happened, like, I’m still in my very good job, and no one would notice a thing. If, for example, I transfer out of my company, and I did poorly, and I got let go a Software Engineer, I feel like that’s the worst case scenario. At least I feel I could go back into the operations field. I mean, the tech jobs are crazy at the moment. So I have a pretty established resume and the upside, so maybe I’ll still have an opportunity there. Or at the end of the day, if I, by the end of this, if I still become a software engineer, but I ended up just hating it for some reason or not liking it, or maybe, for whatever reason, just burning out if it at some point, at least, I could go back to the ops field where I already have had a bit more of an experience there. And I would bring in all of these new skills that I didn’t have before. And that would make me a bit more valuable as an employee there.

Amit: Yeah, that’s right. In fact, Paolo, you’re showing how much of a software slash tech person you are, by having a decision tree around your risk management. If this happens, and that happens, then I will do this. I think that’s pretty cool.

So let me just summarise a few of the points that you were making. I think one takeaway for me is that you don’t have to go in a straight line career path you started and ops, associate ops manager, ops leader, VP, CEO, you don’t have to go in that direction. You can do different things, and still keep moving forward to an extent, and definitely forward in terms of what it is that you’re trying to achieve in life because that’s when you’re making the transition.

The second point that I took away is that it is important to step back, whether you’re 30,40 or 60 it doesn’t really matter, but from time to time, it’s important to step back and evaluate what you want out of life versus what you’re doing. And I think what you mentioned was that you need to understand your why either based on introspection in the shower, or on feedback, like you can talk to people whom you trust and try to understand their perspective as well.

Third point was if you do decide to do something different, establish the risk factors, your whole decision tree way of doing things is pretty cool. And figure out how you might mitigate them. If this doesn’t happen, what’s your fallback option, what’s the worst that could happen. And most likely, it won’t really be as terrible as you might originally think it would be. The other one, which was interesting to me, is that you’ll actually find that many of your current skills are transferable and in fact, valuable in a different role. So not only is it not a completely fresh start from zero, in fact, you’re probably bringing a skill set that the other people don’t have at all, or don’t have as well developed as you do, and which will actually help you, do better in that role.

And finally, I think specifically on the transition to Software Engineering, I think you laid out a really good roadmap, which I’d like to kind of also summarise here. One is to give advance notice and not like one month, give like a year’s notice so everybody knows what you’re trying to do, they have plenty of time to plan, you get a lot of goodwill by having this conversation early. Of course, you can’t make this transition, or people will be reluctant unless you have a good track record. So you should have a good track record and have delivered something of value, you need to plan around your deliverables. So I think you’ve ensured that you’re doing this in the evenings and you won’t be available, but your basic core job is not affected.

Another tip that I took away is that if you’re going to make this transition, learn the same tech stack that your company uses, because otherwise you just be learning something which is not applicable in the company at all. And then the other one, which we discussed at some length, was when you take up the role, you have to get the job done. So focus on doing it however it is that you can tutorials, YouTube, whatever, but then you need to develop a deeper understanding so that then you can do it well. So in the beginning, just try to do it and get it done. But after that you have to be good enough to get it done right. And that’s, I think, important for long term success.

So Paolo, thank you so much. These were great tips. And I really appreciate your time today. For listeners, thank you for listening to us today, we are Paolo and Amit with ShopTok. See you next time.