While I can't speak to some of your goals (I'm not currently a CEO), I can give you some advice about expanding your Salesforce.com and IT knowledge, because I've lived in a bunch of IT and consulting roles and have wiggled around in this space a ton since joining it. So, for this blog post, I'm going to take you on a trip down memory lane.
This is going to be a longer post. Grab some snacks and a blanket.
SWEET BEGINNINGS
I entered the workforce at a college's call center, with calls routed to me. This was great experience because I hated every minute of time spent on inbound. "Inbound" is really just a code word for "customer service hell," and was the name for those who fielded incoming calls. If you aren't already aware, most incoming calls at call centers are customer issues and complaints (in my case, it was student issues and complaints). At the call center, I earned my way off of the phone through building better call tracking systems and streamlining common business processes.
My role quickly shifted into a specialist job where I was responsible for jockeying spreadsheets, managing SharePoint farms, and refining Microsoft-Suite-flavored business technologies. During this phase of my life, I built crappy Access Databases and learned a little bit of Visual Basic. I had a few odd job titles as I changed jobs and started to do more work with SharePoint and supporting sales teams, but my professional reputation was consistently Eager Tinkerer -- meaning if you had tedious, repetitive work to do, I was the person you'd give it to if you wanted it to be streamlined and simplified (and if I couldn't figure out how to streamline, I'd carry out the busywork to the best of my ability).
BUSINESS ANALYST
After lots of learning and process refinement, I managed to get promoted into a Business Analyst (BA) role on a Sales Operations team.
I remember my introduction to Salesforce.com like it was yesterday.
I worked at a SaaS company and we were evaluating CRM solutions; and by "we" I mean leadership I had never met... My immediate manager was our Sales Operations Manager. She and I had worked on refining SharePoint together, and she had decided to bring me into the Salesforce.com discussions. It wasn't long before I started listening to calls about "leads" and "accounts" - words that, by the way, mean completely different things when discussing data than they do when discussing sales process. I digress.
During this phase of my life, I was a "Business Analyst" - asking questions about what, when, why, where and doing some configuration within our tools.
I peeled processes off of SharePoint and out of Excel files and transported them into Salesforce.com. Though we didn't use the title internally, my responsibilities aligned with those of your run of the mill medium-sized-organization Salesforce Administrator.
CRM ANALYST
After a couple of years supporting Salesforce.com at the organization, I decided to explore the job market. I landed a job at a large enterprise as a CRM Analyst and found myself hating every minute.
In larger organizations, especially enterprise organizations, Salesforce.com administration activities are shipped offshore or to consulting firms. There may be analysts to oversee the work consultants do, or to scope the work that needs to be done, but it is very common for large enterprises to send work to a third party. This was the case when I was a CRM Analyst. I was more of a PowerPoint master than anything else, since consultants would carry out the actual build of the system.
SR. BUSINESS SYSTEMS ANALYST
So, I boomeranged back to my old company. Sidenote: always, always, always leave on good terms. DO NOT BURN BRIDGES.
My manager and I decided I should focus more on more complex platform development, and coach our more junior/newer administrators up to speed on platform configuration. I really, really wanted to focus on building my code writing skills and my manager let me do just that. Let me just get this off my chest:
I was a *terrible* developer for the first few months.
- I put work inside triggers
- I wrote a ton of future methods
- I didn't understand batch processing and integrations, so I caused issues for the org
- I accidentally reassigned our entire account portfolio
The list goes on and on.
In a lot of orgs, the Business Systems Analyst title means "person who configures complex things" and in the organization that I supported, I also customized complex things.
Configure means you use declarative tools (workflow, process builder, flow) to support complex business processes. Customize means you write code.
I configured dreamy solutions and wrote a ton of code. I got better at writing code as I gained experience, but I also helped the organization accrue technical debt. (I'm sorry for that, guys.)
TECHNICAL LEAD
One day, I decided to apply for a consulting role at the company that had helped my company implement Salesforce.com.
I landed a job as a technical lead at that company. Sidenote: I still love you very much, Appirio.
Technical Leads are a lot like Sr. Business System Analysts who code. My job duties included running code reviews, analyzing business requirements to propose solutions, designing said solutions, delegating work to developers and configuration analysts, and mentoring.
I *loved* this job. I loved it so much that I worked all the time. All the time. Like, I'd be online at 3:30am working.
Consulting was invigorating. Technical Leads are also responsible for working with clients to gain trust, understand the business issues, discuss technical specifications of solutions, demo solutions, align their teams to the customer's agreed upon methodology, etc, etc. Working with customers in this capacity forced me to learn how to talk more about technology in a business-friendly way, beyond asking process-specific questions.
I *really loved* this job. Technical Leads are the glue between strategy and delivery. They work closely with Architects, Business Analysts, Project Managers, Developers, DevOps, Configuration Analysts, and the customers to make sure projects meet (and exceed) expectations.
ENTERPRISE ARCHITECT
After spending a ton of time outside of work learning more about the platform, and continuing to work, I had decided I was ready to start spending a little less time at work. (At one point, I had billed 70+ hour weeks consistently, and it was beginning to take a toll on my personal life.)
I found a company that sounded amazing, and when the only open role that sort-of aligned to my skills was Enterprise Architect, I decided to apply.
I landed the job.
Enterprise Architects are not platform specific. They are platform agnostic. This role required deep understanding of business strategy, and being able to interface more with the business to translate capability roadmaps into technology. While I loved working with the business to talk through business process best practices, common KPIs, and vetting vendors, I didn't feel like a great fit in this space.
SOLUTION ARCHITECT
I decided to apply for consulting roles that would marry my passion for working with the business and my love for tinkering. As a Solution Architect for a consulting firm, I get to plug into business capabilities to help shape and define project scope, and build out prototypes to illustrate how Salesforce.com can help customers achieve their business strategy and technology goals.
Solution Architects can live in strategy and delivery; and I'm frequently pulled in to help out with SOWs and scoping calls. I'm exposed to a ton of industries and different types of businesses (and different variations of small, mid, and enterprise processes).
I love this job, and I love consulting.
THE FUTURE
I'm not sure what the future will bring, but I miss mentoring junior resources. My favorite role was probably Technical Lead because I get a great deal of satisfaction from coaching others, and watching them achieve their own goals.
SHORTCUTS
There are no shortcuts to get the job you want. I recommend hard work, actively listening, engaging with recruiting firms, and staying active in Trailblazer Communities. Before every job change, I reached out to my networks to those who may have experience with the roles I was interested in, just to hear what their experiences may have been or if they had any valuable lessons learned to share. This helps you to know what you're getting into before you find yourself stuck in a job you may not like.
RECOMMENDED APPROACH
I find myself giving the following advice EVERY TIME I talk about career pathing.
- Network to find out what you want to be (Community events, Twitter) and identify potential mentors
- Define your goal
- Say your goal aloud
- Tell people you trust (in the community) your goal; share it publicly if you feel comfortable
- Use Trailhead to learn more about the platform (I recommend to start with the Admin Trail)
- Read Help Articles about specific functionality to learn more about the platform
- Use Developer Docs (if you want to become a dev) to learn more about the platform
- Tinker! Transition spreadsheets into Salesforce declaratively; then write workflow rules as triggers, classes in a dev sandbox just to gain exposure to code (if you want to be a developer)
- Join local Trailblazer Community Meetups and actively engage
- Get Certified!!! This will help you get any job, especially if you don't have specific experience in an area!
- Think about consulting to broaden you knowledge of the platform - you can even consult on your own, on the side
- Volunteer your time as a Salesforce.com consultant to broaden your knowledge of the platform
- Ask your mentors for help
Questions? Comments? Reach out!
I hope you enjoyed this post. It was fun to write.
P.S. I also still love you, Ceridian. I love you very much but you damn well know I do.
