Earlier this week a colleague of mine, Wesley George, shared an article he had written named Shifting the bar in the architect role on an internal Fujitsu wiki. I really liked his piece because it gave an insight into some of the personal characteristics needed to be successful in a pre-sales technical role. He was specifically referring to the Solutions Architect positions that many people find somewhat mysterious. Today I hope to demystify the function of these people a little. Architects are usually found on the product/service vendor or consultant side of the fence but this is not a rigid requirement and architects can actually frequently be found in organizations that primarily consume instead of sell IT as well.
The role at times may appear glamorous, which it can be, but like most things it has its fair share of tedium and rigour included into the mix. People in these jobs are expected to have a deep technical knowledge and are required to be collaborative across a broad spectrum of job functions, technologies and products to deliver positive results. However, in most instances the joy of bringing these results to life is done by the field engineers implementing on the ground and not the solutions lead. Unfortunately, like architects of all types most of your time will be spent writing documents, drawing, making presentations and smiling in meetings. You may be hardcore to the bone but once you step into the solutions seat you will very rarely get to pull the trigger even though you chose the bullet.
So, still think this role is for you? Are you ready to move from problem identification and requirements discovery to blueprint specification? Well let's hear what that feels like from someone who is living in that space.
As a Solutions Architect, what you are really doing, is being the manager of your own service company.
What you are selling, is basically your own services. The fact that your pay check is being signed by someone else doesn't/shouldn't really matter. However, the focus of the solution provider is a motivation to resolve a pain point the customer is experiencing.
The customer is building a relationship with you, as much as the company you are working for. Therefore, it is critical to know the stakeholder’s degree of influence and power, and their interests in the results that you are seeking to drive. Moreover, customers are interested in solutions and services that result in
measurable outcomes and are looking to benefit from new, more flexible consumption models.
On top of that, you are continually networking and always building a rapport with current and potential clients around the world. Every solution delivered can either enhance your reputation or detract from it. So, in my opinion, I would rather leave the customer with a good solution, rather than having sales tweak their budgets just to get the contract. It seems to suggest that the bar for an architect should therefore be shifted from product sales to outcome sales where the driver is about the value of the outcomes.
So what can you do to create the outcome that is beneficial for all parties concerned (The customer, your
employer and yourself)?
Well, what I am learning to do, is try to emphasize the importance of leaving the customer with the right
solution based on their requirements and constraints. This discussion should involve both the technical side of things, as well as any client executive(s)/sales people involved. Try to focus on the long term results, such as customer satisfaction and reoccurring sales. This is the outcome driven trusted advisor role whereby the customer knows their end goal, or at least how this would be visible.
As it relates to the customer, do your best to explain why solution A is better than B, because of the requirements fit that are in place. Most stakeholders are sensible enough that, if you just take your time to explain the solution and have your reasoning in place, they will understand. Both of these (explaining and reasoning), are important for you to build the before mentioned rapport with the customer.
In the end, you should end up with a customer that will ask you for advice when in need, and trust your judgement when you recommend a solution. By doing this you effectively put the “fluff” from the client executive(s) aside and focus on the important work and measurable outcomes.
As engineers/architects, we tend to focus on the technical side of a solution, but to be successful in our role(s), we also need to pay attention to the relational construct. Given the fact that outcome sales require us as professionals to adopt a holistic perspective to the customer's business. Furthermore, building
long-term relationships with stakeholders establishes credibility and customer loyalty.
-Wesley George
Adopting the outcome sales philosophy demands a change in mindset that transcends the pursuit of the purely technical endeavour or the solely revenue driven motive. Make this an ongoing personal initiative and constantly refresh yourself about your primary purpose as a solution provider. Remember to be cognizant of this the next time you engage a client.
And in case you still don't understand what the outcome process means it is about:
-
Being a team-player, but knowing you are the one who has to talk with the customer routinely.
-
Doing your best to understand the customer and his/her requirements and business objectives.
-
Taking your time to explain your solution to the customer.
-
Never taking the customer for granted.
-
Paying attention to the social/human aspect when engaging with both the customer and your co-workers
Nneko Branche.