You are not talking enough about Internal Tools (and 4 examples)

Everywhere I worked, I have always enjoyed developing internal tools.
I feel that this is an area that does not get the focus it deserves despite the potential to dramatically impact the effectiveness of a company’s day to day operations.
Too often, tools are developed in the dark, during off hours and are being promoted by individual developers and not managers.

At every company I have ever worked for, I found myself developing tools for these daily nuisances that would otherwise required manual intervention, syncing of data from one system to another, management of manual spreadsheet and many other use cases.
While many companies face similar challenges when it comes to the day-to-day operations, for good reasons, each company is still unique and so, in my experience, spending a few days on internal tools rather than incorporating an off-the-shelf solution is a very powerful concept.
To list a few advantages:

1. Internal Tools are usually about helping teams spend less time on manual work and becoming more effective, this results in the day-to-day being more fun — Let the bots do bots’ job
2. Switching from manual tasks to automatic will end up reducing chances of human mistakes being made
3. Opportunity to test, first hand, a new stack of technology, given that usually such tools are easier test-beds for proof of concepts
4. An opportunity for a team members to get a breather from the company’s tech stack and go wild — personal growth opportunity
5. Such tools are always good opportunities for an Open Source project that could be of benefit to others down the road

Deciding to spend the time to build an Internal Tool is not always an easy call for engineers, we have a strong tendency to try and focus on our core business and avoid “inventing the wheel”
Consider this copyright from an unnamed company that sells a framework for the creation of such tools:

So, spending the time on building something that is obviously not the core value of your company is always questionable.
When discussing that — Build vs Buy — do not forget to add the third option: Build vs Buy vs Keep-Doing-It-Manually. For these small projects, too often than not, we decide to Keep-Doing-It-Manually, and too often, it’s actually not in the R&D department, but rather in the Customer Success, Fraud Department, IT or any other team that has less resources for in-house developing. It’s important in these decision points, to have the holistic view of why we do that — there are cultural and technical advantages that are beyond the tool itself.

(When referring to internal tools, this is not about BI Tools or main Back-office systems. These, in my mind, are a mandatory part for the tool set, more often than not, requiring detailed roadmaps and dedicated teams.)

4 Examples of Internal Tools or Utilities

Below is a brief sample of a few tools we built internally to address pains across the organisation.

Camel — RFP Made easy

Early on, we noticed the grueling process of answering RFP questions and while of course there are quite a few companies that specialise in building tools to manage that, we felt the pain is simpler in our case and we thought it would make sense for us to start with a simpler system.
All we wanted was an improved and smarter search of data over multiple Excel spreadsheets. Camel is an Elastic search + Excel, nothing more and nothing less. 3 years later it’s still a powerful tool and meets current needs!

Total work — 4 days by a former intern (Hi there, Jesse Berliner-Sachs!)

Kill It! — querying the database may go wrong

People sometimes make mistakes, and what happens when such mistakes are a queries that takes forever? sometimes causing database performance degradation?
Killing running transactions requires elevated privileges and we wanted to keep permissions contained. For that we built Kill It — A simple UI that allows watching and killing transactions in a safer way.

Total work — 1 day, working with some Ruby again, it’s good for your soul.

Safer Send Button — avoid data leakage

When sending out emails, a recipients list is manually entered and in some client facing teams many times a day. It’s an area where a simple typo of addressing the wrong person, could result in data leaked, something we work day and night to avoid and protect from.

To address that, we have created a Chrome Extension designed to better visualize the distribution of a given email when sent to outside recipients — Safer Send Button

Total work — 2 days, countless mistakes already prevented — win!

Ask-For-Ack — make sure the message goes through

It’s the Digital Age, the age of (really) short attention span, and between Slack, Zoom, email and F2F, things may be missed.
But what if this is a really important message? something that if missed by someone could be harmful ? or just significant waste of someone’s time?
For that, we have created Ask-For-Ack — a way to send information and monitor exactly who saw the message, who read and acknowledged it and who is out and about.

Total work — 1 week, to be open sourced pretty soon.