🛫 What’s your 90 day plan?
The inspiration for this post comes from this SFXD Discord post.
What’s the biggest hurdle we face when joining a new company? We want to prove ourselves, but we don’t have the information to do it. We’re newbies. Let’s take advantage of this status in our first 90 days.
Depending on the type of company you join, you might have to reduce the amount of days to execute your plan. For example, if you’re joining a small startup (< 100 people), halve it to 45 days. At a more established company, you’ll be working with more defined processes, so it’ll be some time before you actually see your first feature in prod.
Assuming you don’t have fires to fight immediately, here’s what I’d recommend you do in your first 90 days at your new company:
Your first 30 days as a Salesforce professional
Goal: Retain all the surface level info you can on CRM processes, how the team works, and what they (and now you) are responsible for
Meet and greets
- 1:1s: your immediate team members (admins, devs, QA, architects, BSAs, skip-level manager)
- What’s the biggest challenge facing the team right now? In 6 months?
- How do our stakeholders view Salesforce as a platform? How do they view the team?
- Who are other people I should meet with?
- What does your definition of success look like in my first 90 days?
- How do we get code and config from development to deploy?
- What’s the process around off-cycle deploys? How onerous is it to do?
- What’s the intake process? How does the team action on bugs?
- How does the team prioritize work?
- How do you maintain a healthy backlog?
- Who has the last say in design decisions?
- How do you envision the team looking in a year?
- How do you measure success in the role? How does your manager measure your success?
Learn the business & how Salesforce plays a part in it
- How does the company make its money?
- Where does Salesforce play a role? When you understand this, you understand how to impact the business
- What systems does Salesforce touch? What systems does it ingest information from?
- How do we monitor our instance?
- How’s the data model? How many process builders/flows/workflow rules?
- What’s the Apex footprint?
- Where’s the documentation for the critical business processes? If there’s no documentation, your managers and teammates are your new best friends
- Get your IDE set up so you can easily search through the org
- What do your internal customers use Salesforce for? Your external ones? Try walking a mile in their shoes
- Where’s the room for improvement? Was it hard for you to use Salesforce?
- Always keep in mind how Salesforce ties to the business
Your first 60 days as a Salesforce professional
Goal: Go one level deeper in your learning and set yourself up for that easy home-run
Meet and greets
- 1:1s, continued: meet with the people your team recommended to meet with. In addition, reach out to your stakeholders in engineering (data, integrations), sales, service, marketing, legal, HR, etc.
- Common and differing views: is there any common ground that all the people you just met with share?
- The deliverables tell a story: Read through the tickets your immediate team recently delivered and see how the sausage is made. Is there a clear user story? Acceptance criteria? Did the story move to the comments? Is there even a story to begin with?! Are there lots of bugs? Is there a QA function? Are they staffed?
Manager, how can I help?
- How am I doing? What do I start/stop/continue doing?
- What concerns do you have about me in the role?
- What high impact, low effort projects can I work on?
Focus on Salesforce projects that are low effort and will have a high impact
Think about what to tackle in Salesforce in this manner: what’s something I can deliver in a sprint or two and will let my stakeholders know I’m not playing around with the value I can provide as a Salesforce professional?
What I would do when I was starting a role is to look at the Salesforce tickets that were assigned to a Salesforce developer or Salesforce administrator that didn't have any traction for some time, but it was still marked as "Important." More often than not, they were still important, but someone couldn't get to it. I would take on work like this and it would have a huge impact on the team when I delivered it. Plus, my coworkers were thankful that they no longer had to worry about it.
A helpful word of advice when it comes to estimating stories: you should assume it will take at least 20% longer than you initially estimate. Being great at customizing the Salesforce platform does not always translate to being great at estimating how long a piece of work will take to complete.
Face-time with your users who will be using Salesforce every day
- Find the super users of the system and learn their pain points. It might sound different than what the other people are telling you 😯
- Don’t judge how they work around the system, you’re there to listen
- “What do you like about using Salesforce? What do you hate about it? Please explain”
- If there are up-to-date recordings of your users using Salesforce, then watch those!
Your first 90 days as a Salesforce professional
Your main goal as a Salesforce admin or Salesforce developer
If there's one takeaway from your first 90 days, it's to get a quick win under your belt. Additionally, you should start to find out what you will specialize in on the Salesforce platform for the next few months. If you're an individidual contributor (like a Salesforce Administrator or Salesforce Developer), you can speak with your manager to identify priorities.
Getting the quick win will build trust with your Salesforce team and stakeholders
Okay, DA! You're talking about "quick wins," but what does that actually mean?
Think of a quick win as a new Salesforce feature that you could deliver to your stakeholders with relative easy. Another example would be fixing a pesky Salesforce bug that other members of the team either were too busy or lazy to tackle. If you can find something that makes your business stakeholders' or your teammates' lives easier ont he Salesforce platform, then you're building trust with them - one step at a time.
It's important to call out that you should make sure you have enough business context under your belt before you start updating Salesforce metadata (this means Apex classes, Apex triggers, Flows, Workflow rules, Process Builders, and more). You don't want to turn your quick win initiative into a huge bug that the team has to jump in and fix. I guess this advice does really only apply to you if you're one of those renegades who makes changes directly in Salesforce production.
Make sure you get feedback from your team, which includes the Salesforce QA team and any relevant business stakeholders before pushing your changes to production.
When Salesforce professionals build trust, they shape the future of their Salesforce instance
- What are some things I could implement that would change the business for the better? Examples: Process Builder consolidation, trigger frameworks, better user experience
- I don’t know the history of how “X” feature came to be, but what if we changed it so that it did “Y” instead? (leaning on the newb card here)
Get actionable feedback
- Meet with your manager: How am I ramping up? What am I doing that’s working/not working? What can I help with now?
- Check in with your teammates: How is it working with me? How do our working styles complement/conflict?
Pave the way to success with your manager
- Let’s talk careers: What does it mean to be a top performer in my current role?
- What part of the platform should I focus on in the coming months?
- What is concerning you the part of the platform you want me to focus on?