How to build and scale a successful Salesforce DevOps team

Whether you're just starting to grow your DevOps team, or have an established team trying to optimize your release process, one of the most difficult parts can be establishing a strong foundation that works not just today, but also for years to come.

In the spirit of all things DevOps, continuous improvement is key for any team. So no matter what stage you’re at, it’s worth evaluating your current process and identifying whether there is room for optimization. Here are a few suggestions of how to make sure you’re establishing an environment that will set you and your team up for long-term DevOps success.

Define ownership

The most successful DevOps teams have total clarity on their remit. Ensure that everyone knows what they own, and the responsibilities they have, both individually and as a team. It’s more than likely that your team — both now and in the future — will be made up of individuals with different skills. As you develop or modify a new DevOps process, defining whose expertise is best suited to particular tasks, or which roles are allowed to make different types of changes, will both help avoid mishaps and increase overall efficiency. Some teams scale from a handful of people making changes in Salesforce to over 50 within the space of just a few years — planning ahead can help keep a handle on your org.

And don’t forget that as your team grows, your organization will be scaling too. As a result, you’re likely to get more and more questions over whether your team can do task X, or who is responsible for implementing or maintaining tool Y — so allocate your resources wisely. Remember that ownership doesn’t stop at selecting appropriate technical tools, you also need to consider data ownership, responsibilities, and the relevant controls. What about tools that interface with Salesforce? Do these also require your team's support?

Being able to confidently define what falls inside and outside of your team’s area allows you to determine who will provide assistance, set clear expectations, and stick to these expectations over time. This brings us on nicely to the next piece of advice…

Create guidelines — and document them

In order for your team to work effectively, they — and the rest of your business — need to understand the process by which requested or required changes are made. Determine what matters to you, your stakeholders, and the wider business, and design processes that take this into account.

A core concept of DevOps is having a single “source of truth”. Make sure you have defined this, and that everyone in the organization knows where this exists. To work out what you should include, think about the things that you want or need to track to keep control of your org. Hint: it’s probably not all 150+ types of metadata that are available in Salesforce, and there’s no need to include them if your team doesn’t use them.

It’s also worth identifying whether there are particular metadata types that cause friction in deployments. If you have a deployment pipeline, think about the experience of the wider team in migrating features. If you have a metadata type which is difficult to deploy, it may use up valuable time if it needs to be unblocked. How critical is it to include this in your source of truth?

Once you’ve set your processes and defined the scope of your source of truth, document them and share these guidelines with the rest of the organization. But remember, guidelines don’t have to be set in stone. Over time, the needs of your stakeholders as well as the ability and size of your team will change, so keep going back to review whether your guidelines are still working for you.

Be prepared for growth

Things grow fast in the Salesforce platform, so you and your team need to be prepared to handle it. You should assume that the number of features and team members you need to support will double every year. What would your deployments look like next year, or the year after if this pattern were to continue?

A bigger team means bigger overheads — this could be fielding questions, writing support documents, or solving issues, for your stakeholders as well as internal team members. Aim to reduce thrash wherever possible. Make documentation that answers common questions about your release process readily available — this will reduce the time your team spends away from their day-to-day tasks and increase productivity.

Establish a reliable review process

Whilst code reviews and pull requests are fairly common, your team might not do this — or it may not be necessary to do this — for all code types. This will vary from org to org, depending on the code that is being created or changed. It’s also worth noting that code reviews don’t always need to be completed within a tool. Some teams find that peer-to-peer review of a build on a call or in an ad-hoc meeting works for them, before formally signing off in a tool like Git.

Create a style guide to figure out what actually matters in a code review. This is also a great way to introduce and settle in new members of the team. Whilst there’s nothing more nerve wracking than submitting a code review as the new person on the team, you can make it significantly worse by not telling them what your team actively looks for in their reviews. Defining the goalposts means everyone is set up for success.

If your team has a more mature DevOps process, here’s where you might want to start pulling in some tools to help. For example, if you use Gearset there are status checks, or Clayton could help you craft some automated checks based on your style guide.

You should also remember that whoever it is that’s making changes, we’re all human, and mistakes happen. The skill lies in mitigating this. If your team is always putting in huge pull requests, there’s a high likelihood that the reviewer will overlook or miss something. Encourage your team to keep releases small and ship frequently so that reviews manageable and focused. For some changes, automation using a DevOps tool can avoid human error. For example, you could employ a combination of automated status checks and pipelines to auto-promote features without manual interventions.

It’s worth highlighting that code reviews shouldn’t always be looking for mistakes. Celebrate excellent implementations too! Too often, teams focus on finding errors or breaking changes, when great code is something that should also be called out. On a similar note, work to establish a culture where failing early and fast is encouraged — a team that is scared to fail will suffer in terms of innovation, productivity, and morale.

And finally, avoid creating bottlenecks unnecessarily. Even if you have a defined tech lead, they shouldn't have to be the approver for everything. That'll only slow your process down. And even more crucially, everyone should follow the same process. If you can give a review, you need to get a review, regardless of your role or seniority level. No-one is infallible, so make sure that your review process is one that everyone in the organization can adhere to, to hold everyone to the same high standards.

Manage delivery expectations

It’s important to figure out how and when your stakeholders want various features delivered — and to manage expectations that might change over time. For example, whilst unit tests may take just a couple of minutes to run now, in a year’s time that could double, or even triple — although a strong foundation around unit test practices can help mitigate this. Minor changes add up fast — some orgs can have deployment times which vary from minutes to hours. How can you make this clear to your stakeholders?

You should also consider whether you should release every change as soon as it’s complete — even if you can. Having a defined release cadence can help you set and maintain expectations more easily in the long term than if you immediately release everything. It’s hard to claw time back when stakeholders have gotten used to instantaneous delivery.

Try to always put things into a deployment pipeline instead of always doing ad-hoc deployments. Ad-hoc works well when your team is three or four people, but it’s a disaster once you have more than eight people attempting to deploy in tandem, with a high chance of overwritten changes, merge conflicts and other issues. Even creating the most simple pipeline, laying out how changes exist in each branch and why, will provide a process that your team can follow.

And you need to think about the whole process, because the journey doesn’t stop at deployment. Support is often overlooked when launching a new project. Teams often overanalyze how long it’ll take to build, test, and deliver a feature but rarely consider what it would take to continuously support that feature.

When you have a small team, it’s easy to react to everything, but it’s important to outline how you will triage an issue, determine its severity, and solve the problem. Be ready with levers that you can pull in an emergency if needed to deploy an urgent fix — and be sure you know how they fit into your pipeline too!

All in all, planning for long term support is a key area which will help you envision how your team may need to grow, or your remit may need to expand in the future.

Proceed with caution optimism

Building a successful Salesforce DevOps team isn’t always easy, and scaling brings its own challenges. But it always pays off in the long-term when you get to see the positive impact your team’s work is having, and ultimately helping you to get maximum ROI from your organization’s Salesforce investment.

If you’d like to learn more about how to effectively lead a DevOps team, the Salesforce DevOps Leadership Certificate from DevOps Launchpad is a great resource to build up your skills. You can also encourage your team to brush up on their DevOps knowledge and ensure everyone is on a level playing field with the Salesforce DevOps Fundamentals Certificate. Good luck!