Technology is not a solution. A solution is built around the jobs that need to be done, which at Lift, grows out of our prime directive: the business process should always drive the technology; the technology should never dictate the business process. This directive guides us in everything we do, especially in our view of solutions. A strong solutions architect can be your competitive advantage, but as the role of RevOps has grown, the focus on "solution" and "architects" has multiplied in a confusing way. This episode guides listeners about the most important considerations, which is why Doug chose to reshare this episode in this week of our "Best of" series.
Doug posted to LinkedIn after he saw a lot of job titles recruiting for a solutions architect. He means no offense to anyone, Doug has great respect for the talent, skills, and expertise of many solution architects. That said, if the focus of your expertise is on the technologies or configuration of the product, the role is not a solution architect, rather it’s a technical or product architect role. Solutions architect centers their focus and primary expertise on designing the underlying business processes that should be driving any configuration. To end it off, combining a solution architect with a technical architect will give you fire.
What Doug is trying to get across is that technology is not a solution. Then once you put a brand in front of something, it’s even further away from a solution. So a solution by definition is agnostic.
Doug has theories as to why technology gets called a solution. Some of it is marketing, some of it is the move towards solution selling. If you think about it, the solution is really built around the idea of jobs to be done. Part of the problem is that the product becomes more and more complicated. Someone needs to understand how it’s going to fit within a customer’s existing technology. In a lot of ways that used to be called the sales engineer, and now it’s become the solution architect. That position is to be a master of that product, but it isn’t a solution architect, it’s a technical architect. A solution architect has to go beyond the product and technology and look at the business process.
This episode is a little self serving because Doug and Jess get into why Lift is unique. Doug's favorite, unique selling proposition about Imagine is that we have a pretty good grasp on technical components. He wouldn’t put us in the best category, but our application is the best because we come from a deep and broad understanding of the underlying motions, so we are able to pick up without anyone having to say anything.
So much of tech implementation is difficult because it sounds like everyone understands each other because of the words they use. They feel like they’re talking about the same thing, but they don’t have the same meaning. One thing that Imagine does extraordinarily well is that we’re able to lead the effort. We address the difficulty up front. To be a solution architect, you need to know the problem better than anyone else. Everyone wants to jump to the solve and not fully understand the problem.
Doug had an interesting conversation with his favorite Twitter buddy, Pete Caputa. Pete started by asking, how does your marketing agency go about creating strategy with, or for clients trying to design a survey on this? Doug responded to him by asking, what is your definition of strategy? After asking Doug his thoughts, Doug responded with a link to a blog of ours on Strategy Kills. The blog discusses 3 elements of a good strategy and one of them is a strong diagnosis that clearly defines the challenge. Doug wants to emphasize here that if you’re talking about a solution, it’s a diagnostic process. A diagnostic process takes the first piece of information as a means to get to the next piece. It’s digging in and testing and trying to get to the underlying cause. The actions should be coherent, using resources, policies and maneuvers to support each other.
The biggest strategic problem facing most organizations is how often and badly they misuse the word strategy. What is strategy? It’s the guiding policy where choices are made. Decisions kill alternatives. Strategy gives you the framework to manage tradeoffs and make decisions. Strategy can only come from within because if it is brought to you, you wouldn’t abide by it. You have to be an active participant and it has to be ongoing for it to stick.
If you take a look at how the best companies procure high impact technology, they do a business process audit and diagnostic process first to define the problem, to define the requirements of whatever’s going to be used to solve the problem. And it isn’t the technical architect’s job to say you can’t do something. The technical architect is there to say what the difficulty would be in configuring the technology in a way to make something happen.
Why do you think that the solution architect role ends up getting categorized as more of a technology or configuration focus?
Sales and marketing because they usually call your technology a solution which technology is not a solution. It is an enabler and accelerator of a solution. It’s a way to solve and manage the solution. Doug is a solutions architect first, so he will always prioritize the underlying business process over the tech which might cause him to bypass something.
The solutions architect and the technical architect reinforce each other.
What does a solution architect do and what does the technical architect do?
Depending on the conditions, the solution architect is responsible for how something can be done, what could go wrong, what else you need to consider with regards to the technology. They may be responsible for the actual configuration.
Jess’s Key Takeaways:
Follow Jess, Doug & Imagine on socials for updates on the show or other insights:
Doug Davidoff: Twitter - @dougdavidoff | LinkedIn
Jess Cardenas: Twitter - @JessDCardenas | LinkedIn
Imagine Business Development: Twitter - @DemandCreator | LinkedIn
Subscribe to the show on Spotify & Apple Podcasts
Check out Let's Play RevOps on Twitch for more commentary on this topic