While trying to gain footing in the Salesforce ecosystem, it may be difficult to see how the exercises in The Salesforce Anchor actually help on the job. A lot of the program benefits are for those still searching for their first job but there are also transferable skills that can be applied in the first thirty days of that job to really make a splash.
First, create a developer sandbox for yourself. This will be your playground. There are three different types of sandboxes, and it's really important to make sure you choose the right one. Otherwise, your attempts to start off with a splash may backfire, because some types have costs involved. There's also a limit on how frequently you can refresh a sandbox so you'll need to make sure that you understand that, as well.
The most robust version is the full copy sandbox. It is not only a copy of all the metadata from Production (fields, layouts, automation, record types, etc.) but also the data. So it's essentially a full backup of Production that can be refreshed no more often than every 29 days. Depending on the licensing contract with Salesforce, the number of full copy sandboxes varies from org to org, if there's one at all. It's not uncommon, especially for smaller, less robust orgs to not have a full copy sandbox at all.
Instead, what those companies may opt for is a partial copy sandbox. Still a complete copy of all the metadata, but only a subset of the data, up to the data limit of 5 GB. Other than that, partial copy sandboxes can be refreshed as often as every five days.
Both full copy and partial copy sandboxes have costs associated with them. For that reason, make sure you create a developer sandbox. There's also a Developer Pro that's available but the only difference, again, is storage limit. Developer sandboxes have a capacity of 200MB while Developer Pro sandboxes can have 1GB. The cool thing about developer sandboxes, though, is that every org comes with the ability to spin off several up for free. The main drawback with these sandboxes is that you won't have any data copied over from Production. So, usually, you'll have to create some dummy data before you can really make use of the system, but even that’s not considered a downside in this case.
Once you have your Developer sandbox created, start creating some dummy data. While it might seem like a tedious task at first, when it's your first week on a new job, this is a great way to familiarize yourself with what the system does. Even further, and possibly most importantly, it gives you a chance to see the system from the end user's perspective first. By walking through the system and creating all of the necessary underlying data, you'll start to understand more about how it's being used currently, and eventually how you can improve it in the future. Keep a notebook along the way of your findings, that will come in handy.
Next, review your notes and identify what your low-hanging fruit is. Can you improve any page layouts? Would some new, better filtered list views be helpful? Can you add help text on confusing or ambiguous fields? You'll know the low-hanging fruit because it's something that you can update in 10-15 minutes.
Then decide what might require a little more time. These tasks are things that might require between an hour and a day to update. Things like updating and testing automation logic, overhauling reports and dashboards, or giving an entire app a facelift.
Finally, highlight what may require a longer term, more strategic approach. These tasks often require several meetings and coordination from multiple business stakeholders, who you may not even know yet since you're new.
Once you've got a list of things categorized this way, start with the low-hanging fruit and make those updates in your Developer sandbox. Once you finish those, move up to the next ones. If you think you can, keep going and tackle the difficult stuff. But the point of this entire exercise is to be able to show what you can do with low risk.
Once you've made changes to a page layout, or you've overhauled an app, setup some time with your boss to show them your ideas and get their feedback. The point of this exercise isn't even necessarily to show what you can configure, although that will be a byproduct. The real intention is to show your boss that you know how to identify improvement areas and can take the initiative to improve them without risking the integrity of the system. You can also use this time to bring the long-term fixes or solutions to the table and show your willingness to not only be immediate, but also strategic.
This is one of the main goals of the pedagogy behind The Salesforce Anchor: to see problem-solving through a Salesforce lens. Each course is rooted in a different scenario but, regardless, students just have to put on their Salesforce glasses and then they can see where they can have an impact in the system.
Especially as a Salesforce consultant, but also as an in-house admin, being able to put those glasses on, identify weaknesses in the technology, and be apart of the ideation process to resolve that problem is what will keep you employed.