11 Years of No BS Cloud Career Advice in 36 Mins

Added: 2026-05-10

[00:00:00]When I was at Vodafone, which by the way was one of the largest telecom companies in Europe and Africa, very similar to Verizon for those in the US, I was the engineer that implemented Slack into the whole business. And the crazy part, our internal cyber security team shut me down multiple times. Why do you need Slack? Why can't you just use email? I know it sounds crazy, but that was their mentality. I obviously pushed back very hard because I knew the way work was moving, email simply wasn't going to cut it. And eventually every single one of those technology teams adopted Slack. In fact the whole global Vodafone organization adopted Slack right from the UK business which was I was in every country in Europe globally everyone right because the industry had moved on whether they liked it or not. And by the way, when we were implementing agile ways of working, DevOps, CI/CD, AWS, right, moving to cloud into Vodafone, Google and all of these other tech companies have already been working like this for five, six, even seven years.

[00:01:00]That's how late big enterprises catch up. And there are still companies right now working the same way that Vodafone did 10 years ago. Long processes, big projects, very slow to adopt new technology, a lot of politics. Right?

[00:01:14]That experience told me one of the most important lessons of my career and it's going to be truth number one, which is the industry moves with or without you.

[00:01:25]Don't get blindsided. And what's wild is that I'm seeing the same thing happen right now with AI where professionals are refusing to adopt it and pushing back so hard even though the writing is on the wall. How I see it is pretty straightforward. AI makes all of us IT professionals and engineers as a whole far less valuable than 5 to 10 years ago. But a professional who knows how to leverage AI is also far more valuable today than they were 5 to 10 years ago.

[00:01:54]So you either move with the industry or it moves without you. I'm Slay man. I've been in tech for more than 11 years. And today I run my own businesses across cloud and AI consulting, my software company study.ai AI and my academy where I've helped more than 900 IT professionals, engineers, and career switches master cloud engineering and land six figure roles including at companies like AWS and Microsoft. Now, in this video, I'm going to compress everything that I've learned in tech, every mistake, every win, every lesson from the trenches into 53 truths. I started in IT operations, retail systems at Vodafone, 500 UK stores making sure they could transact, take orders, process payments, and give out phone contracts. I was on the back end in the IT team. Then I moved into release management, then software, then cloud, then architecture, then DevOps. Right?

[00:02:43]I've done the whole software development life cycle now. And because of that, I now have opportunities for any tech, Rob, and that's allowed me to build my own companies. Sure, you start somewhere, right? It doesn't really matter where, but you need to be active and changing every 18 months or so. By that point, you've done enough in that role, right? A lot of people make the mistake of sitting in the same role for 5, 10, 20 years in the same job and then they're like, "Well, I've been laid off.

[00:03:09]What's going on?" Yes, that's because you've not been keeping up with technology and not becoming a well-rounded engineer. So, you need to move internally or externally. It really doesn't matter. Who does your company serve? What products do you sell? What's the revenue model? Most engineers have no idea. They just do their task and then they go home. But when you understand the business, you build domain expertise. And domain expertise is what makes you irreplaceable and lets you move between industries. I've worked in telecom, defense, healthcare, government, food and beverages, fintech, energy. Basically, all of the industries that you can think of. The only difference between them is some compliance and some different internal processes. Fundamentally, all the technology is still the same. AWS, Terraform, CI/CD. But the domain knowledge is what allows you to progress because you are thinking in terms of business impact and not just technology.

[00:04:01]Now I realized very early on that everyone was moving into cloud and digital. So I moved into the digital team at Vodafone. You need to have your ears on the ground. What are the core projects that people are talking about in your business? Which ones have senior leadership backing them? Which ones have real budget behind them? Because if you work on those projects and you deliver, you are highly highly visible. It raises your reputation across the entire company. I worked on the UK digital transformation on AWS, right? I had a direct line to the directors and the CEO of Vodafone purely because they were pumping in $20 million a year into that project and I was delivering on it. That opportunity did not fall onto my lap.

