Reinventing a Small Wheel
Picture someone who spends a whole Saturday building a spice rack. Not a nice one. The shelves come out slightly uneven, and the jars on the bottom row lean toward each other like tired commuters. A hardware store two miles away sells a better rack for nineteen dollars. Everyone who sees it says some version of the same thing: why would you make that when you could just buy one?
Suppose the answer is that they now know exactly how deep a shelf needs to be for a jar of cumin. That sounds like a joke. I've come to think it's a fairly serious point.
"Don't reinvent the wheel" is probably the most repeated piece of advice in any office I can imagine. It gets said in planning meetings, and it gets said in the first week of a new job, usually to the person who proposed doing something differently. And most of the time it's correct. If a working process exists, using it is cheaper than designing a new one. Nobody should write their own payroll software for fun.
But the advice has a blind spot, and it's a big one. It assumes you understand the wheel you're being told not to reinvent.
Inherited templates
Think about how most work actually gets done. Someone joins a team and is handed a template. A proposal format, say, with seven sections in a particular order. The new person fills it in, faithfully, for two years. They never learn why section four exists. Maybe it was added after a client complained in some year nobody remembers. Maybe it was copied from another company's template that was copied from somewhere else. The section stays because removing it feels like reinventing the wheel, and we've all been told not to do that.
Multiply that by every spreadsheet, checklist and standing meeting in an organization and you get a peculiar kind of building. Every room is furnished. Nobody knows who chose the furniture. People walk around the coffee table in the middle of the hallway because it has always been there.
The person who rebuilds one small thing from scratch learns something the template user never does. They find out which parts carry weight. You write a proposal with no template and discover, around the third paragraph, that the client really does need to see the price before the timeline, because otherwise they skim the timeline looking for the price. Now section four makes sense. Or you discover it doesn't, and you can make a case for cutting it that isn't just a feeling.
There's a version of this in cooking that most people already accept. Recipes are wheels. You follow them. But anyone who cooks regularly eventually makes a dish without one, badly, and that bad dish teaches them more about salt and heat than the previous fifty good ones. Nobody calls that wasted effort. We call it learning to cook.
The small wheel, not the big one
So I'd amend the advice rather than throw it out. Don't reinvent big wheels. Do reinvent a small one now and then, on purpose, when the cost of getting it wrong is low.
The trick is choosing which. A rough test I use: could I rebuild this in an afternoon, and would anyone be harmed if my version were worse for a week? If both answers are comfortable, the rebuild is cheap tuition. A weekly status email qualifies. So does the agenda for a meeting that happens every Tuesday whether or not anyone needs it. The company's billing system does not, and neither does anything a customer touches directly. That second category deserves the original advice in full.
When you do rebuild, the goal usually isn't to replace the old thing. Often you end up back where you started, with the original template and a much better understanding of it. That still counts. The template is now something you chose rather than something you inherited, and you'll defend it more sensibly when someone else asks why it's shaped that way. Occasionally you find a section that does nothing at all, and quietly deleting it saves a few minutes a week for everyone who touches it. Those minutes add up over years in a way that's easy to underrate.
I'll admit I'm not sure where the line sits for a manager. Letting every new hire rebuild the onboarding checklist would be chaos. Forbidding it entirely produces people who follow steps without knowing what the steps protect against, which is how a checklist slowly turns into a superstition. My guess is that the honest move is to say out loud which things are open to tinkering and which aren't, and to explain the reasons behind the ones that aren't. People respect a fence more when they know what's on the other side.
There's also a cost the advice-givers rarely mention. When people never rebuild anything, they lose the confidence that they could. A team that has only ever used inherited tools tends to freeze when one breaks. A team where someone once made their own clumsy version of the status report knows, at least, that the thing is made of parts and the parts can be moved.
Back to the spice rack. I'd bet it stays on the wall for years, bottom row leaning, with its builder always meaning to buy the nineteen-dollar one and never quite doing it. It's hard to give up something you understand all the way down, even when it's crooked.
Jonathan Endicott (Jonathan Weston Endicott) is an entrepreneur and creator who writes about building, momentum and discipline. More at about Jonathan Endicott, on Instagram at @jonathanwendicott and at linktr.ee/jonathanwestonendicott.