Power, spin, or control?
What buying a tennis racket can tell us about identifying process at work
A few weeks ago, I visited a store to purchase a new tennis racket. Though my brother and I took lessons together in our tweens, I only recently regained the requisite level of proficiency to properly utilize a more expensive racket.
Unfortunately, I quickly realized that being able to use a racket is not the same skill as being able to buy a racket. I started (innocuously, I thought) by asking the salesperson if I could see some rackets.
“Sure! Any racket in particular you’re interested in?” he responded.
“No... I was hoping you could tell me.”
In the salesperson’s discomfort, I sensed that I had deviated in some significant way from the typical racket-buyer’s process. “Well, do you like power, spin, or control?”
“Not sure, what do you think?”
Now the salesperson was growing visibly flustered. Over the course of a few minutes where he tried to explain the differences between the various racket types, we finally arrived at a set of rackets that might work well. The whole time, the salesperson seemed ill at ease, glancing around as if looking for help or wondering if I was playing a kind of practical joke.
Looking at the prices of the 3 rackets we had chosen, I realized I wouldn’t feel comfortable paying unless I had actually used the rackets in a game. So I asked the most natural question that came to mind: “is there any way I could try one of these out?”
The change in the salesperson’s demeanor was startling. Immediately the tension melted from his shoulders, and his voice grew more confident. Somehow, we had returned from the wilderness of my tennis naivete to the well-trodden paths of veteran racket-buying.
“Sure, we have a demo program. All I will need is a credit card and some ID.” He proceeded to rattle off the price of late payment and to show me the demo rackets in stock.
As I left the store that day, I reflected on something fundamental about business. One of the best ways for businesses to unlock value is by recognizing common processes. This applies both at the level of the entire enterprise—think of a shoe factory manufacturing 20 standard sizes instead of a cobbler manufacturing a custom shoe for each customer—and in day-to-day operations—think of an HR team adopting an applicant tracking system to for their recruitment pipeline.
Someone at that tennis store had put in time to deeply understand and document the standard process of buying a racket. They then provided those steps to this salesperson during training. I imagine the training said something like this:
When a customer walks in to try a racket, assure them that we have that racket in stock or have the ability to acquire it
Suggest 2-3 rackets that are in the same class: power, spin, or control
If the customer is struggling to make up their mind, offer to let them demo 1-2 rackets
When they return the demo racket, ask them what they thought of the rackets
If they seem interested in buying the racket online, mention that rackets from online do not come prestrung, but we offer complimentary racket stringing and complimentary overgrips
When I walked in and failed step 1, the employee tried to put me on step 2. At that point we had gone completely off script, but I managed to accidentally return to the script in step 3.
Let’s attempt to formalize. There are three senses in which recognizing a process can be helpful, from least- to most-impactful:
Reducing cognitive load
The lowest-impact but easiest process to implement is one that we apply to our own work. For example, Steve Jobs purportedly began dressing in the same outfit every day because he realized he was wasting a few minutes every morning trying to decide what to wear. By creating a simple rule to handle that process, he saved his mental energy for complex tasks like designing the iPhone.
Most of my processes in this vein use templates or pre-created components, for example:
Technical interviews: I copy and paste a pre-created question into HackerRank
Onboarding new team members: I have a standard first meeting agenda that includes topics like “how can I request vacation?” and “how should I think about 1-on-1s”?
Writing design documents: I use a standard template from our company Quip
Figma mock-ups: I use company standard components to avoid spending time on fit-and-finish
PowerPoint presentation: I use the company templates to get branded content
Leveraging less-skilled labor
My visit to the tennis store was another example of the second kind of process: leveraging less-skilled labor. Whoever wrote the tennis store’s training manual would have been easily able to handle an unusual customer like me. By writing a training manual to equip a less-skilled salesperson to handle the vast majority of (easy) customers, that person freed themselves to do more complex work, like negotiating agreements with suppliers or hiring new team members.
When I worked at Azure, one of the ways we used this kind of process was in customer support. Product engineers with their deep knowledge of diagnostics and source code could resolve customer-facing issues quickly, but we needed our product engineers developing new capability and only working on support in cases where customers were experiencing legitimate bugs. So we adopted a tiered model:
When customers report an issue in the Azure portal, we guide them through a series of self-service resolution steps
If the self-service resolution fails, we ask the customer to submit a standardized form with diagnostic information and to grant the support engineer temporary account access
If the support engineer is unable to resolve the issue, they escalate to the on-call engineer
If the on-call engineer is unable to resolve the issue, they escalate to their entire team
By making the product teams the last step of the support process, we ensured that less-specialized support engineers would attempt to solve any problem before it made its way to the product teams.
A note of caution here: only the product teams that accurately understood how customers used the product and fixed the product would actually benefit from the support process we established. Product teams who poorly understood user needs could actually end up worse off: writing misleading troubleshooting guides that annoyed customers and produced an avalanche of unsolvable support tickets. That’s why we only implemented this process for mature products. On products with fewer than 10 users, we wanted product teams providing customer support, so that they could write useful troubleshooting guides.
Automation
And finally, the holy grail - automation. Some processes are so standardized that they can be completely offloaded to machinery. Think of the stars of the Industrial Revolution: the cotton gin, the mechanical loom, and the steam engine.
Examples in the world of bits include spam filters, search engine indexes, and continuous integration tests. One example of a completely automated process that I have been personally impressed by is the way Anduril provisions non-sensitive repositories. Someone on our developer infrastructure team realized that the process of setting up a source code repository looks like:
Create a repository
Answer a set of questions to determine what regulations the repository might be subject to (if any)
Add a set of team members as admins
Create an Elastic Container Registry (ECR) registry for the Docker containers built by that repository
Create a token with least-privileged access to the new ECR registry
Create a new Circle CI project for the new repository
Store the token as an environment variable in the new Circle CI project
Copy in source code from one of our example repositories in that language
They built a service that completely automates all of these steps without requiring any intervention from a member of the developer infrastructure team.
Recognizing it
As I hinted at above, the first step to establishing a useful process is recognizing that it exists. This requires that individuals with the ability to create process (usually more senior team members) consciously create opportunities to recognize processes.
For processes that our customers engage in, two of the most useful techniques are usability tests and journals. Usability tests can help recognize processes that require less than an hour. For example, if I am a Salesforce admin looking to automate lead qualification for the sales team, I could set up an hour to observe how a business development representative manually assigns labels to customers in order to categorize them correctly in Salesforce.
If I were instead trying to help speed up the processing of security clearances (this is a topic that is near and dear to me at the moment), I could ask a security clearance investigator to document every step they take in order to complete an investigation. By looking for patterns in different officers’ journals, I could determine the process that officers are likely to engage in.
For processes that we ourselves engage in, observing someone else may not be possible (if I am the only one participating in the process) or sufficient (for example, if I have been doing things the same way for years and therefore inured to all of the tedium). In those cases, you have enough observations of the process; you just need to disengage for long enough to find the patterns. Amazon founder Jeff Bezos famously budgets time at the beginning of his day to “putter”. Though most of us don’t have executive assistants to block our calendars for us, we can consciously create space by exercising, meditating, and spending time with loved ones.
By making a habit of observing and formalizing the processes that we and our customers engage in, we can keep ourselves and our teams available for creative work and minimize drudgery.