[00:04:42]They literally handpicked me to come and work on it because of the reputation that I built. Be a hawk. Find a big projects and position yourself there.

[00:04:50]One of the first things my manager at Vodafone taught me is that if you're out of sight, you are out of mind. Yes, you want to work from home. Yes, you want it cushy and relaxed. But if people don't see you, they don't know what you are doing and then they forget about you.

[00:05:05]And especially in this layoff environment that we are right now, you need to be active in the calls. Turn on your camera. Be present. Speak up. Ask questions. Contribute in meetings even when you don't have to. Companies are making headcount decisions in rooms that you are not in. The only thing protecting you is whether the people in the room remember your face and your contributions. If you're hidden and not visible, you're going to get hooked.

[00:05:31]When you join a new company, you've literally got 30 days to prove your worth very quickly. When you are a new hireer, you need the quick wins. You have to overd deliver. You need to understand the team that you're on, who you're working with, what projects you're on. Make a mind map to know everyone in your circle, the stakeholders, and what you're working on together. When you start, they are looking to justify their decision in hiring you. So, all eyes are on you.

[00:05:57]First impressions do actually last. Know who the stakeholders are and what they do. Book meetings with them. Build rapport. How do you impact their roles?

[00:06:08]How do they impact yours? As soon as you deliver in those first 30 days, then you will build the trust. Then they'll leave you alone to do your best work. Make your boss look good. The reason that I was so successful in my first 5 years at Vodafone, I had a great relationship with my boss, but also with my boss's boss. That is the key. How? Well, I was active, asking questions, being someone to bounce ideas off, offering myself where I was needed, front of mind for them. They naturally liked working with me and relied on me and I made my boss look good. When she wasn't there, I was representing myself and the team in the right way. Your boss has a boss. That person makes decisions about budgets, headcounts, and who gets the interesting projects. If your boss looks good, then you look good. It's that simple. If you want to be a special snowflake and complain about your boss, then go build your own company and work for yourself.

[00:07:00]Otherwise, suck it up and get on with it. AI is a drug and most engineers don't realize they're hooked. The healthy dopamine of struggling for hours and then solving a problem gets replaced by slot machine dopamine. 20,000 lines in a day. You deploy a bunch of new shiny features, but will it work in 6 months? Do you even understand what's running? The dependency that AI tools and products build is frightening right now, and it's a cycle that becomes hard to break. You need to have nonAI days where you refuse to use AI assistance.

[00:07:30]So, you're not outsourcing your entire brain capacity to AI. I actually quit my job as a software engineer more than 6 years ago. What happened was I told the managers and the team that I need to make a switch into cloud. They said, "Well, you're on this project right now.

[00:07:44]It's going to take 3 to 6 months. We can't do that to the client, etc." Right? So, what did I do? I handed in my resignation the very next day. I quit.

[00:07:52]There is no way that I'm letting someone else dictate my career because fundamentally they do not care. All they do is care about themselves. That's the truth. What happens typically is 3 to 6 months pass by, they hope that you forgot about your goals and ambitions and they just keep kicking the can down the road because all they want is you doing your job in your place following instructions until you're no longer needed. If you don't believe me, ask your boss for a pay rise tomorrow and let me know how it goes. When I first started, I was completely oblivious to office politics. I didn't understand that it was even happening. The dynamics, the relationships, the games people would play in the corporate world. That's just the reality. If you want to move up the corporate ladder, senior leadership, director, partner, you have to be good with people, relationships, building trust, and managing expectations. I did this later on in my career. But when you are new, you don't even notice that this is happening because you're so locked in on getting better and building your presence. And that's totally fine at the start, but at some point, you have to lift your head up and see the game being played around you. Because if you're not playing it, someone else is, and they're using you as their piece on the board.

