Image via wocintechchat.com
A year or so after I joined the Trello team, I was catching up with my former boss, Rich Armstrong, about how things were going in support at Fog Creek. He was surprised that the support team—which he no longer managed—was thinking about ditching the random assignment script that he had implemented years earlier. He realized that the why behind the script had become divorced from the implementation, making the process vulnerable to being removed or replaced.
If you work in the startup space, you probably have automated processes all over the place. Awesome! This article is about how values, process, and automation play together; how to document them; and why they’re useful when processes change.
Let’s start with why process is important.
Process takes understood values and turns them into a repeatable form. The natural evolution of process is automation. Put another way:
Values provide constraints for how to operate
Process reinforces and embeds values
Automation deeply embeds processes, and thus values, within the organization.
Thus, when we automate processes, we embed values into the everyday work of our team. Let’s take a look at an example first and then look at the importance of documenting our values, process, and automation.
Example: Random Assignment Script
I’m going to use the random assignment script as an example. The script assigns tickets from the support inbox to the various members of the support team as they come in. Let’s say you have 100 tickets and 4 members on your team. The script will assign 25 tickets to each person. Contrast this to the way most support teams operate, in which each team member is simply expected to be "in" the queue, usually starting in a shared "unassigned" folder and working oldest to newest.
Let’s look at the values, process, and automation behind the script. Since a lot of automated processes exist in the wild without documented values, we’ll start with automation and move backward:
Automation: The automation is a Python script that runs every 15 minutes to distribute cases. No one has to think about it. It just happens.
Process: The process that is being reinforced is dispassionately distributing cases as they come in, based on a specified load. If a human were doing this task, he or she would triage each case and round robin the cases to the various members on the team.
Values: There are multiple values, so let's list them out:
No Cherry Picking. Cherry picking, that is, eyeballing the support queue and picking the next case you work on, costs extra mental energy in having to decide what to work on.
Equal share of knowledge gain. Some agents are faster than others, so left to their own devices, they might work on more cases than other agents. While that's not in itself a bad thing, the fewer cases the other agents see, the less overall knowledge those agents will have about support and the product. It's not just about fairness (though that applies)—it's also about making sure everyone gets an even share of the knowledge that comes from doing support.
Distributed knowledge. In addition to the volume of knowledge, you also ensure that each agent gets a wide variety of exposure to the product and support. E.g. no one ends up with all the Windows Phone cases. You reduce the need for specialists (which aren't bad, but can unnecessarily affect your "bus factor" if you don’t need them).
Continuity of care. By assigning a case to an agent as it comes in, we ensure that the same agent is going to care for the customer throughout the life of the ticket. This avoids the customer feeling "passed off" and helps a single agent deliver a ticket to full resolution.
Now we know why the random assignment script exists. Now let’s look at how and why to write it all down.
Write it Down
In the case of random assignment, Rich had documented the underlying values years earlier on the Fog Creek blog, but the current support team didn’t know about it. When automating processes, document the values in a place where future custodians of the process can easily find them. Here’s how we do that on the support team at Trello.
We have a Trello board set up to document the automated processes. On the left, we have "possible ideas for improvement", which is everything we might work on if we had the time and it made sense. On the right, is everything that’s already in production, organized by where it lives.
When specing out possible ideas for improvement, we document the values, process, and automation first so we know why it makes sense to do it. Then, when it goes into production, we can look back and see why we did it.
A good next step—which I don’t believe we’re doing—would be to link back to the values from somewhere within the source code or wherever the automation piece happens to be implemented. That way, if for some reason the person reading the code doesn’t know about the underlying values for why it’s there, they don’t have to look far to find them.
Changing Process: Look at the Values
Why is all of this stuff important? If you’re a small startup and you can keep all of the values in your head, this may be overkill. You can do the mental math in your head without thinking about too much. "Let’s just change it" may suffice. If you’re getting beyond the “small startup” phase or if you’re not sure if a process should change, this part is for you.
If your values are documented, when someone suggests a change to process, ask what values underlie that process. Take the values from your current process and the values from the suggested process and prioritize them. Which are most important? If the values from the suggested process win out, you should go with the suggested process or modify the current process to prop up those values, assuming of course it makes sense to spend the time to do so (more on that in the next section).
For example, if the support team adds a new value of "provide a near instant response to paying customers," and if that’s more important than every other value associated with the current automation, the random assignment script would either need to change or make way for a different process that supports faster response times to paying customers.
Bonus! The Process Part
If you’re like me and you like automating things, it can be really easy to jump all the way to the end and start writing code. The automation part is probably easy to write down ("this code does this thing") and perhaps even the values are easy to write down (“this is why this hacky script is important”). It may be just as easy to skip over the understanding the un-automated process, but don’t do it. There’s a huge benefit to thinking about the process part by itself.
Try to answer the question: How would a human manually do this process? There are several reasons to use this as your starting point.
First, for a project that requires a lot of time writing code, you might want to test it manually before investing the time to automate it. When doing the process manually, are you getting the value of it that you expected? If not, it doesn’t make sense to automate it.
Second, if you’re trying to decide if it’s worth spending your time (and therefore the company’s money) automating a process, being able to understand the cost from a manual perspective let’s you understand when you’ll get a return on the company’s investment. E.g. if it costs $75/day to do it manually and $750 to automate it so the subsequent process costs virtually $0 per day, you’ll get a return on your investment after 10 days and save around $20,000 per year going forward. If that’s more valuable than other potential ways to spend your time, it’s time to start coding.
There are of course processes where you would say "if we had to do this manually, we’d never do it," but you can still do some back-of-napkin math to help you weigh whether it’s a good decision from a business perspective.
Et Cetera
On the support team at Trello, we don’t document the values behind every single thing we automate. We have a ton of stuff in Zapier that’s there "because it just makes sense", such as the language detection script. Nobody has to think very hard why it’s useful and the cost to implement and maintain is very low. For philosophical processes such as “how to automate the support queue,” writing down the values is more important.
I can’t remember who at SupConf (May 2016, San Francisco) suggested I write this post, but thanks for the suggestion!
Thanks also to Rich who planted the original seed for this post in my head (and appologies if I misremembered any part of our conversation).
Kate Heddleston’s blog post about The Null Process is excellent and a good counter argument to the comment "We don't want to introduce any unnecessary process."