How to rally engineering teams to build the internal tools you need

With teams spending so much time using internal tools, it’s worth making sure those tools deliver the right results and can be efficiently maintained. While teams can pick from plenty of off-the-shelf software, custom-built tools are often a better, right-sized fit for an organization’s unique needs.

But building custom internal tools from scratch can take a lot of technical investment—which means dipping into time and resources that might already be stretched thin. In product-oriented companies, development may even be seen as a zero sum game, with every hour spent writing code for internal tools an hour taken away from working on the core product roadmap.

In this article, we’ll make the case for the long view: custom internal tools built efficiently can accelerate business growth and ultimately save everyone time that can be reinvested into business and product. More tactically, we’ll address how non-technical teams and engineering teams can collaborate to effectively develop those tools.

For many non-technical teams, their day-to-day operations depend on manual inputs that can struggle to scale as a company grows. Suppose a product achieved a tenfold increase in users in a matter of months. Great news—except that until that point, the support team has been managing by manually searching through Stripe payment details, matching those to Jira tickets, and composing email responses from scratch. The influx of users makes this system unsustainable, and suddenly the support team becomes a critical bottleneck.

It’s not practical—and probably not possible—to 10x the support team’s staffing overnight, so the company needs a better system to handle the volume of customer requests. Leveraging internal tools to automate tasks and improve operational efficiency could ease the burden on the support team, and customers could benefit from faster and more accurate responses to requests. In turn, this can lead to things like lower churn, more positive sentiment, and a host of other positive, knock-on effects. Investing in internal tools goes beyond creating smooth workflows, and can contribute in myriad and measurable ways to a business’s health and resilience.

While off-the-shelf tools like Salesforce, Zendesk, and other third-party applications can be huge leaps for teams coming from a mess of spreadsheets and legacy software, they tend to serve a broad array of customers—so even the best can run into limits tackling more specific problems problems or those unique to a domain area. For just one example, climate tech startup Greenly needed to estimate CO2 emissions from various business activities, and they couldn’t find an off-the-shelf tool designed for the specialized task.

That’s why custom-built internal tools are often the “dream scenario.” Unlike off-the-shelf tools, they can more directly address a team’s pain points and particulars. Rather than forcing a team to adapt their workflow to the tool, a thoughtfully designed custom tool can naturally slot into a team’s practices. That can make them very high reward, but—as we all know—often high effort, too.

The good news is that most of the time, internal tools follow common patterns. They typically have a backend layer that manages the application’s data and business logic, as well as a frontend UI. This paradigm means that engineers don’t actually need to start from zero to build bespoke internal tools. They can leverage reusable software components (like React components), customizable templates, and/or platforms that help them accelerate the work so that they can spend time on the truly custom parts of the tool, not the boilerplate.

Engineers, and especially engineering managers, are always prioritizing how to best spend the limited time in their development cycles. The default is usually to keep building and iterating on the core product—reasonably enough. But supporting other business functions and investing in tooling that could have broad benefits for the company, the customers, and the teams is a meaningful opportunity.

It can be helpful to illuminate that if you’re communicating a request for an internal tool or bespoke operations software. For instance, a non-technical team might need recurring access to logs data. Another team might repeatedly have to modify user accounts in some capacity. These requests eventually make their way to engineers who have to switch contexts to help out. Acknowledging that custom tools to help handle these needs can save everyone time helps underscore their multi-faceted value. (As does examining how internal tools can enable better end-user experiences with teams like sales and support, which can in turn translate into top-line metrics wins like higher customer retention and satisfaction.)

By thoughtfully communicating why it’s worth it to invest some eng time in internal tooling, you can get more buy-in and reduce friction in getting the work done.

Here are a few practical techniques to help give the engineering team a clear sense of what’s to be built, and to show the impact on the business:

It’s no coincidence that these strategies mirror how engineering teams set their own product roadmap. By taking internal product development as seriously as external product development, businesses can more equitably allocate engineering resources between the two.

We’ve just scratched the surface of how engineering and non-technical teams can effectively build custom internal tooling together. Good communication, clarity on impact, and leveraging efficient approaches to building bespoke tools—rather than starting from zero—can be key to getting alignment and buy-in.

To learn more, download our extended guide to rallying engineering to build internal tools for your non-technical team. We go in depth on best practices and techniques for streamlining your tool development process, complete with examples from real-world companies.

Ready to build internal tools in a matter of days or weeks instead of quarters? Book a demo today.