The best-of-breed SaaS era is here to stay, which means your Business Technology team will likely be touching several workflows and applications owned by different stakeholders. While obtaining app expertise is worthwhile, having the ability to zoom out of a particular use case and grasp a 360° view of your organization’s workflows, can lead to serious innovation given your bird’s-eye view of the business. That’s where generalists, or at least the generalist mindset, comes into play.
According to Harvard Business Review, hiring a generalist versus a specialist depends on the rate of change in your industry. If it is slow (like in oil and gas), the study says, teams will likely benefit from employing generalists, who can challenge the industry’s long-held assumptions and bring in new ideas. On the other hand, if change is rapid, teams should instead lean toward specialists, who are more likely to help business innovate in certain areas. For a field like technology, you’d think specialists would be ideal – but what about professionals who oversee the tech strategy and efficiency of an entire organization?
According to Erik Lopez, who’s driven Salesforce design and implementation and led Systems teams at Intuit, Lucid and currently CN Solutions Group, generalists are the way to go. After transitioning roles himself, he’s gained insight into the type of experience needed to be considered a true value-add in Business Technology. In a one-on-one talk with Lopez, we were able to discover:
- Why he transitioned from a CRM focus to business systems
- Why he recommends hiring generalists and the benefits of having them on your team
- What strategies he applies during his hiring process to vet top talent, and actionable tips you can use to scope out creativity
- Tips for generalists on the other side of the interview table
- Wins and challenges Lopez has faced throughout his career
Switching From a CRM to Business Systems’ Mindset
Can you describe your background of how you got into Systems, and then how you came to the realization of hiring a generalist as opposed to a specialist?
I came into systems from, I think, where most people come from – a Salesforce background. Years ago, I worked at Western Governors University in Financial Aid and then was mandated to switch to IT. I had no kind of formal IT background. And while there, they gave me two big platforms to work with: OnBase, an electronic document management system, and the other was Salesforce. There came a point where I was looking to grow in my career and I had to figure out which one I wanted to specialize in – and I felt Salesforce was much more broadly applicable, so naturally I headed toward Salesforce.
I eventually realized as I was doing administrative work that I never strictly worked in Salesforce proper. I was always asked to integrate, look at different tool sets, put them in a data flow, put them in a tool chain, architect various things, etc., and it became obvious to me pretty quickly that while Salesforce was a good foundation, it’s not the end-all-be-all.
So that’s how I came to the thinking of the different types of systems and how they work together. As I started running teams and getting into bigger companies, they would architect one or two of the systems really well, and then would try to transfer data between them and would potentially lose information along that path; during the data flow, you would have definitions change, which was really frustrating for people, and so on. So that was my introduction into the whole concept.
Where the Generalist Mindset Excels
You spoke at the Biz Systems Magic conference last year about optimizing lead handoff between marketing and sales, deduping, and other scenarios. Did you have any examples of where a generalist would better suit that situation as opposed to a specialist in one area?
Yes and I found that as a generalist – which I find to be very refreshing and I found useful in my own career – you tend to map things out first and then systematically arrive at a holistic solution. I noticed that when people were stuck on a particular platform, they often thought about how they would solve it in that system and then get hung up on all sorts of related details.
What you’re really trying to do in business systems, however, is figure out how to move from one area to the next – how to move a lead from marketing to sales, for example – and to make sure you aren’t going to mess anything else up in that process – any rules, classifications, etc. It’s an interesting challenge, but definitely benefits from having a broader mindset.
Has there been any other examples or use cases of where having a generalist background truly benefited over working with a specialist?
There are two examples. One is more process-oriented and the other one is about data itself. With GDPR, for example, you have to scrub systems like a Marketo and a Salesforce and make sure they’re talking to other engagement and enrichment tools like Outreach, SalesLoft, ZoomInfo, etc., to ensure data consistency. And so if you’ve architected things correctly and mapped them out, then it makes it really easy to identify where the data goes and where it has come from, and to know how you’re going to approach an integration strategy for that process.
As far as the business process is concerned, a generalist is better able to see across the org and facilitate a holistic view of the customer across channels. They can determine what data or process passes through which function, the point at which the data interacts with other functions (from marketing to sales to customer success), what the business unit wants that interaction to look like, etc., in order to provide a seamless experience. For this scenario, you don’t want the tool to dictate how you’re going to model something. You want to ensure you have a solid vision of the entire process, and then be able to plug in tools where necessary.
The Process of Hiring a Generalist
How has the impact of hiring generalists versus specialists personally made a difference for you? What were some things you were able to pick up on right away?
In a lot of tech interviews, both ones that I have given and ones I was a candidate for, I preferred more open-ended scenarios that deal with business modeling and business-like situations. If you were to spend the time crafting a project that you can just be additive with, you’ll not only get to the technological answer, but also a good sense of whether a person understands business and what the business is trying to do versus someone who largely knows various implementation strategies.
It gives you a chance to see how the candidate would think through creating an application. And that can very well be platform agnostic when it comes to the technology. From this, you’ll get two things: the implementation detail of, “I created these objects [in Salesforce] with these fields – Lookup, Master Detail, and the reasoning behind them,” as well as a sense of how they think through the business with Salesforce proper as an example.
Is there anything else a Systems candidate can do that would make your job more successful?
Yes, and I’m speaking largely from the perspective of what I’ve understood in the Salesforce ecosystem and hiring a bunch of Salesforce folks who have eventually transitioned into business systems – is that I want them to ask more and better questions. Where I’ve often run into issues with hiring is when someone automatically defaults to the prior experience of just building things on the platform and doesn’t say, “Maybe there actually is a solution and this problem has already been solved, so we’d be best not to repeat the wheel.” Or doesn’t dig deeper and ask better questions of the business process.
This is not to say that the business isn’t knowledgeable of the problem and what’s best for them, but it’s always good to be a better interlocutor and risk-taker where you can. So I like to identify how well they’re going to ask questions. Going back to the scenario of giving someone an app to build in an interview, this provides a lot of flexibility and space for hiring managers to say, “OK, tell me more about this.” If the candidate jumps right into the solution, that’s not the kind of person I want to hire.
Right in the interview process, you’re asking candidates to build an app. Are you asking them to do that during the interview process or are you asking for a strategy?
Strategy. I want them to high-level whiteboard it with me. They don’t need to build it out in particular, but I use Salesforce as an example because that’s usually the platform that people know. If I’m hiring someone to manage Gainsight [a CS platform], then I would use more Gainsight-specific examples, but I would still have the expectation that they’d need to touch other systems and I want them to explain that. Being stuck in one app, unfortunately, is not helping anymore.
Generalist Career Tips: Own a Line of Business and Learn to Code
Outside of being knowledgeable of more systems, what other advice would you give generalists hoping to be a good fit?
I think the best thing that people can do in their career is to “own” a line of business. Because you’re going to be faced with the kind of questions that I find very interesting. For example, the business is going to give you a problem and you need to understand the entire end-to-end; not just the particulars of that certain ask. You’re going to have to suss out the business requirements across and through other processes, what the actual workflows should be, the UI, UX, etc.
Then you have to weigh vendor management, looking at the specific tools and determining whether the vendor can give you the right answer. To do this, you have to be able to clearly identify the problem and not get duped by amazing features or add-ons that don’t help solve it. So this goes back to the kind of business acumen you develop in order for the business to trust you to handle their pains and help create a consistent and scalable process, end-to-end.
Another thing to be careful of is: Just because a vendor or system worked at your last company doesn’t mean it’ll work this time around. You have to be open to the fact that every company is different. The end result could be the same, but the journey may be different depending on whom you work with and the culture and how mature your company or enterprise architecture is. You have to be flexible when it comes to identifying solutions.
The final thing I always suggest is: You need to learn code and, at the very least, you need to be able to read it because you’re going to be hiring vendors at some point and you’ll need to transform the data. If you can’t do it, you’ll have to hire consultants to write code for you – and that adds a layer of complexity into your systems. You can’t abdicate any responsibility toward that end or you’ll risk losing control and enabling an incoherent situation. It would help you in the long run to, at least, learn some integrations, architecture patterns, etc., so this isn’t an additional worry.
Where the Industry Can Improve
What do you feel is beyond candidates’ control in the industry, if anything, and how do you suggest they find a way through it?
In many hub app ecosystems, as I’ve gone around to various conferences, another thing I’ve noticed is: people don’t always have a good way of 1) managing their workflows or anything consistent, and 2) gathering business requirements in any real structured fashion.
As I talk to younger admins, I often hear they want to get a better facility for that and better at managing their workflows.
Even though low code is the direction a lot of tech is going in, I still see a coding background as useful, especially when you’re coming into a territory like building enterprises systems and architecture. And if coding is not immediately on your radar, selecting an automation tool where you can configure those things pretty easily.
—
In all, hiring a generalist or specialist in business systems depends on the needs of your organization. In Erik’s experience, he has found generalists to be especially beneficial to his teams as they tend to think more about the business problem and how a workflow will bring greater value to the organization via connected systems and visibility into the data.
