A mistake I see many people and teams make is that of assuming that an automated task will look like the manual task, only automatic.

But this often isn’t true.

Consider baking cookies. If we were to automate this process the same way we do it manually, it would require a humanoid robot. One which can hold a bowl of dough while mixing, and with hand-like appendages that can roll dough into balls, and arms to open the oven, and place a baking sheet, etc.

But automated cookie baking looks a lot different than this. It may involve a conveyor belt oven, for example.

Automatic orange juicers look a lot different than manual orange juicers.

Automatic mail sorting and manual mail sorting look completely different.

Until very recently, automated vehicles looked entirely different from manually-driven vehicles.

Yet many people assume that their current manual process will look exactly the same once it’s automated, only it will be faster.

When teams are automating software development tasks, such as testing, or deployments, I see this frequent automation. But it’s often wrong.

Teams that successfully automate deployments with continuous delivery, for example, don’t simply automate the task of manually verifying changes. They actually change the shape of their software development process. Often to the point that they write their automated tests even before writing the code that makes such tests pass.

Teams that successfully automate scaling of their apps adopt new application development patterns that account for this new automation. 12-factor apps, Kubernetes, Serverless, etc. They don’t just automate the old process of manually deploying servers and installing software.

If we were to simply automate our existing manual processes, we’d have a complex, fragile, and slow process that’s just being done faster than before. That may be an improvement (so long as the complex, fragile system continues to work), but it’s far from ideal.