From Engineer to Principal Solutions Architect at AWS with Prasad Rao
One 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!
Intro
When 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 paths
When 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 Engineer
My 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.
Pro Tip: Don’t shy away from exploring lateral roles when an opportunity arises. Career growth is never linear.
Growing as a Pre-sales Engineer
Frankly, 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:
Speaking both business and technical languages
Creating stellar technical presentations and product demonstrations
Understanding prospective clients' business needs and designing customized solutions
Collaborating with multiple stakeholders like sales representatives, client executives, business analysts, and product teams
Pro Tip: Spend time with your business stakeholders to understand the WHY behind the tasks you do on a daily basis.
Growing as an Architect
After 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.
As Gregor Hohpe explains in his talk "Thinking Like an Architect" architects see more dimensions than other people do. Some people see it as a circle and others see it as a rectangle, and all of them are right in their own perspective. Architects, having a holistic view, should be able to see it as a three-dimensional cylindrical figure.
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.
Pro Tip: Shift your focus to look at the big picture and have a holistic view. Architects learn to navigate the ambiguity in requirements and constraints.
Cracking the Solutions Architect role at AWS
With 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.
Pro Tip: Don't let coding interviews discourage you from applying at MAANG+ companies. Explore jobs other than SDE roles and you'll be surprised at how different the interview processes are.
The role of a Solutions Architect
Having 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.
Solutions Architects function as architectural experts by creating reference architectures, designing new architectural patterns, and developing methodologies that establish standardized approaches for solving complex technical challenges.
Solutions Architects serve as technical advisors by analyzing complex business requirements and recommending the most effective technological solutions to meet organizational goals and overcome technical challenges.
Solutions Architects serve as technical demonstrators by building proof of concepts and prototypes that validate proposed solutions, showcase technology capabilities, and provide tangible evidence of how specific technologies can effectively address customer challenges and business requirements.
Solutions Architects act as customer advocates by deeply understanding client needs, representing their interests throughout the implementation process, and providing the required feedback to the product teams for enhancing the products and features.
Solutions Architects function as technical trainers by sharing technical knowledge with teams, conducting training sessions, and helping stakeholders understand the implications and benefits of different architectural decisions.
Solutions Architects act as technology evangelists by promoting innovative solutions, speaking at conferences, sharing success stories and best practices, and inspiring the organization to embrace new technologies and architectural approaches that drive business value.
Solutions Architects serve as strategic planners by developing comprehensive technical roadmaps, evaluating emerging technologies, and ensuring solutions are scalable and future-proof to support long-term business growth.
Solutions Architects work as cross-functional collaborators by bridging the gap between business and technical teams, customers and product teams, facilitating communication between stakeholders and aligning diverse groups.
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.
Pro Tip: As every customer is different and every customer problem is unique, so is each day of a Solutions Architect. And that's what I like about the SA role.
Become a Solution Architect
I 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.
The next cohort starts on February 15, 2025, with sessions live streamed on the BeSA YouTube channel every Saturday at 3 PM GMT. Topics covered in the upcoming cohort:
Technical Track: AWS GenAI immersive hands-on workshops
Behavioural Track: Cracking the Solutions Architect Interview at AWS
Watch launch video for full agenda of the upcoming cohort, and if it interests you, register at besaprogram.com!
Last words
Special thanks to Prasad for sharing his journey and insights with us! Make sure to follow him on LinkedIn and check out his newsletter
, where he regularly shares tips on how to pass Big Tech interviews.We are not over yet! 2 more things.
WriteEdge
My friends
and 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 X
There 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
Join the Cohort course Senior Engineer to Lead: Grow and thrive in the role here.
Interested in sponsoring this newsletter? Check the sponsorship options here.
Take a look at the cool swag in the Engineering Leadership Store here.
Want to work with me? You can see all the options here.
Get in touch
You 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.
 | A guest post by
|
Love this article!
I joined a product engineering team after 15 years of technical consulting for a software vendor, working directly customers and handling both project level work and product-inflicted escalations; and skills I learned during that team still benefits my daily work in many aspects. I am usually pulled into direct escalation calls with customers, as I am comfortable to handle such cases, starting with the empathy for their situation and understanding what they need (and that's most often not necessarily a technical solution, but rather the assurance, that we truly understood their problem.), followed by proper communication and status updates, and so on.
In my neighbor-teams I have a lot of ex-consultants, and I see many of them growing faster than "pure-breed" engineers; and that's not because they write better code or drive bigger projects. But because they see the struggles customers have and they influence and prioritize both directly and indirectly features and bugfixes which have a real impact to customers.
Really great article!
Transitioning between job families is not a “one-way” door. In fact, having experience in multiple functions makes you stronger in each of the functions. Especially for Solution Architects whose job is, by definition, to bridge different domains, businesses, and technologies. This build communication skills that are applicable across the board.