Managing work you know how to do yourself
A programmer who co-founded two web companies before he was thirty has good reason to trust hands-on knowledge. The rule gets harder to keep with every hire outside engineering.
I find it hard to manage somebody’s work unless I have an intimate knowledge of how to do it myself.
Justin Kan came to management through code. He co-founded Kiko, a web calendar that was sold on eBay in 2006, and then Justin.tv, which began with Kan wearing a camera on his head and broadcasting his life around the clock. The line comes from a 2010 Inc. magazine profile of how he works, written when Justin.tv had grown well beyond its founding team.
The argument behind it is practical. A manager who has done the work can judge estimates, because they know which tasks are routine and which hide surprises. They can tell when someone is stuck and too proud to say so. They can review output with enough detail to catch real problems, and they earn the respect of specialists who would otherwise suspect that their manager does not understand what they do. In an early startup, where the founder assigns work to a handful of engineers and a wrong estimate can cost a month, that knowledge is worth a great deal.
The rule holds best in fields where the manager’s knowledge stays current. A founder who wrote the first version of the product can manage the engineers who write the second version for a while. Several years later, when the codebase has changed and the team uses tools the founder never touched, the intimate knowledge has become a memory, and memories make poor grounds for second-guessing an engineer.
It holds worst outside the founder’s home field. A technical founder hiring a head of sales, an accountant or a lawyer cannot acquire intimate knowledge of each job and still run the company. A founder who insists on it either becomes the bottleneck for every decision or ends up hiring people weaker than the job requires, because only weaker people leave room for the founder to feel in command. Both outcomes hurt a company that is trying to grow.
There is a middle version that keeps most of the benefit. Before hiring for a function, the founder does a small amount of the work personally: makes the first fifty sales calls, handles a quarter of bookkeeping, writes the first support replies. The goal is not mastery. It is enough exposure to recognize good work, ask sharp questions in an interview and notice when results drift. After that, the specialist is managed on outcomes, and the founder’s hands-on knowledge serves as a reference point instead of a standard the hire must match.
Kan’s instinct is sound for the stage he describes. It turns into a problem when it is applied at a size where no single person could meet it.