Organizational debt

Getting started quickly vs building for the long-run.

Technical debt is the idea that when you build software, you can often move faster by taking short cuts that you will need to go back and fix or improve later.

The longer you leave these things, the harder it becomes to fix them.

And if you build up too much, it will eventually bring development to a grinding halt.

So you can think of these shortcuts as a debt that gathers interest - You’ll have to pay it back eventually. The trick is to decide when.

There’s a similar pattern when it comes to organizations and processes, where choices that allow you to get started quickly will eventually prevent you from scaling until you address them:

• Allowing one hero programmer to become the central source of knowledge for your code base is efficient for initial development but prevents the team from scaling effectively. (And it’s a problem when they eventually burn out.)

• Data entry processes based on spreadsheets can be quickly adapted to immediate needs, but lead to an unmanageable mess.

• Processes based on personal relationships between specific individuals can be quickly optimized, but break down as soon as someone is sick or moves on.

Organizational debt is bad. But it isn’t an absolute evil to be avoided at all costs.

As with technical debt or monetary debt, a reasonable amount of organizational debt will allow you to get things up and running faster than you could without it.

The key is to be deliberate about what kind and how much you acquire.

And make sure to pay it down before it gathers too much interest.