[00:09:02]In tech, you can either be a manager or an IC, an individual contributor. I highly recommend being an IC. Being a manager requires you to be so good at in-house politics, managing people, dealing with all sorts of stuff that doesn't actually move the needle. You fall into the trap of being the boss.

[00:09:20]It's way better to deliver the actual work. Focus on doubling down on skills and building domain expertise because look, I did that. I now have my own consulting company and my software company, Studyc.ai. We're currently doing a fund raise for what I've built from the ground up. The IC path gives you real transferable monetizable expertise. What I did was I went really wide into software and technology engineering, right? IT operations, architecture, release management, software development, right? I learned the whole software development life cycle and then I asked myself where does all of this get deployed? What happens after the code is written? And that's when I realized I had to learn cloud engineering and devos. And at Vodafone, we were building something at the time called DAO, the digital application layer, a micros service-based application platform. By the way, this is back in the day. Now, obviously, we are all accustomed to this, but at the time, we revolutionized how Vodafone's infrastructure worked. I was able to do this because I went very wide first and then deep into cloud and AWS and then DevOps. This is why for me cloud engineering is the best skill set that anyone can acquire in 2026 because you get system design, security, architecture, devops, data, infrastructures code, right? So that's going very wide. And then you specialize for me that was cloud security and AI.

[00:10:38]The way that you communicate is actually a direct representation of the value that you provide. Engineers want technical depth. Managers want outcomes.

[00:10:45]Executives want numbers. If you're speaking to a solutions architect, you can go deep on IM and VPC design. If you're with a VP who came from product talk, delivery speed, and business impact. Most engineers speak in one single language, Python. Obviously, joking, technical, and wonder why nobody listens outside of engineering. You want to adapt your communication to your audience. It's not dumbing it down. It's about making sure that you can speak to non-technical stakeholders. I still see this in the comments in most of my videos. I'll be showcasing how projects and hands-on skills are what you need and then the first three comments will be people asking me my opinion on a specific certification. A few certifications will not get you a six-figure role. People on the internet are telling you that you can get the Security Plus certification and employers will be desperate to hire you.

[00:11:34]Wake up buddy. The market does not care how many exams that you've passed. It cares about whether you can actually do the job. It's never been easier to get hired and nobody's doing the work. I listed three roles on LinkedIn recently.

[00:11:48]Hundreds of applicants the listing said to send a 1 minute Loom video covering your experience. Out of maybe 100 people, two did it. Everyone else just clicked send a CV and didn't even look at those requirements. And nor did I look at their CV. If you can't read the instructions on a job listing, why would I trust you with a production environment? The bar is on the floor.

[00:12:09]There's actually a role in sales called SDR, sales development representative.

[00:12:13]Their entire job is to generate leads for a business. When you are job hunting, take off the engineer hat, put on the SDR hat. Find companies that need your help, that need your solution, because my friends, you are the solution. Send off job applications and then find the hiring manager on LinkedIn and send them a Loom video. One minute face on camera, CV on screen, walk through your experience. That's how you get callbacks. Most cloud engineer CVS read like a shopping list. AWS, Terraform, Docker, Kubernetes, Python, Linux. Great. So does everyone else's.

[00:12:46]What makes yours different? Your CV should tell the story of the problems that you've solved and the business impact of solving them. Not I can use Terraform. It's I designed and implemented a multi-account infrastructures code strategy that reduced deployment time by 80% across 12 teams. Same skills, completely different positioning. One of the best bits of advice that I ever received was that software is only valuable in front of customers. Not on your local machine, not in development, not sitting in a branch waiting for someone to approve it. The only ROI on what companies spend on engineers is when something is live being used generating feedback or revenue. At Vodafone, the old IT teams deployed once a quarter. 15 teams, one weekend, a massive spreadsheet deploying three months of work overnight, Saturday night into Sunday. one by one through a massive list. Imagine waiting three months to deploy AI features that are ready today. Let that sink in. When I was working for the government in the UK consulting for them, we had multiple consultancy companies on the same project. One on solution, one on architecture, one on build, one on operations. And I was getting offers from the other consulting companies that I was working alongside, direct competitors. But it didn't matter to them. Companies are always taking each other's talent. You just have to get so good that they'd be so stupid not to bo you. A common misconception is that AI makes you a better engineer. It doesn't.

