Chapter Ten · Operations · 3 min
The Flywheel, How One Signal Becomes Five Tools
I remember the exact moment I understood what I now think of as the flywheel, mostly because I'd got something quite badly wrong just beforehand.
I remember the exact moment I understood what I now think of as the flywheel, mostly because I'd got something quite badly wrong just beforehand. I had been working with a piece of labour deployment reporting, a fairly modest thing, meant to answer one specific question about whether shifts were being staffed the way they were planned. It did that job well enough. I filed it away mentally as finished and moved on to the next request on the list, the way you do when you're thinking about tools as individual deliverables rather than as anything more connected.
A few months later, a completely different conversation, about predicting kitchen load during busy periods, led me straight back to the same dataset. Then a conversation about spotting unusual shift patterns did the same thing. Then one about correlating staffing choices with guest sentiment.
By the fourth or fifth time I had reached for the same underlying data while exploring what looked, on the surface, like an entirely unrelated problem, I stopped thinking of it as a coincidence and started asking a different question altogether. Rather than asking what tool a business needs, I started asking what dataset, once properly understood, could power several tools I had not even thought of yet.
That's a subtle shift, but it changes almost everything about how you prioritise your time. Some data, it turns out, is just narrow. It answers one question well and has very little else to say. Other data has more to offer, and the difference usually comes down to a handful of things worth checking for deliberately, rather than discovering by accident the way I first did.
Does it capture a decision somebody made, rather than just an outcome that happened afterwards? Does it already exist, exported somewhere, unloved and uninterpreted, rather than requiring a whole new pipeline just to collect it? Does it line up naturally with the rhythm of a shift, so that timing is already built in rather than something you have to bolt on afterwards?
Labour deployment turned out to be one of the highest-leverage datasets I had worked with, precisely because it sits right at the point where a decision gets made, before service pressure arrives to test whether that decision was any good. Once it is properly baselined against what actually happens on the shop floor, it stops looking like a single report and starts revealing possibilities for load prediction, staffing correlation and regional summaries. The useful discovery is that each need not begin from scratch.
That's the flywheel, as far as I understand it. One signal, properly understood and properly trusted, doesn't just answer the question it was built for. It becomes the foundation that several future tools can stand on, each one arriving faster and cheaper than the one before it, because the hardest part, understanding what the data actually means and whether people believe it, has already been done. This is where my thinking departs from the way most organisations still approach internal tooling. Most businesses build tools one request at a time, treating each one as a fresh start. I now ask, every single time, whether what I am building today might be laying a foundation for three things nobody has asked for yet. More often than not, if the right dataset sits underneath it, the answer is yes.
There is a danger in this idea too. Once you start seeing leverage in data, it is easy to collect everything just in case it becomes useful later. I have little enthusiasm for that. Data has a cost in quality, governance and attention, even when storage itself is cheap. The point is not to build a giant lake and wait for insight to swim past. It is to recognise the information already created by meaningful work and understand it well enough to reuse it.
That distinction keeps the flywheel grounded. I am not hunting for data because data is fashionable. I am following decisions. The useful datasets tend to sit close to moments where somebody chose, acted, waited, served, scheduled or changed something. When those moments are captured properly, they often have more to say than the report they were originally collected for.