Everyone seems to know what internal tools are, but they are poorly understood on a broader level. How do the world’s best companies think about internal tools? How much time should engineering spend on them? What should you build internally, and what’s worth buying? We’re profiling engineers, product managers, and designers who build world class internal tools at their companies to get some answers.
Chad Rosen has been working as a software engineer and engineering manager in the Bay Area since 2001. He has helped contribute to both the product and internal tools at companies like Good Technology, ClickShift, Twitter, and Wealthfront.
Chad has worked on all different types of internal tools in his career, and has important advice for anyone doing the same: approach internal tool building the same way you’d approach a user facing app. Users are users: “just because we happen to work for the same company as all our users doesn't mean we should be sacrificing product quality.” We spoke to Chad about how he builds tooling and advocates for resources, as well as some interesting tools he’s built over the course of his career.
What kinds of internal tools have you worked on in your career?
I’ve worked on a broad array of internal tools over my career. The very first tool I built helped QA engineers keep track of test case results, and was eventually open-sourced as Testlink.
Other tools that I’ve built include employee directories, employee feedback systems, internal short-link redirectors, visitor management systems, and applicant tracking systems, among others.
What have your teams built tools with? React, Ruby on Rails, Airtable, etc.
I’ve built internal tools using a lot of different technologies (Ruby/Rails, Python, Node, Java, Go, PHP, etc.). When building internal tools, most companies optimize for speed of delivery and ease of maintenance. Scripting languages (Ruby, Python, Node) tend to be really good for quickly getting something up and running and iterating. However, it’s often best to use technologies commonly used at the company. This enables you to leverage existing infrastructure and often the team is already trained to use it.
Which of the internal tools you've built were the most popular or had the highest adoption among who you worked with?
The most popular tool I worked on was an internal short link redirector (Go Links) that was inspired by a similar tool at Google. Go links enable employees to get to internal websites without having to type the entire URL to access them. The Go link tool was used by almost the entire company thousands of times a day. Someone even built their own business around the concept.
Do you build internal tools just like user facing applications, or are there different standards and development paradigms?
I approach building internal tools as if I were building a B2C application. This includes not only the technical choices but also how the team is organized, being metrics-driven, running experiments, etc. Just because we happen to work for the same company as all our users doesn't mean we should be sacrificing product quality.
With your end-users being internal employees, how do you measure your success and improve your tools?
It’s easier to measure success if your tools are helping a specific business unit be more productive, because you can just focus on improving their core metrics. Improving productivity for an entire organization can be more challenging because it’s harder to measure. With these types of applications I’ve used customer satisfaction (CSAT) and adoption as proxies for success.
How do you approach tool maintenance and prioritizing stakeholder requests? Are you able to build everything needed, or do you need to triage?
It can be challenging to prioritize maintenance and infrastructure tasks for internal tools because they can be hard for non-technical people to understand, and they and take resources away from features that they need. A good strategy for getting this work done has been dedicating a portion of a sprint to bug fixes and infrastructure work. For larger projects, I’ve had to dedicate a portion of the team to non-feature work. For this type of work, it can help to make sure you keep the scope of the work small to avoid projects getting out of control.
What’s a mistake you’ve made building an internal tool that you learned a lot from?
I was part of a team that built an internal applicant tracking system and I wouldn’t undertake that effort again. We heavily underestimated the complexity of the requirements; privacy, permissions, different user types, workflows, etc. If I were to approach that problem again I would probably start with a “buy” solution that handled the majority of use-cases, then and build custom integrations and workflows that weren’t supported by the tool ourselves. More generally, it’s caused me to be more thoughtful about fleshing out and understanding requirements prior to embarking on very large initiatives.
How were internal tools viewed at companies you've worked at? Did people appreciate their importance, or are they second class?
I think that most companies where I’ve worked have valued the impact of a product regardless of whether it is internal or external. If an engineer builds an internal tool that saves thousands of engineering hours for the engineering org, that should be seen as just as valuable as a revenue-generating feature on the user-facing product, if not even more so.
Is it generally hard to advocate for the headcount you need for internal tools?
It can be challenging to get the headcount you need for internal tools. It gets significantly easier if you have good stakeholders that can advocate for you. It also is easier if you can point to specific metrics that can be moved by adding more headcount.
What are the biggest frustrations you run into working on these kinds of tools?
It can occasionally be frustrating when a customer wants a feature designed in such a way that adds a significant amount of complexity. Often this customer doesn’t appreciate the cost of what they’re asking for, so I usually try to add context and help them understand the tradeoffs. I often advocate for doing things in a less complicated way so we can ship and learn faster… but it doesn’t always work.
How do you think about the tradeoff between building a tool and paying for a SaaS product instead? When is something worth building?
I think it can make sense to build your own tool when a few things hold true:
(a) there isn’t an existing product to buy
(b) existing products are low-quality
(c) when you need a large number of integrations with your other tools
(d) when existing solutions are too costly
I think a good middle ground can be to buy (or use open-source) as your foundation, and build custom features on top of it.
Are there any teams or companies you admire who do a great job on internal tooling?
I’ve never seen their tools in person, but it seems like Stripe has great internal tooling. We use their Stripe Home as inspiration for our own intranet.
Is there any advice you’d give to other builders that you wish you’d had when you started?
I would tell someone new to make sure that they try to build internal tools with the same level of quality that they would for an external-facing product. It can be easy to skip things like unit tests, integration tests, and continuous deployment for internal tools, but those decisions will end up costing time and creating issues down the road.
Reader
