Managing By Cliches, Part 1: Knowing When To Cut Your Losses

Picture of hole cards in a game of texas hold 'em

Knowing "when to hold 'em and when to fold 'em" makes all the difference in "not throwing good money after bad"

I came to the realization not long ago that managing my work by cliches wouldn’t be a bad idea.  I mean, cliches might be considered trite, boring, and unexceptional — but they became cliches because there is truth in them, right?  I mean, as odd a saying as it might be, can any mature adult really disagree with the notion that “you can’t have your cake and eat it, too”?

With this in mind, I thought that I’d begin a short series of posts exploring the work-related implications of a number of cliches.  Today’s post focuses on the notion of knowing when to cut your losses (or not “throwing good money after bad,” or, in the words of the Kenny Rogers song, “knowing when to hold ’em and when to fold ’em”).

Cutting Your Losses: Backstory

As with most people, I have a wealth of answers to the standard job interview question, “Tell me about a failure you experienced — and what did you learn from it.” (LOL – or “laughing out loud,” as they say in the texting world).  This particular case involved building a database to manage the HR side of my former company’s frequent acquisition activity.

In theory, it was a sound idea. The only problem was that we built it to handle much more complexity than we ever needed.  (There’s another cliche in there about “building things for the next war, not the last one,” but that’s a story for another day).

We had recently completed a very complex (for us) acquisition, involving multiple business units, dozens of product lines, more than 30 worksites, and close to 1000 employees — some of whom would be staying with us permanently, some of whom would receive retention bonuses for some period of time but would then leave, others of whom would receive severance packages, etc., etc., etc.

After managing this with a simple spreadsheet, we figured that managing another acquisition with a more robust tool/database would be a good idea.  We didn’t know at the time, though, that we’d never again manage an acquisition with nearly the level of complexity as this one.

Clue #1

I should have known I was embarking down a perilous path when I handed the programmer 32-pages of specifications (in truth, 3 or 4 pages probably should have been sufficient).

Clue #2

I should have known we had a problem when the programmer, an early-20’s whiz kid, quit the project half-way through due to mental exhaustion (caused, at least in part, by trying to accommodate the 32 pages of specs).

Clue #3

I should have known we were in trouble when the second programmer, in transferring test data between two of our main computer facilities in different time zones, actually brought one of our operating systems to its knees for several hours, shutting out virtually all other company traffic (yes, we got a call from IT on that one).

Clue #4

When we finally got the database tool in reasonably working order, I should have known all of our efforts were for naught when our highly capable and efficient administrative assistant asked if we could just go back to the spreadsheet for managing the next acquisition, after using the tool just once.  Actually, I’m happy to report that this is exactly what finally got me to realize how misguided we were being in using the tool … and we went back to the simple spreadsheet when the next acquisition came around. (P.S. The spreadsheet ended up working just fine).

Learning From My Mistakes

Though we had tens of thousands of dollars into the project at that point, my highly practical boss agreed to pull the plug on using the database — knowing that it just wasn’t going to meet our needs, despite everyone’s best efforts.  To her considerable credit, she didn’t flinch in shutting the project down, which was undoubtedly in the mental, physical, and financial best interests of all involved.

Lesson learned: We’re all going to make mistakes.  It’s learning from them (so as not to repeat the same mistakes in the future) and knowing when to stop throwing good money (and effort) after bad that makes all the difference.

*  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *

Do you have a “knowing when to cut your losses” story to share?  Please do so at any time!

3 responses to “Managing By Cliches, Part 1: Knowing When To Cut Your Losses

  1. LOL! I have sung that Kenny Rogers song in my head many times. I’ve quoted it too, but I usually go to the next line: “Know when to walk away, know when to run…”

    Rather than share a story, I have a question: did your team do a post-mortem on that project to reflect on and learn from the mistakes?

    • Hi, Liza —

      Thanks so much for your comments. (By the way, I just clicked on your blog — very engaging insights — and look forward to following your perspectives on Twitter).

      In this particular case, the post-mortem was easy, since it was a “failure of one” (i.e., me). At the time, I was the only one handling acquisition matters and I was the one who initiated the failed database project. So, the post-mortem was really just a good long “conversation” with myself — vowing to try to pick up on the “clues” earlier (which were all pretty clear in retrospect, of course).

      Thanks again for writing. I look forward to sharing perspectives in the future!


  2. Pingback: Managing By Cliches, Part 2: Let the System Work for You (not vice versa) | HR Perspectives

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s