What reuse actually requires organisationally

Reuse is often treated as a technical problem.

Build the right abstraction. Create a shared service. Publish an API.

Then wait for teams to use it.

In practice, reuse is mostly an organisational challenge.

The first requirement is aligned incentives.

If teams are rewarded for shipping locally and quickly, reuse will always lose to bespoke solutions. Even when a shared option exists, the short-term cost of integration often outweighs the long-term benefit.

Reuse only works when teams aren't penalised for choosing the common path. Better yet, when choosing it makes them faster.

The second requirement is ownership.

Shared components need clear owners who are accountable for:

• Quality and stability

• Consumer support

• Evolution over time

• Saying no to use cases that don't fit

Without ownership, reuse becomes fragile. Teams lose confidence, and workarounds creep back in.

The third requirement is trust.

Teams won't reuse something they don't trust to remain stable. Predictable change, clear contracts, and honest communication matter more than feature completeness.

Trust takes time to build, but collapses instantly. One unannounced breaking change, one poorly communicated deprecation, one "just deploy and we'll fix issues as they come up", and teams start hedging their bets again.

Another requirement is timing.

Reuse works best after a pattern has emerged naturally, when two or three teams have solved the problem independently, and the commonalities become clear.

Trying to enforce reuse too early often freezes assumptions before they're well understood. You end up reusing the wrong abstraction.

Finally, reuse needs constraints.

Paradoxically, the more flexible a shared solution tries to be, the harder it is to reuse.

Every option becomes a decision. Every configuration becomes cognitive load. Teams spend more time understanding what's possible than building what they need.

I worked with a team that built a "flexible" notification service. It could send emails, SMS, push notifications, webhooks. It had templating, scheduling, retry logic, delivery tracking.

Teams took weeks to integrate because they had to understand every option, even the ones they'd never use.

A simpler service, "we send transactional emails, here's the three required fields", would have been adopted faster. Flexibility felt like a feature. It was actually friction.

Clear boundaries, "we support these three patterns well", make adoption easier. Constraints clarify intent.

In my experience, successful reuse isn't mandated. It's made obvious.

The best path is clearly documented. Integration is faster than building. Support is responsive. Changes are predictable. The decision to reuse becomes trivial.

Reuse follows trust, not mandates.