There is a recurring story about automation told by those looking at tech from the outside. It is a popular anecdote, and goes something like this:

Lisa is a developer at Initrode. She spent most of her day in databases and spreadsheets, cross-referencing them to create weekly reports the higher-ups needed. After some months doing this, she thought to herself “There has to be a better way!”. So she wrote a program to collate all data sources, perform the analysis needed, generate a PDF and email it on a schedule. Now she spends her time on her passion, rock climbing, and stills gets a paycheck every two weeks!

We’re doing DevOps now. It works. The Kool-Aid is drunk. We talk to robots with cheeky names in chatrooms to deploy new releases of our software. Servers confer with each other to promote leaders and cull low performers. Our task management software learns the cadence of our team and arranges sprints accordingly. Leads are tracked and messaged in branching schemes more complicated than any Choose Your Own Adventure book. This is the promised land.

Yet if you walk into the bullpen of any dev or ops team that has implemented sophisticated automation, they are not needle-felting or learning Esperanto. Odds are there is a TV rotated 90 degrees. On that TV is a list of tasks to complete. Some say you can scroll to the end of the list, but no one has seen it with their own eyes. The story of Lisa at Initrode is a legend. We don’t live in that world.

Automation doesn’t let us script our jobs and focus on more leisurely pursuits. In the same vein, if we’re still flooded with work it probably means that automation will not obsolete us and take our jobs. So what’s the point? Some are drawn to automation because it’s cool. It is, but that’s not enough to justify the sheer amount of effort it takes to properly automate something. Automation helps businesses innovate more quickly. Now we’re onto something. We’ve successfully drawn a line directly from automation to the bottom line. Okay, commence the automation!

Wait, so we should see more creative tasks on our bullpen’s TV, right? But it looks the same as before, only with automation tasks sprinkled in. All extra capacity gained from automation is filled up with ever-increasing demands from product. Without context on strategic goals, it’s easy to fall into automating for its own sake. This isn’t what we thought would happen. What gives?

I think we need to restore the spirit of automation as a means to free people to focus on what we’re good at, being creative. Notice I said ‘people’, not 'non-engineers’. Automation should enable everyone, especially engineers, to pursue more creative work. It doesn’t mean that you can now throw more work at the same group of people. Velocity’s ambiguous relationship to value makes it a poor metric for gauging the effectiveness of an automation project.

In a previous post, I talked about how the current expectations and values in software culture are hurting us, the practitioners. When we really dive into automation it starts to clarify how others view the role of software engineers in an organization, especially in regards to creativity. Namely:

Engineers implement ideas. Non-engineers create ideas.

Here are a couple predictable objections to giving engineers more creative freedom.

1- We’re all on the same team here. Engineers shouldn’t have a problem enabling others in the organization.

You’re right, we should place a priority on helping every team member grow and become better at what they do. If engineering’s reward for implementing automation is just more work, how are we accomplishing that goal? Aligning engineering with business priorities doesn’t mean setting up guard rails. Rather, giving engineers the context they need to come up with novel solutions will make your organization more effective.

2- Engineers are left-brain. They think logically, not creatively.

First off, the right-brain/left-brain split is popular science, not science. It has been debunked time and time again. Let’s stop perpetuating this idea.

Creativity is complex, it’s not just making art. Engineers are often creative in their role. The problem here is cyclical. We don’t give engineers enough time to be creative because we don’t value them being creative in a broader sense than “what database should we use?”. Since broader creativity is devalued, engineers don’t actively practice their 'ideation’ skills.

If you currently see engineers as work units to allocate to implementing your ideas, take another look. You’ll be surprised at the inventive ideas they provide when given the time and context. Encourage ideas from everyone regardless of role.

If you’re an engineer, speak up and don’t accept the assumptions attached to your label. You can be just as creative as anyone else, given the time to do so. Let’s take back the automation conversation and give ourselves some room to breathe.

Automation’s goal should be freeing up everyone to be more creative. Our role at an organization shouldn’t limit our potential to be expressive.