# The Cyclic Nature Of In-House Tooling

DevFeed: [The Cyclic Nature Of In-House Tooling](<https://devfeed.tech/articles/the-cyclic-nature-of-in-house-tooling-20045.md>)

Original publisher: [Read original article](<https://technology.doximity.com/articles/the-cyclic-nature-of-in-house-tooling>)

Author: Doximity

Published: 2022-09-28T17:00:00Z

Content type: opinion

Language: en

Sources: [Doximity](<https://devfeed.tech/sources/doximity.md>)

Topics: [Tooling](<https://devfeed.tech/topics/tooling.md>), [CI/CD](<https://devfeed.tech/topics/cicd.md>), [Testing](<https://devfeed.tech/topics/testing.md>), [Automation](<https://devfeed.tech/topics/automation.md>)

Tags: [automation](<https://devfeed.tech/tags/automation.md>), [ci-cd](<https://devfeed.tech/tags/ci-cd.md>), [test-automation](<https://devfeed.tech/tags/test-automation.md>), [tooling](<https://devfeed.tech/tags/tooling.md>), [workflows](<https://devfeed.tech/tags/workflows.md>)

## AI overview

The article explains how Doximity's Infrastructure Automation team treats internal developers as customers and its tooling and services as products. It presents a product-lifecycle approach to discovering needs, prioritizing requests, and improving developer productivity and production deployment processes.

## Source excerpt

Joseph M. Juran popularized the concept of considering members of an organization who are stakeholders concerning another individual or group's products or services to be internal customers. In contrast, and as suggested by the name, external customers are those whose relationship to the organization is not through employment but by purchasing the organization's products or services. While a company's focus primarily lies on the external, teams within the organization must often focus on both. In this article, we'll discuss the marketing initiatives surrounding the release of an internal product. At Doximity, we have various developers focused on many products and services. On the Infrastructure Automation team, we aim to design tooling and workflows that directly assist our internal customers, with the downstream effect benefiting those who are external. Our team's core mission is to build, maintain, and support test tools and frameworks, CI infrastructure and pipelines, and all test automation processes. Our overall goal is to make developers more productive while simplifying the process of deploying to production. While the utilities and services managed by our team are not directly customer-facing, their impact helps reduce friction in the creation of products that are. Being an infrastructure team spanning support across R&D, we're divided between our web, mobile, and data business units, myself aligned with the latter. Therefore, data engineers and scientists are my primary internal customers, with CI/CD users as a whole being my secondary. How do I determine where my developer time is best spent to support them? How can I generate new ideas that benefit my customers? How should I prioritize the myriad of requests sent my way? Suppose I do consider the employees I support to be internal customers. In that case, I should also treat the utilities and services I create and manage as products that adhere to a product life cycle of sorts. This cycle emulates proced