The Rule: Always Present Options A, B, and C

Introduction

In growing companies, it’s common for SaaS (cloud-based software) tools to keep increasing, leading to a situation where the overall tool landscape is unclear and multiple tools with similar functions coexist. This state is often explained away as being due to teams introducing tools on their own, weak governance, or low IT literacy. However, in reality, the unstoppable proliferation of tools is an almost structural inevitability. This article reframes why tools continue to multiply in growing companies—not as a problem with the teams, but as “the consequence of absent management decisions and design.”

Tools Are the “Fastest-Acting Solution”

In the trenches of a growth-stage company, urgent problems like “workflow breakdowns” and “staff shortages” are happening right now. In such moments, the fastest-acting solution is to introduce a tool. Tools are ready to use quickly, have light initial setup, and can be implemented within a single team, making them overwhelmingly faster than waiting for a designed, integrated solution.

Without Design, Tools Become the De Facto Design

Fundamentally, workflow processes, decision boundaries, and data definitions should be designed. However, when such design is absent, tools step in to fill that role. The tool’s specifications dictate the workflow, its data structure constrains decisions, and its integration capabilities become the de facto design choices. As a result, the tool itself becomes the “designer.”

Local Optimization is Always Rational

The decision for each department or team to introduce a tool is correct at that moment. They want to improve their own operations and deliver results faster. They can’t wait for other departments. The problem lies in the absence of an “overarching design” that would halt these rational, localized decisions.

The More Tools You Have, the Less You See the Whole

As tools proliferate, data becomes fragmented, workflows grow complex, and dependencies become impossible to track. Consequently, no one can tell what will break if a tool is removed or where the bottlenecks are. This is not the fault of the tools; it is the inevitable result of lacking an integrated design.

Introducing a Tool is “An Act of Deferring Design”

Introducing a tool is not, in itself, problem-solving. It is a decision to postpone what should have been designed from the start. When this deferral accumulates, it creates “design debt,” such as:

• Un-integratable structures
• Difficulty in implementing fundamental changes

Why Couldn’t It Be Stopped?

The primary reason tool proliferation couldn’t be stopped was the absence of an entity with the authority to make that call. Teams on the ground couldn’t stop it, the IT department lacked the authority for overall design, and management didn’t delve into individual tool choices. As a result, no one took ownership of the decision to “not introduce” a tool.

The True Cost of Tool Sprawl

The bigger problem than the sheer number of tools is the following:

• Decision logic becomes embedded within tools
• The meaning of business processes becomes a black box
• The organization becomes constrained by its tools

This leads to a state where IT modernization becomes difficult, the cost of business change skyrockets, and management’s freedom of decision-making is reduced.

What Management Decision Was Missing?

What was missing was the higher-level decision-making on: “To what extent should we solve problems with tools?”, “From what point should we design the structure?”, and “Who decides this?”. The true responsibility of management was not to manage tool introductions, but to take ownership of “designing in a way that makes tool introductions unnecessary.”

The Next Question to Ask

The question here should not be which tools to cut. The question should be: “Why do we keep making the decision to fill gaps with tools, indefinitely?” In the next article, we will explore why more SaaS leads to less overall visibility and delve into how tool sprawl erodes management’s line of sight.