This is a companion post to my talk for Women Who Code Cloud.
If you’re an infrastructure engineer or an app developer, standing up new infrastructure looks something like this:
App dev team puts in a request for say a new storage account or key vault, it goes to the infrastructure team but it’s competing with the priorities of other teams that the infra team is also doing work for. It goes through the prioritization process, gets into a sprint, the work gets done and goes through QA and finally app dev has their storage account.
But what if it didn't have to be that way?
What if instead you could do this from the comfort of Slack or whatever your chat app of choice is.
When the request is made to the bot, it makes a POST request to a repo and adds the code needed to make the new storage account, the changes are then detected by a pipeline and Terraform plan runs, if this is successful, a pull request is opened for infra team’s review and approval. Now this would be great, but we can’t pretend setting up the infrastructure for a chat bot that makes secure calls to your repos doesn’t require some up front effort. I don’t know about you but when I have asked for something like this in the past, I usually got:
By the end of this you should be able to:
- Have a place to start with your own automation journey
- See a clear path to making the business case for building more robust automation tools
There are three themes to the examples I'm about to share.
- Visibility: Automation and especially when we get into ChatOps, makes things happen in the open. If I use a chat bot to make a new storage account, there's a record that I did so and it's in a very visible place. It also puts information in the path of the user. If multiple people are working on creating resources, it's not just happening on our individual terminals. It's happening in a place where we can all see it.
- Repeatability: Automation happens exactly as you code it the same way every time. As long as you code it the way you want to, this is helpful. There's no concern of steps getting skipped because the machine is doing the work.
- Deep Focus: By putting automation in place, humans can skip some of the mundane steps that require us to context switch. This will be especially apparent with the example of pull requests. Less context switching means more deep focus on the tasks that require complex human thought.
Keep these in mind as I walk through the examples.
The plan here is to:
- Automate the squishy things - the agile processes, the people processes
- Use the same tools to automate thin slices of code things
- Use those thin slices as Minimum Viable Products or Proof of Concept cases for building more robust automation tools
Automate the Squishy Things
Reminders
As I mentioned in Personal Automation: A Primer, start with reminders.
In both Slack and Teams, I set up reminders to check in on retro action items and show and tell topics. This was visible to the whole team (visibility) and set on a weekly cadence (repeatability). It also happened automatically and sat in the channel and a frequent reminder that was there whenever we next looked at the channel without breaking our focus (deep focus)
The show and tell reminder evolved. I added instructions on how to generate the Polly poll (repeatability) so we could vote on topics and linked to the spreadsheet where we put suggestions for topics (visibility).
We also had the On Duty Service. This was a channel in Teams where application developers or just any wayward soul in search of answers could post questions or ask for support. This service required some onboarding. We had operating hours, two developers from the delivery ecosystem team were responsible for monitoring the channel, and we had a series of questions to help diagnose issues. Thus, we created a video to help folks become familiar with how to use the On Duty Service. All of this was posted each day when the service opened (visibility, repeatability).
Included was a link to the short intro video and a list of the questions that folks could answer to help us diagnose their issue. This was also helpful for our team because then we knew when requests happened within operational hours (deep focus). Likewise, we had a closed automation.
We also had a notification that let folks, including our own team, know who was responsible for on duty that week.
It served as a reminder for the other tasks we did alongside having the On Duty Service anchor responsibility.
Habits & Routines
Another process we automated was the rotation of who hosted standup each morning. Initially, it was a manual job. Each day every person on the team would have to check the notebook to see if it was their turn to host. It also meant going into the notebook and rotating the person who was due to run it. We spent a minute or two each morning trying to remember whose turn it was. It was a fair bit of cognitive load, wasted time, and annoyance.
Because this was a repetitive task (repeatability), I set up a spreadsheet that listed the folks in rotation, their email address, their ID number and if it was their turn to run standup.
I wrote an automation that pulled from the spreadsheet of all the possible presenters, tagged the person who was supposed to run standup, posted the list of who was next, and rotated the list 30 minutes before standup (visibility, deep focus).
Pull requests (PRs) were another place where we set up automation. Anytime a pull request was opened or closed on a watched repository, it would post to the PR channel (visibility, repeatability). This meant that if we were working on code, we could push the last of the code, open a PR and go back to coding without falling into the trap of context switching to the chat application. Chat applications can be great for sharing knowledge, but they can also become a time suck if you get into reading through unanswered messages. Automating the PR posts meant we could stay in deep work mode.
Another channel we had was stories that needed further technical refinement or review. The first pass at that automation posted a story to the channel anytime it was added or updated and had the tag "Needs grooming" (repeatability). That unfortunately made the channel very noisy. So I refined the automation. I did not just nix it altogether. I noticed that stories might have details that change but major updates to stories didn't happen frequently and we had a lot of stories that needed review. As a compromise, we shifted the automation to post to the channel twice per day. The automation itself was a bit more complex that previous automations I had built. This automation ran a query to find the stories that needed to be reviewed and formatted them with links to the stories and posted to the channel. That meant when someone wanted to schedule time to review stories, they had a list at their finger tips in the channel, but didn't have to be pinged directly about it (deep focus).
When did I do this work?
https://imgs.xkcd.com/comics/compiling.png
I did a lot of this 1% at a time. When I was waiting for a plan or apply to run in the pipeline, when I was waiting for a meeting to start, or when I had 10-15 min after one meeting before the next one. I would fix a bug and then head in to a meeting. I would start the bones of an automation, save it, and go back to writing code for my assigned work.
Use the same tools to automate thin slices
I shared with the team as I added new automations around our workflows. Not too long after I started building these out a person on another team asked if I could help him with some automation. He had noticed a repetitive task and figured he could make it easier on his team. They were dealing with a bug and didn't have a clear ETA on when it would be fixed, so they were solving the problem manually for the time being. He wanted to be able to send a message to a specific channel and have it remove a “ghost task” from the system. A ghost task was a task that had died but was not removed from the system. One of the advantages of ChatOps is that there’s auditability/visibility and the coding/calls are happening out in the open in a chat channel. So it’s not just someone on their terminal sending curl commands, it’s tracked in the chat who is doing what. Then, if something goes wrong, it’s easy to track back through the chat and see what happened. He was excited at the possibilities of what could be done with the automation.
We got his automation working and his team was able to remove the ghost tasks from the system via sending a message in chat. This meant they could see when each of them was removing a task. They didn't step on one another's toes because if Bob was removing task A and Alice was removing task B then Charlie knew he didn't have to take care of either.
This is what I mean by a thin slice. It is a complete circuit of work that provides value. They used Microsoft Power Automate to do it. It didn't require deeply complex infrastructure. However, to build out a full chat bot that can modify code repositories, that likely will require investment in complex infrastructure.
Use those thin slices as MVPs
That's where the final step comes in. Making all of these processes visible and demonstrating the value quickly means you can amass the data you need to make the case to powers who control the schedule and money. By starting with the squishy processes it also more relatable to folks who don't work with code on a daily basis. Now when you say, "I wanna do that but with our code."
Where to start
- What tools do you have available? Is it teams? Power automate? Slack?
- Experiment on yourself: I have a post about starting with personal automation. Create a private channel in Slack or Teams. Create your own shortcuts. Then, when you share with your team you can say, "I've used this myself."
- Start with the basic stuff: Reminders - think right now about 2 reminders you could set in your chat channel.
- Take your in between time to automate the simple stuff and then gradually add some more complexity.
- Make it visible: Find opportunities to showcase it to others. Look for opportunities to help others automate their process.
To keep up on more posts like this, subscribe to get them sent right to your inbox below.