An expensive deprioritization

Here's a reason why, when building machinery to do something, you should make it with the workflow of the end-user in mind:

I am at work right now in the middle of working on a business-critical task that no longer brings me joy or satisfaction because I've pretty much mastered it. And as you can see, I've stopped doing it to bring you these words.

Anyway, here are five reasons internal tooling should be built with the workflow of the end-user in mind:

1. Humans are the worst at doing mundane things in a repetitive fashion
   It's not going to be true for everyone, but it sure is true for me. Once I get really, really good at doing something, I stop enjoying it. I've mastered the task and can do it efficiently and accurately, so the challenge of learning is gone. If this was the only thing I could do at work, I'd be gone already.

   In a way, I feel like a glorified switchboard operator.

   Switchboard operators are typically required to have very strong communication skills. ¹

   Hey, as an employee at a quickly-growing small enterprise software company, I am supposed to have strong communication skills to ensure collaborative synergy.

2. It's much, much more error prone
   Being that I'm not really into the task at hand, I'm likely to let the quality of my work slip. Each time I have to make a decision, I get fatigued and wish the task would go faster so I can be done with it sooner and move on to more interesting work.

   Not sure what to do about this particular thing? I should research it, click on the links to learn more, maybe do a few searches... nah, just save my time and move on. Nobody will know the difference.

   A false negative is not that bad because it can always be added at a later time without anyone being the wiser. But, a sloppy job can also result in false positives, which require correction. The output of my work ultimately gets put into a report, and it's no good if a report containing false positives goes to the customer. Each time I have to make a conscious decision based on several different input data, the chance for a false positive being included increases.

3. It's really expensive to not do it right
   The small enterprise software company that employs my services, powered by investor dollars, has a limited amount of time to get to self-sufficiency. If the company can't get to that point, the board of directors will start looking for exits before the valuation drops too low and money runs out. I'm expensive. There are several others on my team that do similar work and we are all expensive. If we are doing non-innovative busywork, then we are being drastically overpaid, and the company is losing more money than it needs to.

   The amount of upfront work needed to build a system properly pales in comparison to what will be spent maintaining it, making small fixes, and using the tool in the long run. The opportunity cost of paying several people to do a bunch of pixel-moving tasks instead of working on growing the business is tremendous.

4. Nobody wants to fix old problems
   These tools are the result of engineering projects. When a peice of machinery needs to get built, a team is allocated to the task to see it through to completion. When the project is done and the result delivered, that's it - it's now time to move on to other projects. Sure, bugs will be fixed, but core functionality? If part of the core functionality is to have a human do exception handling, it's going to be that way until the core functionality changes. Can we change the core functionality? No, we can't do that now, there are more important things to work on today. Besides, there are workarounds, even if it takes much longer, is more error-prone, and reduces profitability.

Employees who use internal tools are customers

Yep. They are the internal customers. This is something that the small enterprise software company that I work for has a hard time coming to terms with. Internal tools are very low on the priority list, while software that the customer sees gets most of the engineering effort. I can see why this seems like it makes sense because customers don't have any incentives to stick around, like salary or benefits. But the unseen effects are that it creates a contentious relationship between the users and the internal tool product team (or the engineers if a product manager doesn't exist for internal tools) and the cost of doing business increases invisibly because the employee will stop what they are working on in frustration to write a blog post about why internal tools should be considered production software.