Part one of a three-part series on lean versus redundancy in hardware. This one is about your team.
For most of a decade I was the team hardware startups hired so they wouldn't have to build one. Roughly half my career was spent as a consultant and contractor, and one pattern almost never changed: the founder was trying not to staff.
That instinct is correct. It is also the beginning of a problem nobody warns you about.
Why You Run Lean in the First Place
Running lean has exactly one job at the start: don't spend a lot of cash, and don't sink your resources into developing an idea you haven't validated yet. A full-time engineer is expensive. Outsourcing to a consultancy is one way founders mitigate the risk of burning cash on a bet that hasn't paid off.
This is the right frame early on. You are not trying to build the org chart of the company you hope to become. You are trying to find out whether the thing is worth building at all, while spending as little as possible to learn that.
So you run lean. The question is how lean, and that turns out to be a ladder, not a single choice.
The Ladder of Lean
The leanest you can possibly run is not hiring anyone. You build the product yourself, as a team of one. One rung up from that is still not spending cash: you bring in a few people who work for equity. A team of one, or a few co-builders trading time for ownership, is as lean as it gets.
Above that is where you start actually spending money, and the rung you land on depends on how complex your product is.
If you have a relatively complex product, something electromechanical that needs mechanical design, electrical design, firmware, and software, a consultancy is usually the smart move. The math is simple: if you need four different specialties, finding four different engineers is expensive and hard, and if you aren't deeply technical yourself, managing all four is harder still. A consultancy hands you those specialties as a bundle, and usually a project manager to keep them coordinated.
For simpler products, you can often go a rung lower. A freelancer working part-time is cheaper than a consultancy and lets you keep running lean while you make progress.
Then comes real headcount. This is where you decide between one person who can do a bit of everything but is an expert in nothing, and specialists hired for specific gaps. The more complex your product and the more specific your needs, the more you are forced toward specialists, and the harder it becomes to stay lean.
Every one of these rungs is a cash decision, and on the cash axis the logic holds. The trouble is that cash is not the only thing you are spending.
The Consultancy Rung Hides a Trap
Say you hire a consultancy, they build your product, and then you decide you're done with them. Where does everything they learned go?
Not to you. A large share of that institutional knowledge now lives inside their company, not yours. And if you lose that relationship, because it sours, or because they lose the key engineer who actually did your work, you lose the redundancy you thought you had.
The knowledge isn't destroyed. But unless you were documenting properly, unless you had a real process for managing your BOM, your change orders, and the rest of your engineering documentation, that knowledge is now locked somewhere you can't reach. You rented a team, and you rented their memory along with it.
One Specialist Per Field Is a Bus Factor of One
The same trap shows up when you finally hire.
Whether they are co-founders or your first employees, you are usually hiring one person per field. One electromechanical engineer. One software engineer. Each of them is holding an entire discipline in their head, and often that is the only copy.
Then someone has a falling out, or moves, or makes a life decision that has nothing to do with you, and walks out the door with a discipline's worth of context. That is the weak point of running lean that people don't talk about: when you run lean, you lose redundancy, and when you lose redundancy, you are exposed the moment something goes wrong.
Software people have a name for this: the bus factor. How many people can get hit by a bus before the project stalls. On a lean hardware team, the honest answer is frequently one.
Startups Run Lean on Documentation, Too
Here is what makes it worse. Startups don't just run lean on headcount. They run lean on documentation.
The culture is build fast, and don't write much down. Documentation feels like overhead when you are trying to move, so it slips. That would be survivable if your team were deep. It is not survivable when your team is thin, because the two shortcuts multiply. A thin team plus thin documentation doesn't mean your bus factor is one person; it means your bus factor is one person who also never wrote anything down.
And this cuts harder in hardware than in software. In software, a lot of the knowledge is trapped in the code whether the team likes it or not; the repository is a rough form of documentation on its own. In hardware, the reasoning behind your decisions does not live in a compiled artifact. Why is that component a DNP. Why did the tolerance stack land where it did. Why did you switch suppliers on that connector. If nobody captured it, it is genuinely gone when the person is gone. Your BOM and your change history are the closest thing hardware has to a repository, and only if you actually maintain them.
The Real Question Isn't How Many People to Hire
None of this is an argument to go hire redundant engineers. That contradicts the whole reason you're lean, and for most startups it isn't realistic anyway.
The point is to know the trade you are making. Running lean and running redundant are the same decision seen from opposite ends. Every rung you climb down the ladder to save cash is a rung of redundancy you are choosing to give up. That is a legitimate choice. It is only dangerous when you make it without noticing.
So weigh it actively. Cash flow on one side, redundancy loss on the other, managed on purpose by the founder rather than discovered the week your one firmware person quits.
And there is a lever that lets you keep most of the cash win without eating the full redundancy risk: documentation. Good documentation is how you buy redundancy without buying headcount. It is cheap insurance against the exact key-person risk that running lean creates.
It does not take much. A practice I recommend to every lean team is simple: once a week, on a Friday, your engineers spend an hour or two writing down what they did that week. What changed, what they decided, and why. It goes somewhere the rest of the company can actually reach it, a Google Doc, a PLM system, anywhere that isn't one engineer's head. That is a couple of hours a week against the risk of losing months of context. The trade is not close.
AI Changed What Documentation Is Worth
There is a reason this advice lands differently in 2026 than it did five years ago.
Documentation used to be a write-only graveyard. Someone spent Friday afternoon writing things down, the doc went into a folder, and nobody ever opened it again. The effort was real and the payoff was theoretical, which is exactly why teams skipped it.
AI flips that math. It no longer matters much whether your notes live in a Google Doc, a Word file, or a PDF; a model can now read all of it and answer questions from it. Your documentation stops being a static archive and becomes something you can actually talk to. When that one engineer leaves, the context they wrote down every Friday is still there, and now it can answer for them.
That is where the whole industry is heading, and it changes the cost-benefit of documentation for every hardware team, regardless of what tools you use. The cheaper it gets to turn written-down knowledge into answers, the less excuse there is to run lean on documentation while you run lean on headcount.
A PLM system is one place to keep that knowledge structured and tied to the BOM and change history it describes, rather than scattered across folders. Whatever you use, the principle is the same: run lean if you want, but write it down, because the redundancy you spent is exactly what documentation buys back.
This is also, not by accident, the same lean-versus-agile tension that plays out on the product side rather than the team side; if that is the fight you're in, start here.
Run lean on purpose, not by accident. If you want one place to keep your BOMs, revisions, and change history so the knowledge survives the people, see how it works at oroforge.com.
