Technical debt and organisational debt

In engineering, we have a well-established concept: technical debt.

Technical debt describes how past decisions shape present constraints and costs. When corners are cut, deliberately or not, you create debt. That debt compounds over time. The longer you wait to address it, the more expensive it becomes.

👉 Importantly, technical debt is not inherently bad. Just like financial debt, if you have the capacity to pay it back, it gives you leverage.

Sometimes you want to move fast, accept shortcuts, and trade future cost for present speed. This is when you take on technical debt.

But nothing comes for free. Eventually, the bill arrives.

What is often overlooked is that this concept applies far beyond code.

Organisational debt

Debt exists anywhere where decisions create long-term maintenance, cognitive load, or operational complexity.

This includes (but not only):

• Products kept alive long after they stop fitting strategy
• Processes that exist “because they always have”
• Customer or partner commitments that require ongoing exceptions
• Features that expand scope without increasing value

We’re going to generalise the concept of technical debt and name it organisation debt.

If something will still require human attention, decision-making, or specialized knowledge five or ten years from now, it has a cost. Even if that cost appears negligible today.

Concrete example

A company launches a product. Years later, this product is discontinued. No new customers, no new development. Existing customers are kept because:

• Supporting them appears cheap
• This product still generates some revenue
• Removing it feels unnecessary or risky

On the surface, this looks like free money. In reality, it is not.

As long as customers exist:

• Someone will request a change
• Someone will raise a question, complaint, or edge case
• …

Individually, these costs look insignificant. But over time, and multiplied across many discontinued products, the impact becomes significant:

• Few people remember how these products work
• They no longer align with the current strategy
• Documentation is outdated or missing
• The original builders are gone

The organisation ends up spending significant effort understanding decisions made years ago. What once looked like easy revenue becomes a drag on focus, velocity, and morale.

That is debt being paid with interest.

Organisational debt compound

This is the key insight: debt compound.

An organisation that avoids hard cleanup decisions ends up with:

• Too many products
• Too many processes
• Too many exceptions
• Too much legacy knowledge locked in people’s heads

At some point, this organisation will stops building and starts fighting its own past. Teams are busy, but progress slows. Entire departments exist to maintain things that no longer matter strategically.

This is how companies end up in a place where everyone feels overwhelmed, yet nothing meaningful moves forward.

Organisational debt and feature creep

This same dynamic exists in product management, it is called feature creep: the gradual accumulation of features that individually seem reasonable but collectively increase complexity and reduce clarity.

Feature creep is organisational debt.

It increases:

• Cognitive load for users
• Maintenance cost for teams
• Surface area for bugs, support, and edge cases

Strong product organisations are not defined by how much they add, but by how deliberately they remove.

Apple’s product line remains narrow and focused because features and products are removed aggressively. Google is well known for killing products that no longer fit, often to external criticism.

Killing products or features is not failure. It is how focus is preserved.

Organisational debt apply to most area of a company

Engineering is just the most visible example.

The same dynamic applies to:

• Operations
• Customer support
• Internal processes
• People management
• Organisational structure

Any time we add complexity without a clear long-term justification, we are borrowing against the future.

False value and the cost of “extra work”

Another subtle form of debt comes from work that feels helpful but delivers little real value.

Teams often go the extra mile with good intentions. But intention does not eliminate cost.

Before adding processes or services, it is worth asking:

• Does this create meaningful value?
• Or does it simply create more work to maintain later?

Organisations frequently introduce “nice-to-have” activities that:

• Customers did not explicitly request
• Do not materially change outcomes
• Still require staffing, coordination, and management

Over time, these decisions accumulate. Roles are created. Processes form around them. Management overhead increases.

Eventually, entire teams exist to maintain work that no longer clearly matters—while believing they are contributing to the greater good.

This is also debt.

Small team with a lot of products to serve vs small team with a few products and large customers base

At Feather we have a motto

👉 We believe that a small team with the right focus and the right tools outperforms bigger teams.

Small teams do not scale by serving more products. They scale by doing fewer things exceptionally well.

The limiting factor is not headcount, it is surface area.

A small team can sustainably support:

• A small number of products
• With a large and growing customer base

This works because high frequency enables automation. When the same workflows, edge cases, and decisions repeat often enough, investing in tooling and automation becomes obvious and highly effective. Customer volume can grow exponentially while team size remains constant.

The opposite configuration does not scale.

A small team responsible for:

• Many products
• Each with few customers
• Each with distinct rules, exceptions, and workflows

will inevitably struggle. Frequency is too low to justify automation. Maintenance remains ad-hoc. Knowledge becomes fragmented. Every request feels “special,” and complexity accumulates silently.

In this model, the team scales linearly with complexity, not with value.

This is why strategies built around small, autonomous teams only work if the organization is ruthless about reducing surface area:

• Fewer products
• Fewer features
• Fewer exceptions
• Clear ownership boundaries

Without this discipline, “small teams outperform big teams” becomes an aspiration rather than an operational reality.

The core principle

Every decision creates future cost. If you don’t consciously choose which debt to take on, you’ll inherit it anyway.

The job of leadership is not to eliminate debt entirely, but to choose it deliberately, understand its long-term impact, and regularly pay it down.

Because if you don’t, the organisation eventually stops scaling—and starts surviving its own past.