In 1776, Adam Smith described a pin factory and changed how we think about productive organisation. Most startups have heard of division of labour. Almost none have understood what it actually demands of a founder.
In The Wealth of Nations, Smith observed that a single worker making pins from start to finish might produce twenty pins a day. Ten workers, each specialising in one step of the process — drawing wire, straightening it, cutting, pointing, grinding — could produce forty-eight thousand. Not ten times more. Two thousand four hundred times more.
The standard reading of this is about efficiency: specialisation reduces switching costs, builds muscle memory, removes friction. That reading is correct but incomplete.
The deeper insight is about the nature of knowledge itself. A specialist doesn't just do their task faster — they develop a quality of understanding that a generalist never reaches. The person who does nothing but point pins all day starts to notice things about the wire, the angle, the pressure, that no one who occasionally points pins could ever notice. Specialisation doesn't just divide labour. It generates expertise that cannot exist any other way.
This is what makes interference costly in ways that don't show up immediately. When a generalist overrides a specialist, the damage isn't just the bad decision. It's the signal sent about whose knowledge counts — and the gradual erosion of the conditions under which deep expertise can form at all.
The violation rarely arrives as incompetence. It arrives as involvement. As care. As a founder who built something from nothing and cannot — entirely reasonably — switch off the instinct to shape every decision that matters.
The pattern is consistent. A technical team is hired. A brief is given. The founder is satisfied. Two weeks pass. The founder starts asking questions that aren't questions — they're redirections. Architecture choices get relitigated in Slack. Implementation paths get second-guessed in standups. The engineers, who were hired for their judgment, learn that their judgment is conditional on the founder's approval. They stop exercising it fully. Why would they?
The fastest way to slow a startup down is a founder who cannot stop at the brief.
The technical team doesn't need to be told how. They need to know why, what success looks like, and when it needs to ship. Everything else is interference dressed up as involvement.
I was working as Chief AI Architect on a system alongside a strong data scientist. The architecture we designed was rigorous: embeddings for semantic representation, cosine similarity for relevance scoring, clustering to surface structure in the data. These are not fashionable choices — they are correct choices. Well-understood, well-suited to the problem, and well-implemented.
The founder was happy for two months. Then someone in his network mentioned, in passing, that embeddings are widely used these days. Common. Mainstream.
The project was halted. The architecture was redefined. The new constraint: the system could not use embeddings, cosine similarity, or clustering. The components that had been selected precisely because they were the best tools for the job were ruled out — not because they failed, not because they were expensive, not because something better existed — but because they were no longer rare.
"Common" is not an engineering criterion.
This is a distinct and underappreciated category of founder interference. It isn't micromanagement born of anxiety, or a founder who thinks they know better than the engineers. It's something more subtle: the conflation of technical decisions with brand identity. The belief that how a system is built is part of what the company is — and therefore must reflect the founder's sense of distinctiveness, regardless of whether it serves the actual problem.
The cost was significant. Months of progress, discarded. A data scientist whose technical judgment had been explicitly overridden on aesthetic grounds. An architecture that now had to achieve the same outcomes through components selected for novelty rather than fitness. The system became harder to build, harder to explain, and harder to maintain — for no engineering reason whatsoever.
Division of labour only works if the boundaries of each role are respected. Smith's pin factory doesn't produce forty-eight thousand pins a day if the man grinding occasionally wanders over to do some pointing, or if the factory owner redesigns the pointing station because he finds the current method unremarkable.
In a startup, the founder owns the problem definition, the success criteria, and the urgency. Those are non-negotiable — and a founder who doesn't own them fully is abdicating real responsibility. But the implementation path, the architectural choices, the technical components: these belong to the people hired to make them. Not because founders lack intelligence, but because the knowledge required to make those decisions well can only be developed by people who do nothing else.
The technical team will always accommodate this. They are paid to, and they want to keep their jobs. But each accommodation teaches them that their expertise is decorative — consulted for its appearance, overridden at will. The best engineers leave first, because they have options and because they find this intolerable. The ones who remain are the ones who have learned to stop caring.
I work with startups on technology, processes, and people. In reverse order of difficulty. The technology is almost never the problem. The architecture is almost never wrong. What is wrong, with surprising consistency, is the distribution of decision rights — and the cost of that misalignment compounds quietly until it becomes visible all at once.
Smith's pin factory is a description of what happens when people are trusted to develop expertise within a bounded role. It is also, implicitly, a warning about what happens when they aren't.
A founder who sets the problem clearly and then steps back is not abdicating control. They are creating the conditions under which the people they hired can become genuinely excellent at what they were hired to do.
That is the only environment in which a startup builds something that couldn't have been built anywhere else.