Service cookbooks.

Project selection is very much like optimizing system performance: if you aren’t measuring, then you’ll fix the wrong things. If your team is underwater and looking to dig its way out, the first thing to do is to set up analytics to understand where your team is spending their time.

Most approaches to instrumenting time allocation require a large time investment from your team to track tasks, which somewhat defeats the plan goal to save their time. One approach I found to work very well, without requiring major workflow changes by your team, is creating a simple internal website that contains your team’s service cookbook.

This cookbook lists every task or offering your team performs, and can provide documentation and collect per-task required fields to reduce back and forth between asker and askee due to missing information. Each of these asks can be instrumented to determine the number of incoming requests, and is also an automation vector where you can gradually move each task’s form from submitting a ticket to immediately performing the requested action.

The service cookbook is probably the single highest impact tool I’ve found for reducing entropy as it allows:

1. Analytics on all incoming requests, which allow you to prioritize automation projects.
2. Reduces back-and-forth on each request, which reduces concurrent requests and maximizes time spent solving problems.
3. Documents all your requests, forcing you to have messy ownership discussions early.
4. Once engineers are used to coming to your cookbook to file requests, you can simply drop in automation there to fully cut yourself out of the loop, without even needing to have them learn a new behavior.

The other nice thing is that you can start with just compiling a JSON or YAML into a simple Bootstrap website, so it’s the kind of thing you can do over a weekend.

Overall, the service cookbook concept is a good example of designing interfaces that remain usable across multiple generations of implementation: easy for you, easy for your users, and good for all.

This was originally a section in Productivity in the age of hypergrowth but it never quite fit, so I pulled it into a standalone post.