Pushes, Bearings and Mass

Flywheel is one of those words that turns up in most strategy documents I read. Everybody wants one. When I ask which part of the flywheel a team is building, the answer is usually a description of the next feature.

The metaphor belongs to Jim Collins, who introduced it in Good to Great in 2001. What he got right is the physics: momentum comes from many consistent pushes, none of them heroic, and one day the wheel turns under its own weight. His version stops being useful because his flywheel is one wheel, and the only thing you can do to it is push.

The oldest flywheel is the potter’s wheel, and it is the best picture of what one is for. A potter kicks a heavy stone disc a few times, and then both hands are free to shape the clay while the disc keeps turning. The work goes on for a while after the kicking stops. A heavier disc needs fewer kicks, and well-oiled bearings let it run longer between them.

The disc is not what makes pottery possible. The earliest wheels were plain discs turned by hand, and the potter shaped the clay in the pauses between turns. The flywheel holds the momentum so the potter can stay with the pot, and more comes out of the same afternoon.

That is what people mean when they say a company has a flywheel. They mean the parts of the business that keep working between pushes: loops where one week’s output makes the next week’s work easier, and assets that improve the whole system rather than one feature. A company runs fine without any of it, the same way a potter can turn the wheel by hand. What the flywheel changes is how much comes out of the same hours.

Seen that way, the wheel has three parts you can spend an hour on. You can kick the disc, you can oil the bearings it spins on, or you can make the disc heavier.

A push is a kick. It turns the disc once. Ship the feature, run the launch, write the spec. It is often the most valuable thing available that week, and when it is done the wheel is exactly as you left it.

The bearings are the machine itself: the monorepo, CI, the design system, observability. Bearings add no energy of their own. They decide how much speed the disc loses between one kick and the next.

Mass is the weight of the disc: an evaluation suite for an AI pipeline, the labeled data that improves a model every week. Mass is what keeps the disc turning after the last kick. This is the one place where the metaphor is generous to software. A potter cannot make the disc heavier every week, and a team can.

All three are legitimate, and most weeks are correctly mostly pushes. The problem starts when a push gets written into the plan as an investment. The third part is the one people mean when they say flywheel, and in my experience it is the part that gets the least deliberate time.

When Every Hour Was a Push

The complaint I hear most often sounds like this: we shipped all year, and January feels like starting from scratch. Teams read that as a missing flywheel. In most cases I have looked at, the wheel was fine and the bearings had seized.

The version I lived through was a design system. We had thirty-one screens, shipped over six months, each with its own hand-rolled spacing, colors and layout code. Every one of those screens had been a perfectly good push. Then a rebranding arrived, and the estimate for changing the colors and typography across all thirty-one came back so large that we stopped estimating.

So we put in a design system and moved the existing screens onto it. Now colors and typography live in design tokens, and every screen updates the moment a token does. A screen built by someone who has since left is something a new joiner can safely change on a Tuesday afternoon.

The original pushes were as good as they ever were. The design system changed how much of their speed the wheel keeps, which is a bearings question, and it stays open long after the push is done.

Bearings Have a Floor

This is also where the word flywheel gets misapplied most often. A design system makes work easier, but it does not compound, because friction has a floor. You can remove it once, and after that the returns stop arriving. The thirtieth screen was much cheaper than the fourth. The three hundredth will not be cheaper than the thirtieth.

Mass has no floor. Every case you add to an evaluation suite sits on top of every case already in it. A team that reports its reuse gains as compounding is setting an expectation the second half of the year cannot meet.

You also cannot half-install a bearing. A monorepo migration that is sixty percent done is worse than never starting, because you are paying the full cost of the migration and getting none of the relief. Mass can be added a kilogram at a time, but bearings only pay out once the migration is finished.

So pick the date the migration is finished and defend it against whatever urgent thing arrives in week three. Half-finished foundations are usually invisible in the plan, because every individual decision to pause one looked reasonable at the time. Sequencing Is Not an Opinion tells a longer story of how that happens.

What Counts as Mass

Not everything you build stores momentum, and how well it was built has little to do with it. The test I use is whether the work touches it on its own.

The clearest case I have lived through is a release process. Every release meant manual regression testing, driven by spreadsheets of who needed to check what. The spreadsheets were maintained by people who cared, which made the weakness hard to see. The work was tedious but tolerable, right up until one of those people was out and the whole release stalled with them.

Then we automated the regression suite. It runs with nobody in the loop and surfaces only when it needs a human. It holds the same knowledge, written down by the same people, but it keeps working on the day one of them is away.

An asset counts as mass if the work reaches it without anyone deciding to reach for it. A document nobody opens or a metric nobody reads is weight on the frame, not on the disc. The check is whether anything downstream would notice the artifact’s absence within a week.

Mass also only accumulates if each turn of the wheel feeds the next one, and often that loop does not close. Take a recommendation model. One team generates the recommendations, another serves them, users click or they do not, and a third team builds the dashboards that score the results. Every piece has an owner and is run well. The step where the scored result changes what gets generated next belongs to nobody. It sits between two teams rather than inside either, so it appears on no plan. Somebody standing above all the owners has to hand that step to a person by name.

A Heavier Wheel Is Harder to Start

There is a good reason mass so rarely gets added. A potter with a heavier disc kicks longer before the first pot, and adding mass to a team genuinely slows it down for months, right up until it is the only thing carrying the work.

Most of that cost is coordination. To build an evaluation suite you first have to get people to agree on what a good output is, which is slower and more political than shipping the feature would have been. It feels like overhead around the real work, but that agreement is the asset. You pay for it once, in meetings, and afterwards the judgment runs without anyone in the room. The second suite is much cheaper because the argument about what good means has already been had.

There is also a failure at the other end. The startup that builds the platform, the abstraction layer and the internal tooling before there is a product anyone wants ends up with a beautifully engineered wheel that has never turned. Mass is only momentum once something is moving.

And it is worth being straight about the third part: mass is the one you can do without. Plenty of good companies never deliberately add any, and as long as the bearings are sound and someone keeps pushing, they run well for years. I have not seen a company fail because it lacked a flywheel. Mass is closer to what separates a good company from a great one, and that is worth wanting without treating it as an emergency.

The far more common failure is the team that only ever pushes. Every quarter is features, nobody is allowed near the bearings, and a change that should take a day takes three weeks. Everyone is kicking as hard as they can and the wheel is barely moving, because a wheel on seized bearings loses the speed of each push before the next one lands.

Label the Plan

The model earns its keep as a diagnosis, and the symptom usually tells you which part to reach for.

• Everything runs smoothly and the only real problem is more work than people. You need mass. Build the thing that keeps turning when nobody is pushing.
• Nothing is technically difficult and yet everything is slow, and estimates keep coming back larger than the work sounds. The bearings need attention. Pushing harder only produces heat.
• The machine is genuinely good and very little is coming out of it. You are not pushing enough.

That last one is worth sitting with. The missing pushes are often not engineering at all: getting the product in front of people, finding more users, collecting the data the model needs. It is basic work, and strong engineering organizations often consider themselves above it.

The one thing to do on Monday: take the current plan and label every line as a push, a bearing or mass, then look at the split. It takes ten minutes and is usually uncomfortable, because most of what the plan calls investment turns out to be pushes. Most weeks the split comes back nearly all push, and most weeks that is correct.

The label leaves the plan as it was and changes what you expect back from it, which matters more. In my experience the plans that go wrong rarely have the wrong tasks on them. They have three different things, with three different shapes of return, all filed under investment, so nobody notices that the wheel was pushed hard all year and is turning no faster than in January.