There’s no way around it. It’s been a while!
I always tell myself that I want to write more … then the week hits and it somehow always ends up being priority item number four when I only have time to work on a list of three.
I’ve learned to give myself grace. After all, I have been very busy, and I think that I’ve been prioritizing effectively. One of those priorities has been preparing to welcome (and then care for) a baby girl, which meant that I needed to make sure things could run smoothly when out for a month on paternity leave.
That time off predictably flew by. Honestly, it felt great not to think (that much) about work. But in those many delirious, sleep-deprived 2 am windows one thought did come back to me repeatedly: I want to write more.
Writing activates a unique part of my brain that would otherwise lie dormant. It forces me to better clarify and organize my thoughts. And to arrive at a defined point of view on important topics that might otherwise remain fuzzy.
All this to say, I’m excited to be writing again! Especially about a topic that I haven’t been able to shake from my head these past few months.
Before we move on though: A quick tease: When I was out on leave, I spent some of my (very little) downtime playing with new AI tools. Let me tell you, things have advanced RAPIDLY the past few months. I get asked about how I think about and use AI constantly, and I built something cool to help me answer that question. Stay tuned for next week!
Introducing the Theory of Constraints
Every collection operation is a system. The Theory of Constraints is a management framework built around one simple idea: Every system has a single bottleneck (constraint) that controls everything. To improve overall performance of the system, there is ONE key constraint that must be fixed.
There are certainly many problems, all competing for your attention.
But there is only ONE that really matters. And your recovery rate - regardless of how well everything else functions - is capped to however well that constraint is performing.
Before this gets too dry, let’s use a hypothetical to illustrate. Pretend you are an astronaut, on a solo mission in outer space. While circling in Earth’s orbit, uncertain of when you’ll be able to return home, you decide that you better take inventory of your resources.
You find that you have enough oxygen to last for ten days. Enough water to last for four. And enough food to last for seven. What’s the constraint here?
Water! Any time spent trying to solve the air or food problems will be a waste of time and resources. You’d die of dehydration before they ever become relevant.
This is a simple example that obscures the real challenge that presents itself once you embrace Theory of Constraints.
In a collection operation, there are no shortage of problems worth solving. And solving problems is often easy. That’s what makes TOC so useful. When fifteen things look broken, the constraint is the ONE that actually matters. Identify and solve for it first. Everything else can wait.
“There is nothing so useless as doing efficiently that which should not be done at all.”
- Peter Drucker
Quick side note before we dive deeper: Yes, small improvements are valuable and compound into meaningful productivity improvement. And non-operational challenges (compliance, for example), can muddy the TOC decision-making process. I won’t focus on either here, as I want this to be readable over one cup of coffee.
Same for fully outlining the full TOC process. If you want the full deep dive, check out Eli Goldratt’s Theory of Constraints book. And reply letting me know if I should circle back with a part two to this initial look at TOC.
Introducing the Theory of Constraints
At the risk of oversimplifying, total recovery is a basic equation:
Outbound attempts X RPC Rate X Promise to Pay Rate X Average Promise Amount X Promise Kept Rate.
Each variable is a lever. The constraint is whichever one is limiting your output (total dollars collected).
This distinction matters more than it sounds. When recoveries are down, managers don’t usually ask which variable is the bottleneck. They ask what can be improved. And the answer is often the one that is most actionable, not the one that will remove the constraint.