[00:14:12]It's a force multiplier. It just makes you more of what you already are. If your fundamentals are solid and you understand what's happening under the hood, AI turns you into a machine.

[00:14:23]Pardon the pun. You're solving problems faster, automating more, learning quicker. But if your foundations are weak, AI helps you make bigger mistakes at a faster rate. bad configurations, security holes, broken infrastructure, all shipped to production before anyone catches it because you didn't know what to look for. The balance that nobody's getting right. Learn the fundamentals first, then use AI to multiply them.

[00:14:47]Stop counting certifications. Stop counting Udemy courses completed. That's not progress. Progress is measured in problems that you can solve today that you couldn't solve 30 days ago. Can you design a multi- account ads landing zone now when you couldn't last month? That is progress. Can you troubleshoot an IM permission boundary issue that would have stomped you 6 weeks ago? That is progress. Can you walk into a meeting and explain the security implications of a design decision when previously you would have stayed quiet? That is progress. Everything else is just passive consumption. People ask me, are companies following best practices, clean architectures? The truth is almost never. Most environments in production are very messy. I've audited companies with root access keys hardcoded into Lambda functions, S3 buckets wide open that nobody knew about. I am policies that haven't been reviewed since the account was created. And that's your opportunity. If every environment was clean, then they wouldn't need to hire you. The real skill is walking into chaos and saying, "Here's what's wrong.

[00:15:47]Here's what we fix first, and here is why." Don't wait for a perfect environment. You have to go and build it. Every company has a small group of people doing the vast majority of what matters. I call them the wizards. Find them, study their code, their PRs, how they approach problems. But be very careful. In bigger companies, you get internal influencers, big ideas people with great reputations for starting things. But when you look at what they've actually built, not very much.

[00:16:14]All talk and no action. Make sure you're learning from someone who does the real work, not someone who talks about doing the work. There are wizards at every single company who are absolutely crucial and most of the organizations don't even know their name. Those are the ones that you want to learn from.

[00:16:30]When you are new, no task is too small.

[00:16:33]You have to build trust faster than anything else. But there is a trap. If you're always the person volunteering for everything that becomes the expectation and suddenly you're buried in grunt work with no time for the projects that actually matter. Build what I call social capital first by being helpful and reliable. Then spend that capital on getting the work that moves your career forward. Be useful without becoming the person everyone dumps their most boring work on. Most people get it wrong in one direction or the other. Some of you watching this are slaves to the tech community, hunting the meta to the meta to the meta, right?

[00:17:08]New programming languages drops, they switch. New framework launches, they restart. New tool gets attention on Twitter and then they pivot. And then they end up with five things that they don't even know very well. So they are useless at all of them, right? Go wide first as I said and then you need to go deep and specialize in one area so you can solve problems that nobody else on the team can. Everything becomes boring at a certain point and the moment that you're bored, the grass looks greener.

[00:17:35]But that new thing, that new opportunity, that new whatever it is gets boring in 6 months, too. And then you're back to the beginning. You have to become the person who pushes through the boring middle. Consistency doesn't look impressive. It only looks impressive in the results years later.

[00:17:51]You are the product. You need to market yourself within the business and to everyone else. People need to know what you are doing, where you're impacting things. Write about it. Talk about it in meetings. Document your wins. If nobody knows what you've done as far as the company is concerned, it didn't happen.

[00:18:10]Visibility inside the company is just as important as visibility outside it. In 2026, it's no longer about who you know.

