Want to Improve Your Software Team’s Efficiency? Automate

The quickest way to boost efficiency in your development pipeline is by reducing manual tasks. And that requires thoughtful, effective leadership at every step in the process.

One thing that all high-performing software development teams have in common is a commitment to automation. Yet despite its power to level the playing field by helping teams produce almost unbelievably outsized returns (440x the number of releases, 5x failure rate reduction, 3.5x more source lines of code written), many organizations still struggle to scale it.

In our experience the biggest blockers are cultural, rather than technological. You may even be unwittingly scuttling your team’s automation efforts through some fairly benign leadership activities. Getting efficiency wins out of automation means being intentional about promoting cultures of sharing, overcoming leadership next-time-itis, and preventing over-optimization.

Promote Cultures of Sharing

Early automation efforts often involve pretty crude tools that can be embarrassing for authors who pride themselves on well-architected system design. But progress is better than perfection. The power of these early tools is that a wide group of people can leverage them, increasing the return on the investment necessary to create them.

Initially, the most reused automations might be command line tools or even browser plugins. Eventually, though, as certain automation tools gain popularity, they will become stronger and more polished through group contributions.

Creating safe spaces and forums for publishing tools will encourage people to share more, and early efforts here will slingshot you to long-term success.

Want some quick wins? Create repositories where engineers are encouraged to check in half-baked tools, organize a company hackathon around automation, and promote successes by handing out monthly awards to teams that share automation wins.

1. Create a tool repository

Creating a place to share tools and plugins that everyone understands are “use at your own risk” will encourage developers to check in tools that can be re-used by others without the critique. It will also help you get some valuable IP off of your developer laptops and into some form of repository. As it grows, management of the file structure and index will become an issue, so create a small group of custodians who publish updates and groom the tools list.

2. Encourage teamwork

Group settings and sponsored hackathons can be a great way to promote a culture of automation. Rather than trying to lead the discussion, let the engineers pow-wow and self-prioritize. But support the initiative with opening thoughts, demos, and prizes.

3. Promote successes

Some of the best results we’ve seen for automation efforts come from recognition of success. Make simple awards for things like “most used automation” or “most used tool” or “most minutes saved” and hand them out to your top developers on a monthly basis. Remember that remote teams often suffer in these activities, so brainstorm ways to include them, too.

Overcome Leadership Next-time-itis

Here’s the traditional automator’s dilemma: It takes two hours to complete a task and two and a half hours to write a script to execute it. The likelihood of your needing to do that task again is 50/50. Do you write the script to automate it? What if it takes two months to complete and four months to automate?

In the ongoing quest to save time and increase efficiency, it’s easy to recognize a good idea for optimization but put it off to focus on the task at hand. As the thought process commonly goes, there will always a next time when you can address the problem. But high-performing organizations will opt to automate whenever and wherever possible. A healthy automation culture needs support from all levels of management, and keeping a keen eye on what your team is doing and asking “Could we automate that?” constantly is a good first step.

Eventually your teams will be asking you for some space to automate tasks. When they do, you’ll need to have a method in place for identifying your pain points, tracking your automation metrics, and evaluating your automation options.

1. Be intentional about evaluating automation

When a team member suggests that a task be automated, take them seriously. Rather than nod and think, “Wouldn’t that be great?” take the time to really consider it. Ask yourself questions like, “How would I do that? What is my team’s process for making that happen?” At the very least, create a backlog that you can reference when you move on to the next step.

2. Figure out where the most pain is

Now that you’ve committed to moving forward with automation, it’s time to identify where best to allocate your resources. Gather your team and hold a brainstorming session to catalog all of the tasks they do manually, and then begin tracking them over the next sprint to determine where your pain points lie.

3. Determine your coefficient of automation

With the data from your task-tracking exercise in hand, you’re ready to measure the efficacy of automating a task by determining your coefficient of automation. (There are, of course, other benefits to automation, like increased quality and reduced errors.) In the most efficient teams, as the quickest wins start to produce more efficiency, these numbers become smaller and smaller. In other words, while at the beginning teams may consider automating large, very frequently executed tasks that are quick to automate, high-performing teams are automating small, infrequently executed tasks that take a while to automate.

Here is a worked example.

Given:
X: time it takes to do a task manually
Y: time it would take to automate the task
Z: time it will take post-automation
n: expected number of times the task will be executed in the next 12 months.

Y+nZ < C(nX)

Solving for C:
C = Y+nZ / nX
This tends to C=1 in the most high-performing teams.

Prevent Over-optimization of Solutions

When engineering teams are evaluating how and what to automate, they’re often encouraged to design systems that can handle multiple use cases. In theory, this is a sound approach, but when done too early in the automation journey it can result in over-optimization: What could have been a simple tool balloons in scope to become a complex platform.

You want to avoid this natural impulse at all costs; your team will learn a lot from the exercise of getting something small working, and the gains in efficiency will establish a baseline you can use to assess whether a more robust tool is worth further investment right now. The over-optimization antidote is creating a culture where people feel safe to not only share their tools no matter how rough they may be, but also start small and build upon their successes.

1. Create a culture of shipping early

Reid Hoffman, founder of LinkedIn, famously said, “If you are not embarrassed by the first version of your product, you’ve launched too late.” In other words, your team’s first few stabs at automation may be suboptimal, which means it’s important that members aren’t picking apart each other’s tools. If left unchecked, that kind of environment can result in engineers over-optimizing a solution before sharing otherwise helpful and time-saving creations.

2. Start with a command line tool

These tools don’t have to be pretty; they need to work. So before you waste time building a user interface, focus on solving the problem. Embrace the win of getting a tool working in the command land, and then put a UI on it and turn it into something that looks nice. As a manager, your attitude shouldn’t be “This will be good when it looks good.” It should be “This is good because it works.”

Want to ship software faster to production? With its weeklong Navigator program, sodo will bring technical subject matter experts to you to help you identify your team’s skills and set goals for a software delivery transformation. https://l.shipondayone.com/nav.html