Using Slack as a Control Plane

This is the first post in our Slack for Architects series. In this series, we’ll share how our team has been thinking about, implementing and using Slack to run our business, as well as what we’re learning about Slack as a group of working architects. We want this series to help architects answer some key questions:

• How should I guide my teams and customers to think about Slack?
• What are the emerging best practices (or anti-patterns) in custom Slack apps and workflows? (Especially large-scale implementations?)
• What are some examples of how Salesforce is thinking about and using Slack?

In this post, we’ll look at how our team contextualized Slack in our own system landscape, how we identified the ‘sweet spots’ for Slack, how we prioritized and edited the kind of work we’re doing in Slack, and how we’re thinking about measuring value of the work we’re doing with Slack.

The other posts in this series will look at using Slack to:

• Collaborate effectively as a remote-first, async team
• Better automate and scale engagement & projects
• Apply well-architected principles early & often

Let’s dive in and look at how we went about placing Slack in our overall technical landscape.

Placing Slack in Our Enterprise Landscape

Along with building Salesforce Well-Architected, our team has been working on our technical infrastructure. When we started our infrastructure design, we originally looked at how we could build our own world-class Salesforce implementation.

Inevitably, we had to make the decisions about what to cut and de-prioritize as we translated our ‘art of the possible’ into ‘what can we deliver this year on time and on budget?’. As we made these decisions, it became clearer that better leveraging Slack could allow us to automate and orchestrate some of our most important work — with a minimum of backend infrastructure changes or investments. (If you want to see how we streamlined and defined our automations, see Tom Leddy’s Optimizing Our Processes for Consistency and Reuse.)

Here are some of the realities we had to consider as we designed our own usage of Slack:

• Implementation maturity & context — We’re not working with a greenfield implementation. We’re part of a large enterprise implementation, with considerable maturity (i.e. IT-centralized management, security, approvals…and bureaucracy). This means any solution involving custom code will be significantly more complex and slow to implement.
• Stakeholder context — Not every person at Salesforce is highly skilled in Slack. Our company trajectory is aimed at increasing overall understanding and skill in using Slack — but skillsets vary widely across different parts of the company. Our implementation of Slack can support both internal and external stakeholder engagement scenarios.
• Team context — Our team uses Slack heavily, but we are relative novices in terms of using automation and apps within Slack. We are a small team, with no dedicated role focused on Slack management or app dev. (Which deeply influences what design choices will serve us ‘at scale’.)
• Our actual business priorities — The core mission of our team is to build & deliver architectural tools and resources. Time spent dreaming up or designing use cases is time away from our core mission — unless these efforts result in tangible, useful resources for architects OR significant time savings/velocity boosts for our team.

Like many users in a large enterprise, we have to figure out how to get the most usage from “out of the box” Slack behaviors — without creating a mass of ad hoc configurations that won’t scale. Enter the idea of the control plane.

Slack as a Control Plane

This idea first came up in a discussion our team had with Parker Harris, as we worked on the first Architect keynote for Dreamforce. We chose to use Slack as a key part of two demos: our ‘Align Everyone’ demo, showing ways a working architect could manage projects and stakeholders, and our ‘Unlock Engagement’ demo, which showed a first look at Salesforce Flow in Slack.

As we reviewed the demo details, Parker asked us how we were thinking about Slack as a control plane — particularly in the ‘Unlock Engagement’ demo. The idea essentially boils down to: What kind of info or action, surfaced in Slack, could make someone’s day faster and easier WITHOUT requiring them to leave Slack?

The conversation helped us realize we needed to re-evaluate our use case for Salesforce Flow in Slack. Our first pass at the automation really amounted to using Slack to interrupt someone’s day, and ask them to switch context to get some kind of work done. Instead, our automation needed to help them get work done faster — within the context of the kind of work they were already doing in Slack.

As we built out our own usage of Slack, the idea of truly creating a control plane for our operations stayed with me. To get to that level of effectiveness, we needed to think through a few things.

First, we needed to do some basic discovery about our current context:

• What kind of work was already happening in Slack?
• Where was similar work happening in across other systems?
• What kind of tools or apps could we use or build in Slack, without running into corporate IT approvals/processes?
• What kinds of apps would require corporate IT approvals/processes?

Next, we needed to step back and evaluate. We needed sort out our ideas into potential roadmap items, patterns, as well as anti-patterns:

• What was good/bad/indifferent about the work we were doing in Slack?
• Why were different sorts of “similar work” happening in other places? (i.e. Because of necessary context in that other system? Because it pre-dated Slack? Because we just haven’t thought about using Slack? Some other compelling technical or operational reason?)
• Based on what’s working well for us in Slack, what kinds of “similar work” seem more aligned with those uses?
• Would it be good for us to consolidate all of [x] kind of “similar work” in Slack? If so, what kind of work would remain in other systems? Could we eliminate some systems?
• What kinds of limitations or blockers would we run into if we tried to move [x] work into Slack? (i.e. Where would bureaucracy in our company slow us down or block us? Could we find ways to experiment & avoid building ‘shadow IT’?)
• Based on what’s not working well for us in Slack, what patterns or app behaviors should we avoid? What kinds of “similar work” might fall into an anti-pattern in Slack?
• What kind of “similar work” should stay as-is? Why?
• What kinds of work would we NOT support in Slack? Why?

Let’s take a look at how our team answered these questions.

When we compared our ‘what work would be better’ ideas to our priorities for infrastructure and automation as a whole, we realized that simply making better usage of our channels would help us get a lot more effective work done in Slack. We’ve modified our team’s “how we work” policies to include how we set up and maintain Slack channels, and use workflow builder to drive more work through those channels. (Which will also help us govern and scale these initial experiments, as we had to develop design standards & lightweight policies for what we’re building.)

The anti-patterns we identified essentially all boil down to NOT using Slack as a control plane. Using apps that just add noise to a channel, and require us to leave Slack to get work done — that is an anti-pattern. (To be clear — sometimes getting a notification in Slack is helpful. But it’s something that’s most helpful on a per user basis vs. on a channel-wide level.) Similarly, building elaborate workflows to try and shove complex datasets into Slack vs. identifying (and quickly shipping!) clear, simple workflows that can automate pieces of low-level or repetitive work — that is also an anti-pattern.

As we deliver our first wave of roadmap items, we’ll need to revisit our “how can we get better work done in Slack” conversation — starting right back at the discovery phase. But this approach allowed us to identify where we could get more value out of how we’re automating and getting work done in Slack — without having to do any heavy lifting around implementation or development. We are also able to measure success pretty straightforward terms — channel size, activity, workflow usage metrics, etc.

In future posts in this series, we’ll take a deeper look at the workflows we’re building in Slack, the ways we’re using it to collaborate as a team and with stakeholders inside & outside of Salesforce and the policies that we’ve set up to be intentional in our Slack usage and implementation.