…and why it was worth every, sometimes difficult, second of it
Disclaimer: This is my private opinion and experience on this role and is not an official Salesforce post. I will not be sharing all aspects of the Solution Engineering / -Architecture role as it would be outside of the scope for a 10min reading time post and this should just give you an idea of my thought process.
TL;DR
I already gave the most important information away in the subtitle. Is it worth going into Solution Engineering from a more technical role like Solution- or Technical Architect? The answer is (at least for me) YES! To make this work for you however, I believe that being aware of the side effects and why some skills from your previous role may work against you in Solution Engineering are important topics I am covering in this post. Certainly a post like this would have made my time easier when I transitioned from a Salesforce Solution Architect to -Engineer ~2,5 years ago.
The Positives:
- Involved in the decision process early on
- Similar (potentially more) pay
- Likely less travel and not so many night overs
The Negatives:
- Your technical expertise may not be as relevant and can even work against you
- The project manager and your main counter part is Sales
- Nothing wrong with that but a huge difference compared to a project related role and working with like minded people who understand the technology
- Customer Success is mainly (not only) defined by Sales numbers
The Point:
It’s up to you! If you are willing to change, make a few sacrifices and get out of your comfort zone. I would argue that this is an Opportunity to become a great Solution Engineer and make your architectural skills work in your favour.
Who should read this
If you are in a Salesforce related project role e.g. Solution- or Technical Architect, Functional Consultant, Administrator, Business Analyst, Developer etc. and you are interested into Salesforce Solution Engineering, I think you can benefit from this post. I am sure I would have if someone understood where I was coming from and where I wanted to go. If this post encouraged you to do so or you have additional feedback and questions after reading, I am looking forward to a message from you.
My Story
I was introduced to the Force.com platform in 2013 by two colleagues and now friends of mine at a Berlin based start-up (Thanks again you two. It’s still great having you around as friends). I was a working student in Finance before I joined the Salesforce team. As part of my working student project, I had collaborated with the Salesforce team lead (given her experience in translating business requirements into technology) at the time and a freelancer who automated a few processes for writing invoices on FileMaker. This reduced time spent on generating and sending invoices significantly from 3-4 employees being busy for 3-4 days in a week to 1 employee 1-2 days.
This was my first hand experience on how organizations should not stand in their own way by not changing tedious and inefficient tasks to the better with platforms that can help them achieving these goals easily. I was so impressed by it, that I had to this more often and wanted to help others understand these simple concepts.
Bye bye finance and hello Salesforce
This is how I ended up as a Salesforce Solution Architect eventually. To keep this personal story short, I later continued with several roles in the Salesforce ecosystem as an internal Administrator, Business Analyst, Berlin Admin Group team lead and later implemented Salesforce and Veeva technology for customers in the Life Sciences industry with multi-cloud projects and roll-outs for more than 700+ users in an international setup. Let me say. I had a great time!
However, there was one thing that bothered me. When I started a project, the decisions on the technology where already made. In some cases I didn’t like those decisions and it was more difficult to help our customers with good Solution Architecture, if the technical foundation wasn’t there to support it. Therefore, I wanted to get involved as early as possible in a project to help customers taking the right technical decisions at the right time. My answer to that problem: The Solution Engineer!
The “Bad” Surprise that turned out good
When I finally reached my goal of joining Salesforce as a Solution Engineer it didn’t take too long until I was left confused if my decision of changing roles was good or bad. Looking backwards, I was an idiot for not realizing why I was confused and more importantly how I could have avoided it. I am proud to say that I was an idiot back then, as this proves progress on my journey.
Let me break down where my confusion came from and why this was avoidable:
Fully understand the objective of the Solution Engineering role before making a change
Konfuzius – 500 BC
As a Solution Architect, you ensure that the solutions meet the business requirements and fit into the enterprise architecture as a whole. The solution also needs to be stable and scalable for future requirements. Sounds similar to the role of a Solution Engineer you might say? I thought so too. Here is what’s different.
While a Solution Engineer might have the same objective in mind as described above, your peers are different. You are supporting the sales team to grow the business and are incentivized (typically by a regional quota) on the number of sales. Therefore, deep technical know-how, as compared to a Solution Architect, is not the most relevant skillset. It’s about explaining the value of your solution to the business and help them taking a decision, sometimes convincing, on investing in your solutions. Don’t get me wrong. I am not saying technical know-how is not important as a Solution Engineer but your peers internally as well as on customer side, will not have that technical understanding as you do. You have to adapt your language and talk about technology as a business enabler and how it will help them instead of mentioning the coolest and latest features of your solution only.
To put it differently – A Solution Architect is hired for a particular project or multiple projects. The decision on these projects have already been made. It’s about putting together a scalable solution that meets todays and the futures business requirements. It requires technical know-how and your peers are typically technical or functional consultants who know how the platform works.
A Solution Engineer may engage before a purchasing decision has been made and needs to raise awareness on why customers should be investing into their solutions or platform without going into the technical details. In fact, it would be counterproductive to speak about detailed functionalities of the platform to a Solution Engineers typical target audience.
How could I have avoided this “bad” surprise for myself?
Letting my ego at home. It didn’t matter on how much I knew about the platform and how many successful projects I have already had with Salesforce. I should have thought about my peers, their goals and how/if the skills that I have can support them in achieving their objectives. I thought I had done that but man was I wrong.
For example: It doesn’t matter that I have build solutions on Salesforce myself, owning 10+ certifications, and know the platform so well that I could talk about all kinds of business requirements and how to particularly solve them. It also didn’t matter that I knew Salesforce better than most of my peers. It only matters if I can explain to customers why I think their organization will benefit from investing into the platform and how we have reduced go-live time from 12 to 6 months due to harmonizing and standardizing technology and going by a platform approach instead of building individual solutions over and over again.
That being said, of course you should stick to your principles and don’t compromise them. Needless to say that a Solution Engineer still needs to qualify if the offered solutions make sense for their customer and sometimes explain to Sales why it’s not a good idea to follow a certain Opportunity.
How I grew into the Solution Engineering Role
After a lot of frustrating experiences I asked myself if I am in the right role or not. I ended up speaking to more experienced colleagues in that role and tried to understand if there is something I can do better. Now, the reality is that it’s not a black or white kind of topic, so there was no simple solution. However, it did help understanding that my colleagues had similar experiences when they started and just had to give it some time to grow into the role and understand how to deal with the dynamics and vlocity given the fact that every Project is different and there is no such thing as one approach that fits them all.
To give you some more context though, I started reading a lot about the Solution Engineering role and how I can improve my skillsets towards that role. Online, I found a few ressources too and this visualization here has stuck with me the most as this made it clear to me why I was having difficulties of adapting to that role at first. I was thinking about the wrong target audience. A Solution Engineer often engages with decision makers in business who just want to understand how your company can help them achieving their goals and not what features of your particular solutions. Therefore, my understanding of the platform was relevant, I just had to shape my story to address the audience and this was not on a technical level.
The above illustrations visualizes the idea of a Solution Engineer, I think. Ideally, you would be speaking to your customers C-Level sponsors as they are planning the business objectives for an organization and are eventually signing the contracts. Now, if we look at their objectives e.g. “Becoming US leader in widget production” you must prove them why your company has the right solutions for them. Guess what, they don’t care if you know every technical detail of your solution or not. They just want to understand if and how you can help them getting there, why they should trust you and what the timeline is of achieving their goals with your solutions.
Even in the middle layer, your VPs and Business Unit Leads typically don’t care about the technical details. They want to understand how it can help them running their teams better to achieve the corporate business goals. Also, an investment might be cut from their budget, so they need to be convinced on why you are the right partner, too.
And your typical end users, they are the ones that might be interested into more details and a typical audience where know-how on detailed level might be important. They are certainly influencing the decision but will probably not have the last call.
What’s my message?
I had to understand that the ideal Solution Engineer would convince the decision makers to invest into our solutions and that detailed technical know-how isn’t always necessary for that. However, my experience as a Solution Architect are still extremely valuable. I just had to adapt my language to my new target group and share authentic stories that I had experienced as a Solution Architect, supporting the idea that they should partner with us to help them achieving their business goals. Not what products in particular are needed for that but talking about the platform benefits for them.
Moving Forward
I am not nearly where I would like to be in this role and my learning journey will continue hopefully helping me to grow further into this role and helping myself, fellow SEs, customers and sales colleagues the value of good Solution Engineering. Now with a focus on the Healthcare and Life Sciences Industry at Salesforce.
If you are considering a change of roles into Solution Engineering, I hope this post was helpful to you. If you have feedback or anything else you would like to chat about, I am looking forward hearing from you.
Demen