I’m a Lead Salesforce developer for a big tech company, where I support our critical business functions (Sales, Marketing, Support, Legal, etc.). Our team has people with lots of experience – including integrations, development experience on other tech stacks, and just overall great Salesforce chops.
The work we do focuses on building custom solutions to support these business functions. It revolves around the Salesforce platform, but we sometimes find ourselves using different tech to meet their needs when Salesforce is a bottleneck (ahem, governor limits). My role focuses on the backend and automation side of the business.
Here’s a quick run-down on the day in the life of a Lead Salesforce Developer at a big tech company (Hint: you’re not coding as much). I’ve consolidated some of my day-to-day roles into a few patterns I’ve seen in my time working as a Lead Developer: (1) technical leadership; (2) planning; (3) unblocking/facilitating work correctly; (4) levelheadedness.
Provide technical leadership
Yes, I write less code and review more of it now. And that’s ok. The job now is an opportunity to grow and mentor the people around me, identify the trends in the Salesforce ecosystem to see if it’s valuable to implement or just a fad, write the technical vision for the team, and tackle technical debt.
When a new project or initiative starts, I will participate in the initial discovery calls and answer how the current business process works. It sheds light on how long it will take to implement some of the business requirements. I’ll also involve myself in coordinating designs with our system architect(s).
Growth and mentorship
It ranges from tactical implementation details — “This is how you do a pull request” — to meta-level discussions about careers — “Conquering your impostor syndrome is entirely possible and takes time. Everyone makes mistakes – how do you learn from them and iterate?”
Identify trends in and around the Salesforce ecosystem
I find myself reading release notes and Salesforce blogs, browsing Salesforce, Dreamforce/TrailheadDX updates, etc.
Here’s an example of a trend impacting me: cloud-based businesses are shifting from subscription-based pricing to consumption-based pricing. In my case, I have to think about any potential impacts to our customized data models, current CPQ implementation, development roadmap, and how companies actually define product consumption.
Write a technical vision for the team
Tanya Reilly puts it succinctly: send small but thoughtful gifts into the team’s future.
By executing the bullet points below, we send our teams now, and in the future, small and thoughtful gifts to make their technical lives easier.
- The business comes before and after the technology: No “us vs. them” mentality here. Other than your core tech team, do any of your business stakeholders care about your core backend? A bit of empathy goes a long way.
- How can we answer teammates’ burning questions? How was onboarding for you? Is there a critical business process that can’t work unless one specific person is there? How do we enable others to participate in that process to remove the bottleneck? What’s a best practice that we haven’t implemented yet?
- Think long term (5 years): Yes, everyone has a plan until they get punched in the face. But, it doesn’t make sense to write a vision that’s short-sighted — thinking only one year out is too small of a time-scale.
- Be more specific: Example — All integrations to and from Salesforce will no longer be point-to-point but tunnel through our middleware of choice.
- Keep it short: People won’t read long walls of text. A two-page document chock-full of information and references to other content will do the trick.
Pay your debts
Legacy code slows down development and admin throughput. When any code or config hits production, it becomes legacy code.
It’s hard to justify to the business that I will take time away from the Applications Engineering team to focus on fixing things they won’t even see. Still, it’s a baseline requirement for me to figure out where the technical debt impedes the business functionality and build a plan of attack around it.
This role flies under the radar, but it’s critical to your success as a Lead Developer: doing the unseen work to help shepherd your team along. I’d say that unblocking my teammates and shielding our team from politics is that unseen work.
Your teammates will get stuck. They need help with consolidating Process Builders or deploying their changes to production. Their business partner isn’t responding to their requests to UAT, and it’s the last day of development. The behaviour outlined in the API documentation doesn’t line up with what’s happening in front of them.
You’ll need to have the business knowledge and technical chops to get them unstuck. When it comes to getting a dev/admin unstuck on a piece of Salesforce-related work, I don’t explicitly solve it for them (unless it’s a real-time crunch), but I guide how to resolve it. Why? If I do the work for them, I’ll pay the price when I inevitably have to do it again, and I become the bottleneck. Don’t deprive your team of learning.
No silent sufferers
I also need to pay special attention to the silent sufferers and weed that behaviour from the team and instead replace it with a culture that enables people to speak up when they’re stuck. No one wins when someone’s silently suffering. In the end, this behaviour affects the software deliverability in the short run and team credibility in the long run.
Shield your team
You’ll find that stakeholders will inevitably escalate on your team. It’s just part of working on a Salesforce implementation at any company.
Identify the performative escalations from the actual ones. In either case, it will fall on you to handle those escalations to shield your developers and admins, so they can focus on delivering their work distraction-free.
Plan for the future
There’s lots of planning involved, more than I ever thought was necessary when I first started as an entry-level Salesforce developer.
- I will meet with the other leads to discuss all tickets that come through our intake process since the last time we met, figure out which team will work on that ticket, and all of us will make a “scientific wild ass guess,” aka a SWAG.
- Next, our team will meet to take another pass at the ticket and reach a consensus on how long we think it would take for someone to do. When assigning tickets to the team, it’s crucial to consider the business priority, a potential carryover from the previous sprint, vacation times, and my teammates’ skill sets as part of the equation.
Guardian of the calendar
One of the unwritten rules of progressing in your career is that you will have more meetings. How can we get any work done when our lives are status reports, sprint planning, retrospectives, and ad-hoc work?
It’s on me to make sure I’m constantly auditing my calendar. There are four questions I ask myself when deciding to take or schedule a meeting:
- Does this have to be a meeting? Could this be resolved via an email, JIRA ticket, Slack message, etc.?
- Do I need to be there? Is this something I can watch later on? Do I need to make an important decision or is it something I can decide later on?
- Are the results of this meeting going to benefit anyone/anything? Which team(s) will make what decision(s)? Are we coming up with ideas for a solution? Are we going over something pertinent to the team?
- How is this meeting helping our company/department objectives? It’s easy to run off-track when the team doesn’t know what their “north star” is.
If you find yourself saying no to the first three or can’t answer the last one clearly, it’s fair game to cut!
Keep your cool
Some of my managers have told me that I don’t look like I care enough when stakeholders are screaming their heads off. My response is: “why should I reciprocate that type of energy back to my stakeholders?”
Maintaining a sense of calm is essential — people feed off your energy. As a Lead Developer, you are in a position to influence and course-correct a failing project, talk down a pissed-off exec, or motivate a dejected group of individual contributors.
One of the main things that help me keep my cool is to put the high-stakes situation in perspective: it’s a manufactured sense of urgency. If we don’t deliver on the deadline, do people die? Do we lose our jobs? Most likely not. This is not to say that I don’t care for our business stakeholders’ issues: it’s merely an attempt to remove stress as a factor in my decision-making.
It also helps to have an incident management strategy. We can learn from Google SREs, a group of people that keep revenue-critical systems despite things like natural disasters and bandwidth outages.
The work you do will not always have immediate benefits but will compound over time. When you become a Lead Developer, you’ll find yourself writing less code but thinking strategically about the long-term health of your company’s Salesforce implementation for years to come. You’re no longer worried about your own work. Still, you’re enabling your developers and admins to do their best work with your guidance so that they become self-sufficient to eventually lead teams and company initiatives in the future. When you protect your and your team’s time, you’re helping keep your team on track to help your stakeholders and meet deadlines. When you’re keeping your cool, your calm permeates through your team, which serves everyone well in high-pressure situations.
Join my free newsletter on Salesforce careers, salary negotiation, and psychology at somemagicnuggets.com.