[00:18:18]It's about who knows you. Get something in front of customers and users as fast as possible and then make it great later. That's my ethos for my software company stay.ai and it runs on that ethos. I can tell my team, can we get a small part of the bigger feature out, get it to customers, get feedback, and then iterate as fast as possible. I've seen teams and engineers spend 6 months building something in isolation only to find out customers didn't really want it. Ship it ugly. Let the market tell you what to fix first. Everything that you are today is just a sum of all the decisions that you've made up until this point. Your career, your salary, your skills, your health, your relationships, all of it. The results of thousands of decisions and choices stacked on top of each other. Which means that if you want to get somewhere different, you have to start making different decisions. And there is no hack. There is no magic moment where everything clicks. It's just decisions. every single day compounding over time. You want to become a cloud engineer? Then vote for that life. Vote with your time. Vote with your energy. Vote with the sacrifices that you're willing to make.

[00:19:25]Your calendar shows you what you actually prioritize. Your spending shows you what you actually value. Your actions show you what you're becoming.

[00:19:34]Make sure that those things match the life that you say you want. Companies are implementing AI as fast as possible.

[00:19:42]rushing to production, rushing to demonstrate their value because of shareholder pressure. Are they thinking about security? Absolutely not.

[00:19:49]Employees are already pasting customer data into catcht on their company laptops, uploading internal documents to public AI tools, sending proprietary code to AI systems with no controls and nobody in leadership even knows that this is happening. The wave of AI security incidents is on the horizon.

[00:20:06]The people who already understand cloud security and AI infrastructure will be in an absolutely strong position. Early in your career, don't job hop. Stay in the same company for at least 3 to 5 years. I did 5 years of Vodivo, but I had four different roles. That's what made it work. DevOps, cloud, IT operations, software, leading whole engineering teams in my early 20s.

[00:20:28]Technically, they were completely different roles, but all under one single roof. And that gave me the platform to go to any company that I wanted afterwards. Build the skills, get the experience. Your skill set will pay you in the future. It won't pay you today. You won't be rightly compensated early on. But every skill that you stack compounds into leverage later on. The money is a byproduct of the skills that you build today. Nobody is reviewing 10,000 lines of AI generated code a day.

[00:20:58]They are lying for clouds over VC money.

[00:21:00]realistically review more than about 150 lines at once and actually understand what's happening. Beyond that, the context slips and when it breaks, and it definitely will, you have no idea where to start because you didn't write it and you didn't read it. The AI company owns your product. Your only path forward is spending more money with them. The craziest trade-off in modern engineering, right? You went from being an independent engineer who could build anything with your own hands, your own brain, to being completely dependent on a subscription that can change pricing, change capabilities, or even get discontinued. And you have zero control over any of it. If you want to teach a monkey how to do something, you have to give them the reward immediately. The longer the delay, the less trainable that they are. The sign of intelligence is expanding that window. You can do the work today and trust that the reward is coming, even if it's months or years away. Most people can't make that trade.

[00:21:55]They want the result now. They want the six figure salary before they built the skills to earn it. They want the job offer before they've built the portfolio. They want the shortcut before they've done the reps. Your ability to delay gratification is probably the single biggest indicator and predictor of where you'll end up. If you can stack 3 years of unglamorous work and trust that it compounds, you'll outperform everyone who needed the dopamine hit today. Follow your passion is nice advice from people who already have the money and they've made it. What actually works is finding what you're good at that companies are willing to pay for.

[00:22:30]Passion usually comes from competence and not the other way around. I wasn't born passionate about AI and cloud security. I started because I saw the demand. I saw the talent gap and I positioned myself right there. The passion came after I got really good at what I do and companies were paying me big money for. If I waited to feel passionate before starting, I'd still be waiting today. Start with the market need. The passion always catches up.

[00:22:56]Analysis paralysis have cost more careers than wrong decisions ever have.

[00:22:59]I've met people who spent 2 years deciding whether to learn AWS or Azure.

[00:23:04]2 years. Both platforms have evolved.

