Time bankruptcy results from the deliberate over-commitment of core resources.
You’d know the symptoms, if not the name. You’re fighting to put out the fires from customer complaints, or incomplete work, or are suffering from an inability to focus upon new development or new customers before cleaning up the mess inside your organization.
Why use this term?
I created the term “time bankruptcy” almost thirty years ago when the computer software
business was young, and I was a software developer building a young company based upon quality first. Asked to speak at software industry events, I found my voice and immediate audience understanding as I described variants of these problems to my audience. The insight became clearer as I was hired again and again to pick up the pieces of failed programming efforts by other software companies in this then young industry.
Here is one example:
You take on a new customer, customize programs or services as needed, and install perhaps an 80% completed system, product or service. The customer pays for all or at least 90% of the bill, perhaps holding back a retainer awaiting completion.
Moving toward time bankruptcy…
[Email readers, continue here…] Burning through the payment and needing more to cover fixed overhead, you do the same partial task for the next 80% customer, moving on to the third. About that time, the first would call asking for completion, firmly but politely. The fourth installation was interrupted as the first customer suggested that he would stop giving glowing recommendations for you, insisting upon a completion date, while the second customer interrupted with its first call for completion.
By the fifth or sixth (who keeps count for these stories?), the first threatens suit, the second becomes demanding and the third makes that expected call for a completion date. So, you stop work on the newest product or installation to complete unfinished work. Revenues dry up while overhead continues to burn though your pockets.
It’s a classic case of time bankruptcy.
You have deliberately overcommitted your prime or core resources (in this case personal time) leading to a loss of income and reputation that you cannot easily recover.
Another way to the wall…
The same story could be constructed for any company selecting a limited number of test customers for a new product. Select too many, and pay too little attention to each. Commit all your core resources to solving the resulting problem, and new work stops. Time bankruptcy. Not a pretty sight, and completely avoidable.
Be aware of this trap.
No-one but yourself can be blamed for allowing core resources to be overcommitted, even if by subordinates. That’s because you now know the term and the impact of such an error in judgment, and understand that the simple but important remedy is to slow the commitment of those most critical resources to the front lines.
Resonates. A great beginning to a more nuanced or complex story. it is clear that the solo player digs their own debt. Been there – personal behavior and w contractors from construction to dream on ERP promises. But the rest of the story?
Operational excellence for practice toward efficiencies and functionality is essential and saves that reputation. But may not serve time or customer needs if seven signatures are required to change a 1/4 in coupling to a 6mm one.
A little more about the balancing act in assessing bandwidth, slack time while adapting to new demographic and cultural change would be a useful exploration.
While warning folks is a good idea, the tendency to underestimate how long things will take seems extremely widespread and hard to stop. Even the largest construction firms in the world grossly underestimate completion times. Likewise, in our own lives, it routinely takes longer than we anticipate to do standard stuff (even making dinner…).
One suggestion I have heard is that in addition to building up from estimates of how long the necessary tasks will take one might look at the average completion time for similar projects in the past. This may help combat the underestimation problem.