Eliminating Toil
You should probably not automate <i>all</i> toil. You should only automate toil when the toil cost&#x2F;effect is more burdensome than the cost of automating it. All automation has a cost, and may or may not create value. Automation should have a positive and timely return on investment. If the ROI is 10 years down the road, you probably shouldn&#x27;t automate it (yet). If there is a cheaper way to deal with the toil, explore that avenue first.<p>Several times in my career I worked on projects to reduce toil. Sometimes the project would fail because the time it took to work on them went well past the cost saving estimation. Sometimes they would be completed, but the value created was far less than their cost. And sometimes automation wasn&#x27;t even the solution, and we just needed to change our process or system, or do some other manual thing that reduced the toil cost. Sometimes we chose to automate toil because we were afraid to take on a larger project we knew would make the toil unnecessary, so we paid for the automation and then later for rebuilding everything. Or toil was used as an excuse to justify a project that didn&#x27;t really have to do with toil.<p>One of my biggest mistakes as an engineer was assumptions I made about my work that ended up creating more waste than value. Talk to an outsider about your plans and why you&#x27;re doing it, take their advice seriously. And if your automation is optional, make sure you have buy-in before you start working on it; i&#x27;ve sunk months on things that nobody ended up using.<p>A great way to automate toil is incrementally. Typically you have a runbook with step-by-step instructions, and over time you automate one step, then another, etc. The investment is minimal and gradual, it can change over time, and you can target the costliest parts of the toil, optimizing value.