Assemble an Effective Team
After completing this unit, you’ll be able to:
- Structure effective project teams.
- Identify business stakeholders for an app.
- Identify tech stakeholders for an app.
In a traditional Salesforce development lifecycle, app builders use sandboxes to create and test changes. The source of truth is a moving target. The tools and features that come with Salesforce DX present an opportunity to shift how you manage the app development lifecycle for your company, and your metadata. One of the most exciting changes is the introduction of unlocked packages.
Unlocked packages provide a repeatable, scriptable, and trackable vehicle for introducing and managing change in your orgs. When you use unlocked packages, packages become the containers you use to organize your metadata. Packages also become the way you migrate that metadata between environments. And adopting packaging will impact how you manage and think about the very structure of your Salesforce org.
To adopt unlocked packages, your team must also adopt modular app development and all the good things that come with it, including:
- Better ownership of functionality
- More efficient change management
- More efficient development processes (quicker test runs, more maintainable code, and so on)
- Decreased cost to deliver new features
But adopting modular development takes work. It requires more than learning how to use new tools like the Salesforce Command Line Interface (CLI), or adopting a version control system like Git or Subversion to manage your metadata—though those are necessary steps. Modular development also affects how you organize and manage the various stages of app development for your org, and the teams involved in app development.
One of the biggest impacts is the need to untangle your org. The untangling process means looking for patterns in your org’s metadata and organizing your metadata into meaningful units. These units then become the basis for modular development and unlocked packages. The first step on the road to untangling your org and adopting modular development and unlocked packages is getting your org and your teams ready.
Your Salesforce org affects your whole company. When you’re building an app, you know that getting feedback from teams that will be using the app is a critical part of delivering the best solution possible. There are many strategies for involving these stakeholders, or the people who will be affected by a project's outcome, in feedback cycles. In agile development, for example, you build something, show it to stakeholders, get feedback, and iterate on what you built.
But when you’re tackling a project like identifying patterns in your org’s metadata and customizations, how can you engage nontechnical colleagues? And even more to the point, why should you? Isn’t the point of untangling an org to adopt processes and tools that only an app delivery team cares about? As long as you involve the people responsible for app delivery at your company, why would you bother end users or nontechnical management?
Changes to apps ripple through your whole org. When you start thinking about making changes to how you’re managing and delivering the apps that power your business, make sure you’re including the voices and perspectives of the people throughout your business who depend on those apps. But starting to untangle your org by assembling a giant, messy team definitely isn’t the most effective way to begin. So how do you make sure you’re including the right people and building the right teams at the right scale?
Building an effective team begins with identifying the right stakeholders. So untangling your org begins with untangling the many stakeholders for your org. There are a few kinds of stakeholders. You want to identify people who have knowledge of your org from both a technical standpoint and a business standpoint.
There are a few characteristics to look for. You need people who:
- Can accurately answer questions about your business
- Have an awareness of the company and its internal policies
- Know how their own teams use apps
- Know how to find information when they run into questions they can’t answer
Once you’ve identified the stakeholders in your company, organize them into effective working groups. One strategy is to organize teams around the different business units working in your org. Another strategy is to organize around the different apps you’ve built in your org. Whichever strategy you choose, make sure you’re aligning your groups of stakeholders with real functionality in your org and documenting any gaps or overlaps.
Let’s look at examples of team organization for two retail companies: A and B. They both want to start examining their Salesforce orgs and putting some best practices into place around app development.
A is a smaller online retail company. The company uses Sales Cloud, Commerce Cloud, and Marketing Cloud to help manage its direct-to-consumer business. Internally, the employees wear many hats. Because its business is organized more by processes than by official departments, the company decides to form teams organized around the different apps it’s built to support its processes in Salesforce.
B is a larger online retail company. This retail company use Sales Cloud, Service Cloud, Commerce Cloud, Communities, and Marketing Cloud to help manage its distributor and direct-to-consumer businesses. The company is organized into departments, and those departments have different relationships to each line of business. Because it’s built functionality in Salesforce based on the needs of specific departments, the company decides to form teams organized by departments.
Both companies need to make sure they’re communicating across teams. But the two different approaches give each company a manageable way to get started with its untangling process.