Automating Logistics To Improve Productivity


Getting work done is hindered by logistics. Logistics is work about work. It’s the work you do so that you can get something else done.

For example, there’s a workflow I use to create a podcast. Most of that work is logistical: creating a collaborative script document from a template, inviting guests to a recording channel, scheduling the recording, coordinating sponsor content, updating the production calendar, editing the episode, writing a blog post about the episode, and promoting the episode on social media.

Relatively little of the workflow is what I consider the meat of podcast creation: researching the topic and guests, writing interview questions, and recording the actual show.

I draw the line between logistics and meat by considering what I can delegate vs. what I need to do uniquely myself. Most tasks can be divided along this line.

Solving The Logistics Problem With Delegation

One way to boost productivity is to delegate logistics. Delegation frees up your time to focus on the remaining tasks requiring your unique skills.

Delegation comes in at least three forms.

  1. Humans.
  2. Software.
  3. Automation.

Some tasks can be delegated to other humans. In my case, I delegate many tasks in my business to consultants, contractors, employees, and my personal assistant. I still have to manage those relationships, and I have to compensate people for their time. Delegation doesn’t absolve me of task responsibility.

Delegating to other humans is challenging, creating process and interpersonal debt. You might welcome such a difficulty, but find that you aren’t in a position to delegate other humans. You still have delegation options.

In the digital age, delegating to software is self-explanatory–we all do this. As an aside, while I believe in delegating to software, I also believe in delegating software infrastructure. In my business, there is no advantage to be gained by hosting software myself. I delegate software hosting to a mix of SaaS and IaaS infrastructure providers.

Automation steps in where humans shouldn’t and software can’t. Tedious, repetitive tasks are best done by carefully programmed robots.

Software can’t predict all business workflows–businesses are unique, meaning software has limited task granularity out of the box. Software designers can’t create an overly specific product and still retain mass appeal. This is where automation steps in. Automation is the workflow layer on top of software that performs repetitive tasks quickly and predictably.

Delegating To Automation

In my own workflows, I’ve identified automation as the weak link. I’ve passed off as many tasks to other humans as appropriate. I continually review and revise my software tools. However, I don’t automate.

For instance, to prepare for a podcast recording, two of the steps are to create a Google document from a template, build a Slack channel, and invite the guests to both. Accomplishing this is a lot of predictable clicking and typing.

Google Drive has an API. Slack has an API. Why am I interfacing with Google Drive and Slack using the clicky-clicky GUI? Because it’s what I know. It’s easy. It’s time-consuming and error prone, but it gets the job done.

Automating these tasks seems too painful, because I don’t know how to write the code off the top of my head. I’ll have to read documentation, write some code, experiment, and fuss.

Will automating those document and channel creation tasks be worth it? The answer to that question comes in the form of time saved. How long does it take me to clicky-clicky and get these tasks done? Let’s say it’s twenty minutes. I don’t know exactly how long the actual clicking takes, and the reason is that there’s more time to account for than the click time.

There is also distraction time.

When I go into the standard Google Drive UI to create a document, I see a myriad of other folders and documents related to projects I’m working on. I’m reminded of other tasks I need to complete. The temptation to move orthogonally into another task is significant when my to-do list is long.

The same distraction exists when looking at Slack. Even though I squelch almost all notifications, opening the Slack interface to work on channel creation and invitations can take me far afield.

Because of distractions, twenty minutes becomes thirty or forty. Distractions eat the day away. Distractions cut into productivity. Therefore, automation isn’t simply about making clicks go faster. Automation is also about retaining focus by reducing distractions.

A script that gathers a bit of information from me can handle Google doc and Slack channel creation with a single command, instead of me performing a bunch of distractable clicking. Creating the script will be hard, but the result will be time saved and focus retained.

What about IFTTT or Zapier Instead Of Code?

What if I don’t want to read API documentation and write code? Might trigger-based tools like IFTTT or Zapier help? I believe the answer is “yes,” but there’s homework to do to know how much.

Historically, I’ve used both IFTTT and Zapier to automate straightforward tasks like posting to social media based on a RSS feed trigger. However, I’ve found both Zapier and IFTTT, powerful though they are, to be constrained. I can only execute the actions that they support, and the entirety of an platform’s API is unlikely to be exposed to an IFTTT recipe or Zapier zap.

Therefore, I’m leaning toward Python as a programming tool with comparatively infinite flexibility. With learning time invested in APIs, I can write Python scripts to do any action I need.

Writing my own code offers another interesting possibility: chatbots. That is, I can log a chatbot into Slack and issue automation commands to the chatbot from the Slack interface. This is desirable from a business workflow perspective, because it means actions are logged in an observable Slack channel, keeping the other humans I work with in the loop as to what automated work is being done.

About the author

Ethan Banks

Most people know me because I write & podcast about IT on the Packet Pushers network. I also co-authored "Computer Networks Problems & Solutions" with Russ White.

Find out more on my about page.


Most people know me because I write & podcast about IT on the Packet Pushers network. I also co-authored "Computer Networks Problems & Solutions" with Russ White.

Find out more on my about page.

Subscribe via Email

Receive complete, ad-free posts in your inbox as I publish them here.