My first job out of college was with JPMorgan Chase. I worked on the Production Assurance team which was responsible for incident and change management. One thing that quickly became apparent while working there is that JPMorgan Chase depends on a lot of software systems. Interestingly, many of those systems were hacked together and poorly supported.
Here’s how that situation commonly happened: somebody in a business unit identifies a way to become more efficient at what they do using software. Having an app built internally would be too involved and costly, so the person learns how to work with Lotus Notes or Access to build the app themselves. Other people want to use the software as well, and before long a large number of people depend on a poorly supported application to do their jobs. Of course, because there isn’t any official IT support for the application, it’s running on a desktop under somebody’s cubicle and isn’t very reliable. Repeat times a few hundred.
I contributed to the proliferation of poorly supported software myself while I was there by building some tools to help the Production Assurance team monitor services and build incident reports.
Most companies would rather spend time solving their customers’ pain than their own internal pain. The tendency to favor building customer-facing features over internal tools is typical, but most companies do too little of the latter.
Key factors that deter from building internal apps:
Cost. If only considering the financial cost, it’s often cheaper to pay somebody to do a task manually than it is to build (and support) software to automate the work. However, for software companies, the opportunity cost will likely be even greater than the financial cost.
And a few reasons that favor internal apps:
Scale. Doing the work manually may be cheaper at current scale, but not if the business grows 10x. This could be taken as a reason to wait to build, although once an organization becomes reliant on a process or alternative solution, it can be difficult to change (example at many companies: Salesforce).
Quality of Life. Most people would rather not spend time doing repetitive manual tasks. Even if you can hire somebody to do the work, will it be fulfilling? Good people want good tools.
Next Best Alternative. As described based on my experience at Chase, if you don’t build good internal tools, your company will likely end up relying on Excel macros or Access applications. That’s good for some tasks, but not great for something that is a core competency of the business.
Error Rates. Software can have bugs, but it’s more likely for people to make mistakes when doing tasks manually than it is when those tasks are automated. Bugs in software can be fixed, but manually errors can only be solved with involving more people to do QA.
Customer Support. Having good internal tools will likely enable a company to provide better support. Faster response times are valuable, especially when on the phone with a customer.
Perfect Fit. If you build an internal tool, it will do exactly what you need it to do, it in the way that’s best for your business. Using another product often forces you to shape your processes around the tool, rather than the other way around.
I admire 37signals, so I often try to think how they would approach problems based on what they’ve written publicly. A quick search revealed that they’ve built numerous internal apps: Iterations, In/Out, Extra Extra, Smiley, 37, Dash, and likely more.