[00:23:06]opportunities came and went and they're still asking for advice. You want to learn cloud? Go and do it. AI, go and do it. Cyber security, go and do it. You can't analyze the steps to your success in your head because you don't have the full context of what will happen when you take each step. Instead, once you take the first step and then the second step and then the first step, that's when things start to click in place.

[00:23:30]Pick something and start because the longer that you wait, the longer that you stay stuck. For the first 2 to 3 years of your career in tech, it feels like nothing is happening. You are learning but you're not really earning, building but not getting recognized. You start questioning if you've picked the wrong path. You start wondering if you are at the wrong company. But somewhere around year four or year five things start to click. While year 7 or year 8 is compounding so fast that you can barely keep up. But you have to go through the invisible years first. It takes a decade to become an overnight success. Your ability to navigate social dynamics inside of a company is just as important as your technical ability, maybe even more. Who does what, who has influence. It's about being aware. The cloud engineer who gets the best projects isn't always the most technically skilled. It's the one people want to work with, the one that leadership thinks about first. So remember details about your colleagues.

[00:24:26]Follow up on things they mentioned. Be the person that makes a team better by being in the room. If you respond to everyone with one-word answers on Slack, it's shocking how fast people stop wanting to work with you. Technical skills get you in a door. Social capital determines how high your ceiling goes.

[00:24:43]When Elon Musk took over Twitter in 2022, he fired roughly 80% of the workforce. Everyone predicted that the platform would collapse. It didn't. And I think every CEO in Silicon Valley watched that and thought we could do something similar. And the truth is most people actually do nothing. That's the reality. We've all seen the day in the life Tik Toks. People working two hours a day and collecting a full six figure salary. The companies copying the Twitter playbook aren't wrong that there's fat to cut. They're just using AI as the excuse. So if you want to be layoff proof, be the person in 20% that actually does the work. Because when the layoffs hit, the first people to go are the 80% who are coasting. And hey, if you did the work and you got laid off, then you still won because now you can go to a new employer with all of these skills that you've acquired. It's simply a winwin. When you've got an interview, the names are in a calendar invite. Go search those people. What's their role?

[00:25:41]Technical or non-technical. You never walk into an interview completely blind.

[00:25:45]Typically, you'll speak to a recruiter first, then a technical interview, then it'll be with the hiring manager, and then maybe the wider team, right?

[00:25:52]Architect, engineer, product. know who you're talking to at each stage and then adjust your language accordingly. And nobody does this, but bring a 5-minute presentation that you can say, "Hey, let me show you the project that I built."

[00:26:04]Walk through your architecture diagram, explain your decisions. Not only are you thinking outside a box, but now you're presenting and demonstrating your ability, your communication skills.

[00:26:14]Nobody does this in technical interviews. They just talk about what happened. Show and don't tell, so you instantly stand out. build projects that solve real problems. I used to go on Upwork not to freelance but to research.

[00:26:27]I'll look at what problems companies were posting for DevOps roles, Kubernetes issues, infrastructure challenges. Then I would take those briefs and I'll build those projects myself and put them into my portfolio.

[00:26:37]Because if companies are paying for those problems to be solved, someone will pay me to solve them too and document them in the right way. Not just what you did, but why you did it and what was the outcome. Can we make it work? Can we ship it quickly? Can we get feedback? then go back and make it better. The longer it takes to develop something, the more it costs the business, the longer it takes to make money from it. Right? All the tools that we use at cloud engineers, CI/CD, containers, infrastructures code exist to speed things up. If you don't understand shipping velocity as a business driver, you're missing the fundamental reason that your role exists. If you are afraid to apply, afraid to make the move, afraid to put yourself out there, write it down. Not vaguely, in exceptional detail. What are you actually afraid of? I'm afraid to apply for cloud jobs. Okay, but why? I might get rejected. Okay, and then what?

