Applying for a Solutions Architect role? Consider this question first

You are considering applying for a Solutions Architect (SA) role, perhaps at a public cloud provider. Is it the right choice for you? Are you going to be happy and successful? In this article, I share a key question that you should consider before applying. That question is...

Do I have a T-shaped or Pi-shaped (π) expertise profile?

There are certainly more questions to consider, and I list some of them at the end of this post. Still, having spent over a decade in Solutions Architecture roles, I personally consider this as one of the most important predictors of success. But before I explain what I mean by T-shaped and Pi-shaped expertise profiles, I should lay down some fundamentals about the generalist Solutions Architect role.

Some fundamentals about the Solutions Architect role

First, there is no universally accepted definition for the SA role. Almost every company has its own definition(s) of the role. Yes, it is not unusual to have several definitions within a company. For example, an SA role in a sales organization is different than an SA role in a professional services organization. Let's quickly get a feel of how different they are.

In a sales org, the SA is responsible for building a healthy long-term technical relationship with customer stakeholders of all roles and backgrounds. The SA is responsible for guiding the customer from "We have a need. What do you offer?" to "We are confident and ready to use your products." To accomplish that, the SA has to execute numerous activities. These include understanding the customer needs and constraints, matching the right products to those needs, leading product demos, building solution prototypes, helping with solution scoping and pricing, navigating customer business and technical constraints, and more.

In a professional services org, the SA is often in charge of leading the customer from "We have a solution prototype." to "We successfully launched the solution in production." This usually happens through a project with well-defined budget, scope, and timeline. The SA leads the project from a technical standpoint, sometimes acting as a peer to the project manager. The SA also often leads a multi-disciplinary team that is assembled to build and deliver the solution. The team may comprise application developers and testers, product specialists, infrastructure specialists (storage, networking, compute, etc.), and so on.  The SA also acts as the project's technical point of contact for the customer.

The common thread across Solution Architect roles

The roles look quite different at a distance. But, there's an important common thread. Both flavors of the role require technical leadership. To be an effective generalist technical leader, the SA has to be trusted by her customers and her teammates. To be trusted, she has to be credible. A T/Pi expertise profile is the backbone of technical credibility. The relationship between trust and credibility is discussed in the book: The Trusted Advisor Fieldbook: A Comprehensive Toolkit for Leading with Trust.

A T/Pi-shaped expertise profile means having both deep theoretical knowledge and practical skills in one or two technology domains (Technical Depth). It also means having enough familiarity with a few other domains (Technical Breadth). These domains include application development, databases, networking, security, containers, analytics, storage, machine learning, IoT, and more. But what do I mean by the terms "deep" and "enough familiarity"? Let me try to quantify those terms a bit more.

How can we quantify Technical Depth?

One model I found helpful for quantifying both tech depth and breadth is the Dreyfus model of skill acquisition. It is nicely explained in this blog post as well as in the book Pragmatic Thinking and Learning: Refactor Your Wetware. Using the Dreyfus model, we may consider someone to have depth in a tech domain if they had reached either the Competent or the Expert stage.

That usually happens after years of purposeful practice in your domain across many projects or engagements. In a nutshell, purposeful practice is where you practice with well-defined improvement goals, constantly push yourself beyond your comfort zone, and receive continuous useful feedback on your performance. Purposeful practice, and its better cousin, deliberate practice, are treated in more depth in the book Peak: Secrets from the New Science of Expertise.

As a Solutions Architect, you will naturally have credibility in your primary domains. These are the domains where you have most of your experience, education, and training. More importantly, they are the domains where you likely have made most of your career achievements.

As a side note, writing down your career achievements is an investment of time and effort that pays dividends. It's a topic important enough that I dedicated a lengthy post to it. Feel free to take a look here.

How can we quantify Technical Breadth?

Continuing our use of the Dreyfus model, we may consider technical breadth as acquiring essential knowledge and skills in at least 2-3 domains and making it to the Advanced Beginner stage. At this stage, I would argue that you have "just enough" theoretical knowledge and experience to be effective as a Solutions Architect. Let's see an example.

Suppose you are building an application that uses a relational database. Application development is your area of expertise. But, you know little about databases. You encounter a performance issue while testing your application and determine the root cause to be related to the database. You have some basic understanding of databases but still not enough to troubleshoot. You decide to roll up your sleeves and solve the problem yourself. You pick up a book or search up some articles on database troubleshooting and start reading. Through this activity alone, you get exposed to a whole new set of concepts. You get to understand how the database engine executes your SQL queries by using the 'explain plan' capability of your RDBMS. You learn about query optimizers. You learn how to read and interpret table statistics. You understand what indexes are and when and how to use them. By the end of the troubleshooting activity, you had acquired a new skill: database query performance tuning. This process may repeat while solving another problem or accomplishing another database-related task. You acquire more skills in the databases domain.

You are still not an expert in databases by any stretch. But, and this is critical, you now know enough about databases to start being credible as a Solutions Architect. First, you're able to dive deeper into database-related topics and learn and accomplish more, if necessary. Second, you're able to converse on databases to a reasonable depth with others (e.g. customers), including domain experts. Finally, you become familiar with the common needs and problems people have with databases, and how different products solve them.

Imagine this entire process repeating over your career in other domains such as networking, storage, and cloud computing. You end up acquiring enough essential expertise in these domains, leading to the T- or Pi-shaped expertise profile, roughly illustrated below.

Why is a T/Pi-shaped expertise profile relevant for SA roles in cloud providers?

Public cloud providers strive to enable customers to deploy any kind of workload in the cloud. That means that they aim to offer products that cover virtually every conceivable IT need. Case in point, AWS offers 200+ services at the time of writing this post.

As a generalist SA, you need to develop enough knowledge of these products to become credible. But with such vast cloud product portfolios, this is no easy feat. That is when a T/Pi-shaped expertise profile becomes advantageous. You already are an Advanced Beginner in 2-3 domains, and Competent/Expert in 1-2 domains. Even though there is still a learning curve to overcome, you are likely to be able to build on what you already know and adapt your existing skills faster.

Conclusion

The question I shared here is just the beginning of your decision-making journey. Here are a few more questions you may want to think about.

• Am I looking for a pre-sales role or a delivery role? Some Solutions Architect roles are pre-sales roles, with hands-on work limited to demos and prototypes. Other roles are professional services roles, such as cloud architect.
• Am I comfortable doing customer-facing activities? The SA role is typically a customer-facing role, be it an internal or an external customer.
• Do I enjoy building (and taking apart) things? There are situations where you need to build a prototype or a proof-of-concepts yourself.
• Am I willing to commit to continuously learn? Public cloud providers innovate at a rapid pace. Existing products will keep changing, and new products will pop up all the time.
• Do I enjoy teaching or guiding others? This is a significant part of the role and you do it both for customers and for colleagues.

I hope you found this post useful. If you have feedback, feel free to leave me a message here. Thanks for reading!

Photo by Kelly Sikkema on Unsplash