I’m fascinated by software design patterns. If you’re not familiar with them, you’re in for a treat. Start here: https://en.wikipedia.org/wiki/Software_design_pattern

Martin Fowler has this to say about patterns:

For me a pattern is primarily a way to chunk up advice about a topic. Chunking is important because there’s such a huge amount of knowledge you need to write software. As a result there needs be ways to divide knowledge up so you don’t need to remember it all – what you need is to be able to get at a particular chunk of knowledge when you need it. Only then do you need details.

(from https://www.martinfowler.com/articles/writingPatterns.html)

Patterns aren’t just for software, though. They come from architecture in the first place, and the underlying pattern (yeah, I went there) of providing useful advice on a topic with a general description of the solution is darn near universal. Since I spend a lot of my time working with teams on how to communicate with one another and organize their work, I’ve encountered some social interaction patterns that I find useful.

This is a writeup of one of those patterns, the Sheriff pattern. I did not create it, but I can’t find a writeup anywhere else.

Sheriff

The Sheriff pattern is a way for a team to control its interruption level. It’s useful in cases where a team provides service to multiple customers and is responsible for managing systems which can themselves create interruptions.

Context

This pattern is useful for a team that has operational responsibility for one or more systems, both in terms of taking requests from customers and in managing the systems themselves to ensure uptime and continuing function. An operations team is a good example of this; in any given time period, the team has a set of planned work, but must also deal with unplanned work in the form of requests from developers and system-driven problems and outages.

Problem

Unplanned work in the form of interruptions from customer demand and system issues dominates the team’s time, resulting in the team failing to deliver planned work. This is primarily due to task-switching and the corresponding loss of constructed mental state.

In some cases, a team with high interruption level will deliver consistently, but at a low level. In this case, the team may be keeping their commitment artificially low to account for interruptions. While teams *should* plan to leave capacity available for unplanned work, if you’re seeing that the team members are doing a lot of task-switching, the Sheriff pattern may provide value.

Solution

Choose a team member to act as “Sheriff,” rotating this duty between team members.

• When “on duty” the Sheriff acts as the primary point of contact for the team, handling customer requests
• The Sheriff also takes point on dealing with interrupts being raised by systems
• The Sheriff should be proactive in taking responsibility for customer interactions; this is a more important than completing planned work (or to put it another way, this is their planned work)
• The Sheriff must have a low amount of (or no) planned work in the current iteration
  • This pattern also works for teams using Kanban or other non-iteration-based systems; in these cases the Sheriff is primarily focused on intake rather than delivery
• The Sheriff’s identity should be known or easily discernible to outsiders
  • Consider using a visible signal in the workplace (a sheriff hat placed atop a monitor, or high-visibility vest hung on the back of a chair
  • In chatrooms and email, use an alias that can be redirected to the correct team member with a minimum of work; this allows outsiders to direct their requests to the alias and know that it will resolve to the right person
• Other team members can (and should) direct requests sent directly to them to the Sheriff, explaining that this will provide a faster response
• The Sheriff can (and should) hand off work to other team members when the Sheriff runs out of capacity; preserving the ability to respond to new customer requests is the top priority
• The Sheriff should use the team’s backlog and task board to track customer requests so that the full team has visibility to the work being taken in
• The team should monitor the Sheriff’s workload and step in as needed; the point of this pattern is not to land all of the interrupts on one person but to maximize overall team effectiveness
• The Sheriff role should rotate between members of the team on a regular basis
  • All members of the team should participate equally
  • No one person should be the Sheriff for longer than an iteration (or two weeks, if using a non-iteration-based system)

Benefits

In general, the Sheriff pattern reduces interruption for the team as a whole, which leads to reduced task-switching and more focus on completing work for other team members.

The Sheriff will need to hand off some issues to other team members due to expertise or specific knowledge. In these cases, the Sheriff is providing value by positioning the interruption in the way that will have the least impact on a teammate’s time. Teammates are better positioned to understand when someone can be interrupted without damaging their mental state. When a teammate leans back in their chair and looks upward, are they taking a break from work, or deep in thought? Knowing when someone is interruptible with minimal disruption is a huge benefit, and moving an interrupt by as little as a few minutes can prevent the loss of hours of lost productivity.

• Non-Sheriff team members will have more uninterrupted time to get work done, increasing overall team productivity
• The team will be able to finish more work because those interrupts that do come through are positioned at points in time when they are less damaging
• External customer satisfaction will increase, because they will get faster response to their requests
• The team will build a sense of shared responsibility, since they are taking turns as the Sheriff
• External customers will understand that they are dealing with a team rather than a single trusted individual, which helps reinforce the idea that the team is collectively responsible for results
• The Sheriff will have the opportunity to learn about more of the team’s overall responsibilities, which helps to increase backup coverage and create more resilience in the team
• Team members who have been the Sheriff will take learnings from that experience into their work, giving them an incentive to prioritize work that will reduce the pain the next time they “wear the Sheriff hat”

When to use this pattern

When a team is struggling to deliver on planned work due to frequent interruptions.

The interruptions may represent valuable work that cannot be planned, non-valuable work, work that is not the responsibility of this team, or some combination. They may come from external customers or from systems the team is responsible for. Whatever the reason for the interruptions, using a Sheriff will reduce the interruptions for the rest of the team and improve overall productivity, in addition to providing other benefits. 

Related patterns

GateKeeper

SacrificeOnePerson

Illegitumus Non Interruptus

Notes

This is a variant of the On-Call pattern. The utility of calling out this pattern as a variant with a special name is that it creates the opportunity to be explicit about the corrosive effect of interruptions on getting work done. Also, On-Call is usually framed as providing a service to the customer—making someone available to receive a request—while Sheriff is about providing a service to the team, providing someone to remove or reduce interrupts and increase focus time.

This pattern implies the use of the Triage pattern by the Sheriff to evaluate the requests—it is not necessarily the case that all requests (or all alerts) are work that should be done RIGHT NOW. Some things can/should be planned work, and some should be simply deferred or ignored. Thanks to @jeffsussna for the reminder to include this.