I have spent the majority of my career in engineering roles at startups. Both at companies I have worked at, and in the general startup ecosystem, I have frequently heard some variation of the refrain “engineers are expensive, but wireframes are cheap”. While I align with the underlying sentiment that doing the least amount of work to get customer signal is optimal, the phrase has always bothered me.

As an engineering leader, I do not want the rest of the organization to view the work that my colleagues and I do as some luxury that should only be leveraged after we have reached complete confidence that a product or feature needs to be built. At the same time, making a large investment in building something that never reaches general availability can be fatal for a small company. However, I think “how can we avoid involving engineering?” is the wrong question to be asking. Rather, organizations should be asking “why is involving engineering so expensive?”.

The engineering cost of building a product is a function of the experience and abilities of the engineers, as well as the pre-existing infrastructure that is already in place. Much ink has already been spilled on hiring and training good engineers, and the value of doing so cannot be overstated. However, despite the prognostications of some generative artificial intelligence optimists, I have yet to encounter a successful organization that views engineers as highly fungible assets. Infrastructure, on the other hand, is much easier to augment and often times higher leverage.

While it has become a severely overloaded term at this point, I view infrastructure as the parts of a system that reduce the cost and blast radius of introducing new or removing existing functionality. If engineering is viewed as disproportionately expensive in an organization, it is likely that there has been under-investment in infrastructure. It can be easy to find oneself in this position, as infrastructure is not directly tied to user-facing features. Building it requires advocacy by engineering leaders, and trust from other parts of the business.

I have found the answer to the following question to be a good litmus test of whether sufficient investment has been made in infrastructure.

How comfortable are you with introducing a poorly engineered service in production?

The answer depends on how easy it is to:

  • Expose the service to a limited subset of users.
  • Isolate the behavior and any side effects of the service.
  • Remove or replace the service.

While I would generally not advocate for intentionally building low quality software, being able to slide the quality bar towards prototyping without negatively impacting other parts of the system is a valuable capability. Organizations that have it are frequently able to operate more efficiently than those who habitually defer engineering work because they get higher fidelity signal on the usefulness of a product or feature, and the path from experiment to general availability is much clearer.

If you find yourself in an organization where the cost of engineering is high, consider an investment in your infrastructure.