[00:27:25]I feel embarrassed. And then what? I'll apply again, I guess. Right? So, the worst case is that you apply, you get rejected, you feel rubbish for a day or two, and then you try again. That's the monster under the bed. When you actually play it out step by step, you realize, wait, that's what's been stopping me this whole time. Fear only exists when it's vague. The moment that you spell it out in detail, it shrinks to almost nothing. When I quit my software engineering job at Vodafone to go all in on cloud, people had opinions. What if it doesn't work out? And I sat with that question properly. What's the actual worst case that could happen? I fail, I learn a lot, and I go back to being a software engineer for a bit, making a lot of money. I try again, right? That's not really that bad. And the outside, everything that I've built since then.

[00:28:07]The risk was never as scary as it was made out to be. You know, you should be doing it, yet most of you still are.

[00:28:13]Write about your learning. Share your projects and your GitHub repos. The people who build in public attract opportunities that people who build in isolation will never see. A lot of roles never actually make it to LinkedIn or job bots. Instead, recruiters and hiring managers will outbound to you on LinkedIn with an opportunity. Because when a hiring manager searches for a specific keyword or a title on LinkedIn and they stumble across your post and then they find a body of real work, real thinking, real experience, you get added to the short list. If they message you, you now have leverage. Build where people can see you building. I've seen beautiful overengineered architectures that a team could not operate.

[00:28:51]Microservices everywhere when a monolith would have been perfectly fine.

[00:28:54]Kubernetes when EC2 with autoscaling would have been sufficient. It's just more moving parts and more complexity that isn't required. The architecture that wins isn't the most sophisticated one. It's the one that your team can actually build, deploy, debug, and maintain when it breaks. Design for your current team's capability and needs and not for tomorrow's complexity. The job interview isn't about being right. It's about how you think. Interviewers don't expect you to know everything. They want to see how you think through problems that you might not have seen before. If you don't know the answer, do not under any circumstances say that I don't know and leave it there. Instead, say I don't know, but here is how I'd approach it.

[00:29:34]Walk through your reasoning. Explain your thought process. Make estimates and assumptions based on what you do know.

[00:29:40]Ask clarifying questions. Show your thinking. That's what they're hiring for. Every decision that you make as an engineer has trade-offs. Serverless or containers? Trade-off. Multi-reion or single region? Trade-off. Managed service or self-hosted trade-off. There is no objectively correct architecture.

[00:29:58]There is only the architecture that makes the best trade-offs for your specific constraints today. Your budget, your team size, your compliance requirements, your timeline, your risk tolerance, and the expertise in the teams. Right. Early in my career, I thought there was a right way to build things. I'd spend ages trying to find the perfect solution and I would sit in a meeting with a senior architect and they would say, "Yes, but what about the cost?" Or, "What about the team maintaining this after you leave?" Or, "What about the compliance audit in March?" And suddenly my perfect solution wasn't perfect anymore because I'd only optimized for one variable, technical elegance, and ignored everything else.

[00:30:32]That's the real skill that separates junior engineers from seniors. A junior looks for the right answer. A senior looks for the best trade-offs given the constraints and then they can articulate what they're gaining and what they're sacrificing. We're choosing serverless here because it reduces operational overhead for a team of three, but we're accepting higher per request cost and cold start latency because at our current scale, it doesn't matter. That's a trade-off stated clearly and that's what gets you hired. As you progress in your career, you will outgrow some of the people that are around you. This one's uncomfortable, but it's true.

[00:31:04]Friends who are still in the same role that they were 5 years ago. colleagues who stop learning, peers who resent you for your ambition because it highlights their stagnation. It doesn't make them bad people, it just means that you're on different trajectories. The mistake is slowing down to match their pace or worse, dimming what you're doing because it makes others comfortable. Surround yourself with people who are ahead of you, not behind you. Your circle should make you feel like you need to level up, not like you need to hold back. Every coaching program or mentorship that I've ever joined, I've told him the same thing. I will be your biggest success story. Not because of them, but because of me. Because I made the decision that I was going to extract every ounce of value from whatever that I invested in.

