Several years ago I worked as a computer programmer in the Information Technology (IT) Department of a company that manufactured and distributed Consumer Packaged Goods. The IT Department maintained and ran systems that provided some pretty basic services to the business. Manufacturing and Inventory Systems enabled the business to produce and manage its products. Order Processing Systems enabled the business to accept orders from its business-to-business customers and fulfill them with those products. Financial Systems enabled the business to process and track the earnings that resulted from trade in the products.
Our company enjoyed a major presence in its market. Even so, during most years I worked there, by the middle of December, the results being reported by the Financial Systems didn’t look good. Our business wasn’t hitting its financial targets, and the occupants of the C-suite were concerned. So the word would be sent out and reach IT: we would be instructed to “extend the year.”
Our business wasn’t hitting its financial targets, and the occupants of the C-suite were concerned.
What had senior management decided we would do? “Extend the year” meant that when early January arrived, we wouldn’t run the year-end software to close our books for the calendar year just ended. We would leave the books open so that the company could roll orders placed and delivered after January 1 back into the prior year’s business—until revenues became acceptably close to targets. Moreover, it was already standard operating procedure that as soon as possible after product was ordered, we would push that product out the doors, onto the loading docks and onto the trucks, so that the product could be recognized as shipped. Even with this boost to shipping, business was characteristically slow in January, and the prior year might extend weeks into the now current year before we could close it.
Eventually the numbers would come close enough to targets so that IT could execute year-end processing, and the books would close. At long last, usually well into February, we would conclude our prior calendar and business year with satisfactory financial outcomes.
Well at least sort of. With the current year officially launched at last, we would move forward ploddingly until that inevitable moment in the following December when our C-suite executives would again be forced to acknowledge that we weren’t close enough to our financial targets. So our C-suite executives would routinely decide to extend another year. Finally they would have to recognize that the six weeks or so of sales ceded to the prior year mattered, and our C-suite executives would attempt to reverse the impact of what they had done 12 months earlier.
Our company also had the companion problem of revenue lost due to returns—merchandise that our B2B customers would incorrigibly redirect back to us. Our response was to build an extensive and elaborate new Shipment Tracking System, which would require customer companies to affirm that they actively accepted product when they received it; the idea was that the affirmations would enable us to refuse to accept the financially ruinous returns. As the project lead for designing and developing our Shipment Tracking System, I know that the system was never completed and installed and that the anticipated benefits were never realized. Indeed, the Shipment Tracking System that would help us resist returns was still being constructed when our company was absorbed by a competitor.
I think it’s evident that the story I just presented isn’t a success story. It isn’t success when you try to cheat the calendar by packing this year’s revenue into last year because otherwise last year comes up short. It isn’t success when you push product out the door in order to book revenue that will only have to be reversed when the “shipped” product that generated it is returned—and then you try to reduce the losses by investing in expensive new software that you’re still constructing when your company goes out of business.
Nor is the story a lesson learned. No lesson was learned. Before it learned much of anything, our company stopped doing business on its own and merged into a competitor.
So why did I give you this story?
To demonstrate to you the power of a story. But not the power of the story I just gave you. The power of a different story. The power of a driving story.
The power of a driving story.
Let’s look at the C-suite executives whose decisions drove the outcomes. Every December those C-suite executives would examine reports full of grim data that indicated shortfall, poor financial performance, meager or even no upcoming executive bonuses. Those C-suite executives responded to what the data meant for them with action that improved the data—until additional data overrode the improvements and required additional responses. And I’m certain that those C-suite executives would insist that they had consumed and were managing to the data.
But I would disagree. I would counter that those C-suite executives had generated and were managing to a story. They needed—and so they created—a story of success, productivity, robust financial performance worthy of generous executive bonuses. Then they made and executed decisions in the service of the story. But those decisions went counter to what the numbers themselves might have indicated.
Ultimately, the business didn’t stand on its own.
And that is the power of a story.
