When Technology Decisions Outgrow the Way They’ve Always Been Made

The Business Changes Before the Decision Model Does

A 20-person business can make technology decisions in ways that would be completely inappropriate for a 500-person organization, and there is nothing wrong with that. Small organizations benefit from speed. The owner can approve a platform during a conversation. A trusted employee can make a recommendation. A provider can solve a problem without a committee and six weeks of review.

That approach can work remarkably well for years. The problem begins when the business changes but the way it makes technology decisions does not. Growth adds employees, locations, systems, vendors, data, integrations, security requirements, contracts, customer expectations, and dependencies. Technology becomes embedded in nearly every business process while decisions are still made as though the environment were simple enough to understand from memory.

Complexity Changes the Meaning of a “Small” Decision

Consider adopting a cloud application. At a small scale, the evaluation may reasonably focus on whether it solves the problem and whether the price makes sense. As the organization matures, the same purchase can affect identity, data, retention, integration, continuity, security, contracts, and other platforms the business already owns.

The application did not become more complicated because the company grew. The environment around the decision did. A choice that once stood alone now changes a system of relationships.

Growth Creates Connections Between Decisions

A department may select a platform to solve a legitimate requirement. Finance may approve the expense. A provider may configure it correctly. Security controls may be applied appropriately. Every participant can perform well while still seeing only one part of the decision.

The missing view is across the environment. The platform may duplicate another capability, introduce a new identity exception, create a dependency during recovery, complicate data retention, or lock the organization into a contract that conflicts with a planned architecture change. None of those facts automatically makes the purchase wrong. They make it a decision that should be evaluated as part of an architecture rather than as an isolated tool.

The Warning Signs Are Usually Ordinary

Organizations rarely receive a formal notice that their decision model has stopped scaling. The signals are mundane. Leadership discovers two systems doing similar work. A renewal arrives and nobody remembers why the platform was selected. An employee leaves and several integrations suddenly depend on knowledge that left with them, the same institutional-memory gap explored in What Happens When the Person Who Knows the IT Leaves? A temporary exception is now three years old. A project discovers that a legacy system cannot change because three other processes depend on it.

Taken individually, each issue can look manageable. Together they indicate that the organization is making decisions faster than it is maintaining an understanding of what those decisions are creating.

The Answer Is Not Enterprise Bureaucracy

Growing companies often resist governance because the word suggests committees, approval chains, and policy structures designed for global enterprises. That is the wrong benchmark.

ISO/IEC 38500:2024 explicitly applies governance principles to organizations of all sizes. The practical implication is not that a 75-person company should govern technology like a bank. It is that governance should be proportionate to the organization. The minimum useful structure may be surprisingly small: clear ownership for material decisions, documented architectural choices, review dates for significant exceptions, a roadmap tied to business priorities, and leadership visibility into decisions that actually require business authority.

Preserve the Speed. Add the Missing Context

The best governance model for a growing business should protect the speed that made informal decision-making valuable in the first place. Routine operational choices should remain routine. Providers should continue operating within their scope. Department leaders should still be able to move. Technical teams should not need permission to perform ordinary work.

The change is that consequential decisions are recognized before they disappear into day-to-day operations. The organization knows which decisions need broader context, who owns them, what was decided, and when the decision should be revisited.

The Trigger Is Consequence, Not Headcount

There is no employee count at which governance suddenly becomes necessary. A 40-person healthcare organization with sensitive information and regulatory obligations may need more structure than a much larger company with a simpler environment. Rapid acquisition, new locations, AI adoption, compliance requirements, complex customer contracts, or dependence on integrated platforms can accelerate the need.

The better test is whether leadership can still answer basic questions without reconstructing the environment from scattered emails and individual memory: what do we depend on, why did we choose it, where have we accepted meaningful risk, who owns the important decisions, and how do current investments fit the direction of the business?

The Decision Model Has to Grow Too

When those answers become difficult, the business may not have outgrown its technology. It may have outgrown the way it has always made technology decisions.

That is the point where governance becomes less about adding process and more about preserving clarity. Coles Technical Group provides an independent technology architecture and governance layer that works alongside leadership, internal teams, outside providers, vendors, and integrators. The objective is not to slow a growing business down. It is to make sure the decision model grows before complexity begins making decisions on the company’s behalf, which is the operating model described in What Does a Technology Governance Firm Actually Do?