Internal Tooling is Underrated

Introduction

Building tools that help employees be more productive is one of the most valuable things that is done in a company. Unfortunately, it’s frequently underinvested in and deprioritized in favor of customer-facing work. This leaves people creating ad hoc tools to solve their problems or brute-forcing their way to solutions.

In many organizations, this happens for a couple of reasons. The first is that it’s not directly revenue-generating so it’s easier to ignore. The second reason is that timelines are so tight that people feel like they don’t have the time to stop and build tools. This is a frequent source of waste in the long run.

For the most part, this leaves teams with a bunch of ad hoc tools that can solve small problems. Usually, these are developed when something bothers someone so much they fix it for themselves in some way, and then it gets passed onto the rest of the team. In non-technical organizations, this looks even worse with the best-case scenario being an excel workbook that does something similar and the worst case being someone spending their time doing data entry.

Why internal tooling shouldn’t just be treated as a cost center

Internal tooling isn’t directly revenue-generating. However, it’s a critical force multiplier for actually getting work done. Investing in tools improves productivity and there can be a flywheel of process improvements and efficiency gains that lead to more tool investments that compound over time. These gains can make a profound difference in the long-term success of a company.

Tooling also has side benefits and doesn’t just provide efficiency gains. People are generally happier when they have good tools and don’t feel like they are struggling to get work done all the time. Also by providing people with improved tools it allows them to think more deeply about important problems. This is because there is a significant amount of mental energy that is spent on just figuring out where things are or on how a process works instead of more useful work.

Force Multiplication

Tooling generally exists in two categories. The first are tools that make it possible to do the same work that you are doing just faster. The second is the kinds of tools that make it possible to do work that couldn’t be done before. These categories aren’t actually super clean cut because when you improve the way you are doing something far enough it makes things that seemed impossible possible.

Reducing the amount of toil that is necessary to get products developed is important for scaling. Unfortunately, it’s not as simple as just developing tools that automate an existing process and then releasing them. This is because processes themselves can be broken and building tools and automation around that process just lets you get through a bad process more quickly. This means that to actually build tools well there has to be an understanding of what the desired end state is and a willingness to improve the process along with creating new tools.

Tools are also necessary to make new techniques possible. Continuous Delivery is a great example of this. Without investing in test automation and deployment tools there would be no way to actually send code to production with each changeset. The manual work required would overwhelm basically any team. The process of eliminating that work requires a mixture of changing processes and tools.

Creating tools around processes like deployments allows people to worry more about strategy and business objectives and less about day to day operational tasks. There is a limited amount of deep thought work that a person can do in a day. The more of it that is taken up with complicated procedures that could be automated the less of it that is being used on actually valuable work. Many processes that can be automated aren’t trivial and would still require a deep amount of thought and error checking if a human is running them.

Deploys are still a good example of this. They are usually pretty fragile and have a large number of moving pieces that need to be tracked. There is also a bunch of points in the process where if a human is running it there is usually a decision that has to be made about going forward with the deployment or rolling back. The other major issue with doing a deployment manually is that any skipped step can have devastating consequences down the line. This means that each step needs to be checked carefully which makes the whole activity high stress.

Tool Development Improves Systems

Creating tools is also useful for thinking about a system more clearly. In many ways, this is similar to writing where the act of writing down what is going on in a way of deeply thinking about the problem. Making a tool to solve a problem or automate a process is the same thing. To actually solve the problem you need to understand it deeply from end to end.

Since you are understanding the process you are automating it by automating the process. Iterative loops are very effective. Essentially what happens is the first version of the automation isn’t perfect, but they increase understanding of the domain significantly. This means that recreating that automation also allows for a significant amount of process improvement to take place. This is a very good reason to plan to build a prototype version of the automation and then do it again for real in a production system.

Thinking about building tools in iterations is also useful for breaking down a problem. A small part of the problem that is understood can be automated and the rest can be left alone. After that part is understood another piece of the problem can be solved. This is especially useful for extensive processes where it’s not totally clear how the parts fit together, but there are clear handoffs that happen.

Understanding how processes work at companies is similar to understanding how code works. It can be trickier because things are stored in people’s heads instead of in a legible system. The actual stuff that needs to be understood is similar though. People do work based on a set of inputs and then they output something to someone else.

In many technical domains, these processes can and should be fully automated. In other places, human decisions need to be made and workflows need to be designed to make it easy for people to make high-quality decisions. Just because people have to decide what to do with certain steps doesn’t mean the rest of the work can’t be automated. Sometimes there are reasons not to though if the person making the decision needs to have a feel for the data. In that case, it can be worth having some manual steps that involve looking at the data as part of the workflow.

No code tools also present a great opportunity to increase the number of tools that exist especially for non-technical workflows. While more complicated processes will still require engineering support to build. Simple processes can be automated by the person actually performing the process which creates a much tighter feedback loop.

In cases where there is a team involved figuring out how to create the tight feedback loop is critical. It can actually be good to have the person writing the tool and the user working side by side. The faster feedback can happen the better the tool can be improved because tools are a notation for thought.

Conclusion

Creating tools is one of the highest leverage activities that a person can engage in. By making people’s jobs easier and eliminating drudge work we can create a better future. Creating better tools combined with pushing for increased equality can create a better world for all of us.

Software is being used in more and more tasks. There is still a ways to go before we have automated as much as we can. It’s worth turning a critical eye to the tasks that are being done around you every day and seeing how you can make it more efficient and less demanding.