Structuring your Salesforce DevOps team in 2024

Salesforce teams are constantly thinking about structures — the structure of our solutions, orgs, CI/CD pipeline, and our data — but how often do we really take a step back and consider the structure of our Salesforce teams themselves?

Just as there’s no perfect structure for your development lifecycle, there’s no perfect structure for defining team roles, responsibilities, workflows, and ways of working. So, we’re not going to tell you how to structure your team, but instead highlight some key questions that you can use to evaluate your current DevOps team structure.

This blog was written in collaboration with Nanners Lamet. Nanners is a Salesforce Principal Enterprise Architect and one of Gearset’s DevOps Leaders.

How big should your Salesforce DevOps team be?

While the number of Salesforce end users or the scale of your Salesforce usage might necessitate a certain number of hands on deck, there’s no perfect size of your Salesforce team. There are many factors that contribute to determining the ideal team size: scope of work, budget, timeline, and above all else the experience and technical skills of your individual contributors. Oftentimes these factors are subject to change, sometimes dramatically, and teams are pressured to adapt to maintain their efficiency and velocity.

Rather than focusing on the sheer number of resources on your team, contemplate the way that your team collaborates and communicates. Ask yourself key questions like:

• Are there any silos or bottlenecks in your team?
• Is there someone who’s solely responsible for release management, who doesn’t have the opportunity or time for peer reviews?
• Is there only one person undertaking all your QA work, overwhelmed by the output of your developers?
• Is there one person on your team who always has the answers, where problems seem impossible to solve when they are away?

This might be an indicator that you need a larger team or improved collaboration between team members.

Over-specialization can mean someone is siloed in your Salesforce process. This can overwhelm that person with the unmanageable workload of taking sole responsibility for a part of your process. It’s also harmful to the wider team, as this person becomes a single point of failure for your Salesforce development and release management.

Silos also create long-term professional development problems. Someone working alone will have stunted career growth because they won’t get the constant feedback and guidance that they need to continuously improve. Isolating parts of your workflow or specific responsibilities also stops other members of the team from gaining experience in this area.

If you suspect or identify a silo on your team, it may be time to evaluate your team size and investigate ways to break silos, increase the flow of communication, encourage upskilling, and redistribute roles and responsibilities.

Who’s in your DevOps team?

In short, your Salesforce DevOps team should involve your entire Salesforce team. While you may have someone focused on the big picture of your DevOps process, like a DevOps Engineer or Salesforce Architect, DevOps only works with buy-in from every team member.

When your whole team has ownership over your processes and understands the impact of their work, they will be inspired to be more engaged and productive. To guide your team towards realizing their role in the bigger picture, it helps to extend the DevOps team to include your Salesforce end users. While end users won’t be directly involved in the Salesforce development work and process, certainly not with their hands on keyboard merging branches in your pipeline, they are key stakeholders. Viewing them as part of your DevOps team encourages you to prioritize their feedback, educate them about your DevOps process, and reduce organizational friction.

When you increase transparency and engage your stakeholders throughout your DevOps processes, you can secure their buy-in and support, and they can help your team recognize your impact and overall business value. Engagement and alignment between your DevOps team and your stakeholders is critical to facilitate successful change.

Is there an ideal Salesforce DevOps team structure?

It’s simple to think of Salesforce teams being structured by defined roles — admins, developers, architects, business analysts — but most Salesforce teams are cross functional, and most Salesforce professionals find that their responsibilities stretch beyond the structures defined by their roles. With the Salesforce platform itself being an amalgamation of so many different technologies, it’s only natural that Salesforce professionals are no strangers to “wearing many hats”.

One of the simplest and most common examples might be that most developers are also quality assurance testers, taking on the responsibility for testing one anothers’ code or configuration rather than strictly focusing on their own individual development tasks. However, we’ve also come across more dramatic flexibility, such as Salesforce admins that were handling everything from the development of quite complex Apex scripts, through to analyzing business data for C-suite.

The range of responsibilities and experiences that you can expect beyond your job title is probably one of the best things about working on Salesforce, so you shouldn’t worry about fitting a single ideal Salesforce team structure. The important best practice to follow is to make sure your team structure encourages and supports collaboration between various roles and responsibilities — which is where DevOps culture comes into play.

How does DevOps culture structure your team?

Beyond structuring your Salesforce development lifecycle, DevOps is key in setting up the right culture for your team. Initially DevOps methodology emerged as a way to increase collaboration and communication between development and operations teams, which were distinct or completely separate in traditional software team structures.

DevOps practices, processes, and tools were introduced to encourage collaboration between these two teams to improve the efficiency and overall quality of the software development lifecycle.

Bridging this gap between operations and the development process is known as "shift-left" because operations tasks were traditionally kept at the end of the release timeline, but in DevOps methodology they are included earlier in the development process, often before any code is written. Shifting left helps organizations reduce costs, save development time, improve the code quality, and drive up end user satisfaction.

While changing software development processes — such as introducing operations feedback before new features are released — creates the opportunity for collaboration and efficiency gains, it’s DevOps culture that can truly have the most impact on an organization. DevOps culture encourages continuous feedback between team members and different roles at every stage of the development lifecycle, allowing teams to address problems and spot optimizations early and often.

When you adopt DevOps culture, you create a team structure that’s low-blame and high-performance, making members feel safe to give feedback and act on the feedback they receive. It also promotes dignity and equality, because the emphasis on collaboration makes it clear that each team member’s contributions and opinions are central to your team’s success.

How do you measure the success of your team structure?

Salesforce DevOps teams are usually measured on their outputs. Businesses place emphasis on Key Performance Indicators (KPIs) that measure quantifiable outputs like net profits and revenue, while DevOps prioritizes delivery performance metrics such as development velocity, deployment frequency, and accuracy. These metrics are important in measuring the output of your Salesforce DevOps process, but they don’t tell you much about how well your team functions as a team. In fact, focusing only on hard output metrics will cause you to neglect valuable considerations such as employee satisfaction, progression, and workload which has substantial influence on retention, productivity, and results.

The continuous feedback and openness cultivated by your DevOps process doesn’t have to be limited to your release lifecycle. Instead, you can utilize the open communication channels created by your DevOps structure to encourage feedback on those softer issues of satisfaction, progression, and workload. While these can sometimes be difficult topics for teams to broach and for leaders to receive, these conversations give you a holistic understanding of how successful or “well oiled” your team is.

Lead your Salesforce DevOps team

There is no shortcut for building and developing high-performing DevOps teams, and no single structure that will get you there. However, we hope this article has given you some inspiration or sparked some ideas for how you can set up your team for success.

If you want to learn more about how you can support, develop and lead your team, take our DevOps Leadership Certificate. Written in collaboration with experienced Salesforce leaders, it covers the fundamentals for leading your team to success.