[00:31:44]I was going to make it worth it regardless of whether it was perfect or not. And here is what I found. I've learned just as much from bad programs as good ones. Because a lot of the time, getting good is actually the removal of the bad. When you see someone doing something terribly, you learn exactly what not to do. That's valuable, too. If you invest in yourself and you give it 100% and you double your income in a year, who's responsible? Is it the coaching program or is it you? Exactly.

[00:32:09]If you want to make more money, you have to solve bigger problems. A junior fixes config, a mid-level design systems, a senior architect defined strategy that saves the company millions. The size of problem that you can solve directly correlates to what you are worth. When I was doing IT operations at Vodafone, I was solving small problems, keeping retail sold online. When I moved to the cloud architecture, I was solving bigger problems. How do you transform the entire digital platform? When I started my consultancy, I was solving even bigger problems. Each step up in problem size was a step up in compensation. It's all about perspective. Your boss that you don't like makes you hate your job.

[00:32:45]I had managers who blocked my career progression, who promised things they never delivered, who took credit for work they didn't even do. Instead of getting angry, I used those experiences to my advantage. They taught me to document everything, to be visible online, to build relationships outside of my direct chain, to never rely on one person for my career. You could either be a glass half empty or a glass half full person, but only one of them serves you very well. We had a client of decent size, been on AWS for years. They called us because they had a production outage and when they tried to fix it, they realized that nobody in their team actually understood how the infrastructure was set up. One engineer had set up everything by clicking through the console 5 years ago. Then the company grew, more servers got added. Nobody documented any of it and then the original engineer left the company. We call this tribal knowledge loss. All of the understanding of how things work, walked out the door with the person that left. We reverse engineered the entire environment, documented everything, and rebuilt it properly with infrastructure code tools like Terraform. If you're building infrastructure by clicking around the console, you're creating this exact problem. You're building something that only exists in your head and can't be repeated, reviewed, or handed over to anyone else. Why EC2 over Lambda? Why RDS over Dynamo DB? What are the trade-offs? What if the budget got cut in half? What if the system was in a regulated industry? That's what interviewers are actually testing for, and most people can't answer any of it because tutorials taught them the how and not the why. There's a framework called the Bloom's taxonomy. Most people are learning cloud engineering, bouncing between levels one to level three forever. Memorize, understand, and apply. But what gets you hired at a six-figure level is level four and level five. Analysis and evaluation, comparing options, understanding trade-offs, decisions to business outcomes. That's what companies are paying premium rates for. It's not about knowing what the services are or how to use them. It's about building your understanding to know when and why to use them. Every wants to work smarter, right? It sounds good. is what all the productivity gurus tell you. But here is the reality. Most people aren't doing anywhere near enough the volume to even know what works. You can't optimize for what you haven't done yet. You can't shortcut your way to understanding. You have to put in the reps. You have to work harder and then you earn the right to work smarter. And here is what I've noticed about hard work specifically. If you work hard enough and become genuinely exceptional, the relationships and opportunities they will find you. You don't have to chase connections when you are the person that everyone wants to connect with. People will always want to learn from the expert. I started with nothing. Zero at the bottom of the tech chain. No connections and no pedigree. What I had was the willingness to learn and play a longer game than everyone else around me. The fundamentals from years 1 through to year 5 became the foundation for years 5 through year 11. None of it happens without those early years of deep unglamorous patient work. It took years before any of it looked like it was working. There were periods where I questioned everything, where people around me were advancing faster and I was still grinding. But compound growth is invisible early and unstoppable later. If you're in year 1 or year 2 and nothing seems to be working, that's exactly what it's supposed to feel like.

[00:35:53]If you are in year 10 or even year 20, it's not too late to start making changes today. In retrospect, the best time to start was when you started. As always, I'm rooting for you. Good luck.