Marie van Roekel, Customer Success Architect at Salesforce.org, and Paul Ginsberg, Golden Hoodie recipient, talk about their journeys into Salesforce and define an admin and an architect.
How did you get started with Salesforce?
Paul: This is an easy one. A friend asked me to help them out as a side job. My first task was to create formula fields highlighting data quality issues — e.g., identifying Contact records that didn’t have enough information filled in. Having previously worked at an IT support company where the opportunities to permanently help people out were few and far between, I quit my job and moved over to Salesforce full time.
But as a side note — and anticipating the next question — almost from the beginning I was creating custom objects and considering architecture to store data.
Marie: I actually resisted working with Salesforce when I first encountered it. I had been working as a Business Analyst in the CRM space for a couple years but had left CRM to work again in web-based custom developed solutions and some other CRM-like projects. However, I changed employers and my new role required that I focus on identifying and implementing technologies that supported the maturation of business processes. Salesforce was one of the tools that I had to use. I rolled up my sleeves and got deep into finding ways to maximize use of the platform and extending it with either ISV solutions or custom-built integrations. Paul, what is your definition of an Admin?
Paul: Let go back to basics: An Admin is someone who helps an organization with their administrative functions. So this could be anything from resetting passwords to updating picklists and creating reports. If they’re unlucky, it might also include data cleansing (I encourage my organizations to solve that at the source). But let’s be realistic. This is a tiny percentage of a Salesforce Admin’s time. Usually they’ll be helping users articulate their processes and then implementing that in Salesforce, using anything point-and-clickable, from field creation to — ideally, if they are at the top of their game — Flow.
In a perfect universe they’d also be spending lots of time supporting user adoption and training, to make sure that their organization actually achieves a solid return on all that investment.
But then comes along the stretch request. It may be to help implement a complex process or an integration with another system. Many organizations just have that one Admin, so when does it stop being a stretch task for an Admin and when should it be escalated to someone else?
Marie: I agree with you in seeing an Admin as that “administrative” individual who keeps a lot of the repetitive daily operations humming along. In American English, I would call that person a “doer,” meaning they’re very task-oriented. But I’ve learned that the term “doer” in English means someone with a “can-do and just makes things happen” attitude.
So without using the term I originally thought about using, I’d like to point out that the term “admin” has really grown to mean so many different things in the IT sphere. I think of a Windows System Administrator versus a Database Administrator versus a Salesforce Admin, and they are all very different jobs. But at their root is a focus on supporting daily operations.
At the bare minimum, a Salesforce Admin should understand how to create commonly requested reports and dashboards; perform basic user management tasks; complete basic config items like new fields, validation rules, and page layouts; understand the difference between roles, profiles, and permission sets; and have a good understanding of where to get help for all things Salesforce (Help & Training, Trailblazer Community, Power of Us Hub for Salesforce.org topics, and Google are the top four). Moving on, what is your definition of an Architect?
Paul: So here I’ve got no actual clue. It sounds grand and I’ve just presumed I’m not one, which led to this conversation. But I also know that assumptions are the foundations of most muck ups. Architecture starts at the point when a solo Admin can’t design it all, but maybe two Admins together can, if they brainstorm together. In fact — and at a slight tangent — that’s why I like collaborating with others: If two people have different skill sets, together they may complement each other and create awesome results.
Marie: To me, anyone who takes a look at the end-to-end processes and then incorporates a vision for the future in their designs is already well on the way to being an Architect (if they aren’t one already). Over the years, I’ve seen people start in an “admin” role and end up being “architects” of one sort or another.
Someone can start life as an Admin doing things like basic user set ups and password resets, building reports and dashboards, adding/editing fields, and other configuration changes based on direction provided by someone else (for example, a business user).
At some point, that Admin will likely start asking questions. What’s the purpose of this field? What if we did this instead? They start to add some “business analyst” skills with collecting requirements and identifying other ways to solve the problem.
From there, that person can start to see that this department/team/process/system is part of a bigger picture and how it fits (or doesn’t) with other departments/teams/processes/systems (for example, through integrations, user experience design, and so on). When that person starts to advocate for better solutions in the context of the larger picture, that’s when the move from Admin to Architect can be observed.
Paul: So, when did you realize you were an Architect?
Marie: I started calling myself an architect after I realized there were a lot of people that I was encountering in my engagements who called themselves architects, but didn’t have the depth and breadth of experience or skills that I did. I did a few internet searches for jobs and realized that I really was what the job market considered an architect, not “just” a business analyst. At the time, “solution architect” or “functional architect” were the titles I was seeing that best matched the work I was doing for clients, so I chose “solution architect” to describe myself from that point forward. I had looked at the “enterprise architect” and “technical architect” postings, but I didn’t feel that I had all of the qualifications. Interestingly, in hindsight, I think that I could have chosen either of those labels, too.
“Architect” is a term that could mean so many different things,. It’s like the term “doctor”, which can be a third-year medical student, a general internist, or a highly specialized pediatric orthopedic surgeon, not to mention veterinarians, dentists, and professors.
Throughout the Salesforce ecosystem, you find many specializations or focus areas for Architects:
- User and customer experience
- Business processes and impact
- Configuration and code design for a certain subset of clouds
- Solutions for individual projects
- Transformation programs (these can include many of the Salesforce.com Certified Technical Architect competencies as well as other systems)
- High-level relationships of numerous systems (not just Salesforce)
- The code side of Salesforce architecture; e.g., integrations, code, security, and so on
- Customer success, which blends all of the above
And in my personal experience in the United States, a technical architect will often be expected to be able to code, whereas that’s not always the case in Europe.
Paul: OK, it’s now becoming clearer to me. Would it be fair to say that this is a development? That as the Salesforce ecosystem has grown and become more sophisticated, these roles have been created to help flesh out the gap between Admin and everything else? You could even say that the establishment of Ruth the Architect as a Trailhead character was a symptom of this change?
Marie: You are correct. To make it more “fun”, in the ecosystem of partners and customers you may find other titles in use. Partners may call it Business Analyst, Functional Consultant, Solution Architect, Senior Developer, and so on.
And then add languages where a literal translation from a language to English results in a different word. A customer in Finland shared with me that they were searching for a “Salesforce Designer” to join their team. When I asked them to describe what type of skills they wanted this person to have, though, they were describing what I would call an Architect. As an English speaker, when I hear the word “designer,” I think of a graphic designer or user experience designer, not an architect. It turns out that they had literally translated the Finnish job title to English and this was why they were struggling to fill the role.
Paul: So the ecosystem still needs to catch up? Just like those dreaded job postings that ask for an Admin with Pardot implementation and Apex experience. We still need to educate many of those in recruiting about what’s actually practical and feasible. It will create a happier experience for everyone. I suspect that some customers still don’t know the power of what they are using and this creates unrealistic expectations. If the market used the correct job titles, this might even create more respect the role and lead to better decisions being taken.
Marie: Agreed. So, do you believe me now that you, too, are an Architect?
Paul: Yes, I suspect I do. But I love small businesses and nonprofits, and realistically they can’t afford the full time market rate of an Architect, nor do they they need one all the time; this is why many of them go to partners to buy in that service as and when required. I’ll just have to hope that small and medium-size businesses become even more cognizant of the benefits of having part time staff. Having a part-time architect can reache under-served groups in the job market and can solve hiring problems at the same time! It takes an Architect to come up with a cool solution like this I guess!
source: https://medium.com/salesforce-architects/correspondences-from-admin-to-architect-2c0347ff659a
