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!

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