In software engineering, technical debt is when you work quickly and take shortcuts in coding that prioritize completing the work sooner over long-term stability and consistency of the code. Essentially, you borrow time and resources from the future (to fix problems arising from these shortcuts) in order to have a product NOW. Like financial debt, technical debt can accrue “interest” in the increasing time required in the future to work around issues associated with these shortcuts.

A similar issue exists with administrative systems, although we don’t always look at it this way. Many organizations have systems that aren’t working for them. They may have nonsensical file structures, or no place to store important client information, or a need to use multiple systems to complete a simple task.

While we may look at the “ROI” or “efficiency” issues associated with such systems, wouldn’t it be productive to apply this “debt” framework to administrative systems and databases that were implemented without enough attention at the start? Like other forms of debt, the time losses to these systems only compound with time.