Automation doesn’t have to be all or nothing. Automating manual processes is a practice that one can employ via simple principles. Broad enough to be applied to a range of workflows, flexible enough to be tailored to an individual’s personal development routines; these principles are not in themselves complex, and can be performed regularly in the day to day of working in a codebase.
Learn how to cultivate habits and a culture of incremental automation so even if the goal is not a full self-service suite of automated tools, your team can begin a journey away from friction and manual tasks.

== The Details
This talk will describe principles the audience can employ to improve painful manual processes and introduce automation into their, and their teams', workflow. These principles are not in and of themselves complex, and can be performed regularly throughout the day to day tasks of working in an application's code and infrastructure. With even infrequent use, they will slowly layer in automation to reduce the friction of manual tasks for a project. The goal of these principles is to develop habits and a practice so that even if they never yield a full self-service automation suite, the practice will allow for valuable enhancements for nearly any project. The principles are broad enough so as to be applicable to a wide range of workflows and tailored to suit an individual's personal development practice.

- Document the manual processes
* Every manual action should generate an artifact or potentially improve an existing one as well as completing its task
* avoid the decision paralysis of deciding if something is worth documenting by documenting everything
* find low-friction paths to introducing new documentation

- Small improvements are large in aggregate
* Without the cognitive load or productivity cost of drastic changes or large amounts of work
* any small improvement is an improvement nonetheless

- Collaborate early and often
* if the goal is many small improvements making drastic change, many small improvements from many contributors decreases the time it takes to reach those heights.

== Outline
We'll explore the idea of incremental automation and the practice of automating by using practical examples and these steps. This will be the majority of the time of the talk, and we'll derive the principals from the examples by the end.

I. Document the manual process

* documentation is code, the person reading the documentation and performing the tasks is the CPU. You are the CPU.
* the documentation is the pseudocode that will eventually become the automation

II. Use the documentation to perform the task

* even if you wrote it, referring to and using the documentation will iteratively lead to it being more clear
* because "you two weeks from now" is essentially a different person from the you that wrote the doc, you'll be able to iterate on making the steps more clear
* edge cases and error handling will likely arise as you use the doc more than once

III. Make the documentation into a script

* I like the gem "runbook" by braintree, but it can be as simple as a bash script or a plain ruby file etc.
* each step in the doc should be a prompt on the screen, and require input from the developer doing the tasks to continue

IV. Check the script (the living version of the documentation) into version control

* this is now the source of truth for this process, if it was in a knowledge base system like confluence, link to the script
* at the start, the documentation and the script should look very similar, with a little bit of code syntax interspersed
* the sooner you collaborate, the sooner the rest of the team can contribute

V. Identify which step to automate first

* any number of heuristics can make this choice. easiest to automate? worst pain point? most error prone? you do you.
* If there is a step that is "copy paste this code into the terminal" that's a prime candidate for automating it, you already have the code written
* next time you run the script, you'll do one less step!

VI. Continue automating as time and need allows.

* never get the whole thing automated, but it's 50% there? that's 100% more automation than you had before! (someone check my math)

====
While it is widely applicable, the audience I hope to reach is that developer or team who is bogged down in manual processes. Often those manual processes seem un-automatable, or that the time can't be spared to go off to yourself, away from feature work, and craft a wholly behind-the-scenes script or automation. I intend to give them the tools, and the permission (become sometimes all you need is for someone to say something you're already thinking), to not have to deal with the all-or-nothing automation and build up that support over time, step by step.

== The Pitch
Practicing automation is valuable across a wide range of projects and applications. Some teams have huge processes that take a great deal of time and energy, and returns on investing in automation will be powerful, and some teams have small tasks that could also be automated. The small tasks might not lead to monumental results, but automation can still provide value in both arenas.

These practices and techniques were used by a product team I worked with to wrangle several of our manual tasks into manageable automated systems. We have "battle tested" these ideas and they added a lot of value, and even avoided burnout of some of our team. I'd like to impart some of what we learned, not just from 20,000 foot view, but from our experience actually implementing this approach. Our specific examples might not be applicable to every team or situation, but we have demonstrated some process or workflow for dealing with issues that arise putting this concept to work.

First Public Delivery: RubyConf Mini 2022 (Providence USA)