From Engineer to Principal Solutions Architect at AWS with Prasad Rao
- Gregor Ojstersek and Prasad Rao from Engineering Leadership <gregorojstersek@substack.com>
- Hidden Recipient <hidden@emailshot.io>
From Engineer to Principal Solutions Architect at AWS with Prasad RaoOne particular role helped him get many crucial skills that you normally don't get in typical engineering roles!
Ship Software Faster with Experienced Engineers (Sponsored)Finding skilled developers is hard → even for seasoned engineering leaders. Traditional hiring cycles can take months while critical features sit in the backlog. Lemon.io removes the guesswork by rigorously vetting engineers and matching you with top talent in just 48 hours. Need to scale your team quickly or find specialized talent that's hard to source locally? They match you with developers from Europe and Latin America who integrate seamlessly into your workflow → without the long hiring cycles or commitment of long-term contracts. They don't just check résumés, but put developers through a rigorous multi-step vetting process that assesses technical skills, problem-solving abilities, and communication. Let’s get back to this week’s thought! IntroWhen we talk about career paths, all of our journeys are unique. There is no one single best path that works for all of us. It’s important that you find out what path you wish to pursue and work towards it. And to help you with this, we have Prasad Rao, Principal Solutions Architect at AWS today with us. He is sharing his journey from engineer all the way to Principal Solutions Architect. Prasad has chosen the Architecture path and I can see why very clearly. He grew as an engineer early on but later moved to the role of a Pre-sales Engineer, which helped him with speaking in both business and technical terms, creating presentations, understanding clients and managing multiple stakeholders. That particular set of skills is often hard to get from engineering roles alone, but it plays a crucial part in an Architect positions. Now, let’s get into his journey, Prasad, over to you! Don’t overlook alternative career pathsWhen engineers think about career growth, they often focus on two traditional paths: either advancing as an Individual Contributor (climbing from Senior to Staff Engineer and beyond) or transitioning into Engineering Management. However, there are other powerful career paths that are sometimes overlooked. In this article, I am sharing my journey of transitioning from an engineer to a Solutions Architect at AWS, offering insights into this alternative career trajectory. Early years as an EngineerMy career began as a .NET Developer, where I gradually progressed to become a Senior Developer and then a Tech Lead. The year I graduated, I interviewed for a couple of Big Tech companies but never got beyond the initial coding rounds. I thought I wasn't made for Big Tech and made peace with it. After a few initial job switches, I settled into a consulting company and started climbing the ladder. Unlike many others who choose the management track, I wanted to grow as an Individual Contributor (IC). However, many companies do not have a clearly defined IC growth path. The natural progression is to become a manager. I was looking for alternative opportunities. Even though I was working for a consulting company, I was in a unique position as I was working on building a product for a financial services company. When the product was ready, they needed someone in the field to demo it to potential clients. I took the role, and that opened a whole new world of possibilities for me. That's when I was first introduced to pre-sales activities. Instead of being an engineer on the product team, I would be part of the field team as a pre-sales engineer.
Growing as a Pre-sales EngineerFrankly, before I started, I didn't know if such a role existed. As with any new role, there were pros and cons of being a pre-sales engineer. The pros were that I would be working more closely with customers onsite and traveling the world. The cons were that I would work on activities sometimes frowned upon by engineers - stakeholder management, customer interactions, gathering requirements, creating sales presentations, etc. Frankly, it was stepping out of my comfort zone, but it helped me develop skills that I never knew would be so important in my career growth. After a couple of years in this role working with multiple customers, I understood the importance of understanding customers' requirements and working backward to achieve them. Being an engineer, I had mostly focused on completing the tasks assigned to me. I never focused on understanding the real business reasons behind the tasks. Other skills I learned in this role:
Growing as an ArchitectAfter a few years in the role of Pre-sales engineer, I got an opportunity to consult as a Senior Engineer/Tech Lead for a financial services customer on a digital transformation project. With improved business acumen and communication skills, I quickly became the go-to person for the customer. It was a development project, but my focus shifted to understanding the bigger picture. As developers, we design and architect components, so we're already doing architecture work without realizing it. A key to transitioning to an architect role is viewing these individual components and systems through a wider lens. To grow as an architect, you need to learn system design, distributed systems, and integration patterns. You also need to develop the mindset of considering scalability, performance, security, cost, and other factors. But those are technical skills that are relatively easy to pick up. The important thing to develop as an architect is perspective - while developers often focus deeply on specific components, architects maintain a holistic view of the entire system. For that, understanding the business requirements is essential. A pivotal insight that helped my transition was understanding that architects are essentially developers who view systems through a wider lens. The main difference is scale and perspective - while developers often focus deeply on specific components, architects need to maintain a holistic view of the entire system. In architecture, there is nothing defined as right or wrong - it's always a trade-off. There is a reason architects start their answers with "It depends." It depends on the requirements. It depends on what you would like to achieve. It depends on what constraints you're working with. Every architectural decision involves balancing multiple factors: scalability versus simplicity, performance versus maintainability, time-to-market versus perfect technical design, or cost versus capability. Lastly, to grow as an architect, it is also important to develop a broad understanding of multiple technologies. This enables you to make informed decisions about choosing the right tools for specific problems.
Cracking the Solutions Architect role at AWSWith 10+ years in the industry, I had gained enough experience in different roles - developer, tech lead, pre-sales engineer, and architect. I was looking for a new job when one of my seniors suggested I try for AWS. I was reluctant, thinking that I would have to go through coding exercises. I was pretty hands-on, but solving LeetCode was not my cup of tea. To my surprise, I learned that coding rounds happen only for SDE roles. So if you are a naive person like me thinking that jobs at Big Tech are out of reach because of coding rounds, then please explore other roles. I browsed through multiple roles to find one that matched my profile - 'Solutions Architect, Microsoft Developer Tools on AWS'. The job role mentioned experience required with .NET and Microsoft workload stack. In the role, I had to help customers migrate and modernize their Microsoft workloads on AWS. My decade-long career was all in Microsoft technologies, but I had zero experience with AWS. I was pretty candid about that in my call with the recruiter, and still my profile got shortlisted. The entire interview process (8 rounds) was completely based on my experience and my learning ability with new technologies. No coding round whatsoever. I'm not saying the interviews were easy or that I did not have to prepare. It took a lot of hard work to prepare for the interviews, but the diverse experience I had gained helped me position myself as a good fit for a Solutions Architect role, which requires both technical and consulting skills.
The role of a Solutions ArchitectHaving spent 5 years in the Solutions Architect (SA) role at AWS and being promoted to Principal SA has given me enough insights into what is required to become a successful SA. Ask any experienced SA about what their day-to-day role looks like, and they would answer, "Every day is different." And that's true. Let me give you a glimpse of the different hats an SA wears in their role. It will not only help you understand what a typical day of an SA looks like but also the skills you should be developing if you aspire to become an SA.
So, one day I might spend a full day in whiteboarding sessions with customers, understanding their requirements and coming up with solutions using different AWS services. Another day might find me glued to my computer, creating a proof of concept to showcase the capabilities of AWS services. Then there might be days when I speak at conferences, evangelizing AWS services. Or I might spend a full day conducting workshops and training sessions to upskill customers on AWS.
Become a Solution ArchitectI along with few other Amazonians, co-founded a FREE mentoring initiative called BeSA (Become a Solutions Architect). The 8-week program focuses on technical and behavioural skills to help you excel in your cloud career.
Watch launch video for full agenda of the upcoming cohort, and if it interests you, register at besaprogram.com! Last wordsSpecial thanks to Prasad for sharing his journey and insights with us! Make sure to follow him on LinkedIn and check out his newsletter Big Tech Careers, where he regularly shares tips on how to pass Big Tech interviews. We are not over yet! 2 more things. WriteEdgeMy friends Jordan Cutler and Sidwyn Koh have launched their product called WriteEdge. It turns your rough ideas into polished design docs. It saves you time by handling the structure, tuning to audiences, and considerations for you. Here is a quick Demo: Engineering Leadership community on XThere is a free community on X, it’s called Engineering Leadership → A 100% community-led and started by Mahdi. I really like the discussions on Engineering Leadership topics being held there. If you are someone looking to have discussions with like-minded people → More than 468 people are already there! Liked this article? Make sure to 💙 click the like button. Feedback or addition? Make sure to 💬 comment. Know someone that would find this helpful? Make sure to 🔁 share this post. Whenever you are ready, here is how I can help you further
Get in touchYou can find me on LinkedIn, X, Bluesky, Instagram or Threads. If you wish to make a request on particular topic you would like to read, you can send me an email to info@gregorojstersek.com. This newsletter is funded by paid subscriptions from readers like yourself. If you aren’t already, consider becoming a paid subscriber to receive the full experience! You are more than welcome to find whatever interests you here and try it out in your particular case. Let me know how it went! Topics are normally about all things engineering related, leadership, management, developing scalable products, building teams etc. You're currently a free subscriber to Engineering Leadership. For the full experience, upgrade your subscription. |
Similar newsletters
There are other similar shared emails that you might be interested in: