21 Jan 2020
The (Different Kind of) Information Advantage
I’m in the middle of Range right now - a book about the value of generalists - and I am more and more starting to see all around me that there is a delicate balance between good, classic Adam Smith specialization and overspecialization.
Adam Smith says that specialization of labor is good because thousands of workers divided into specialized tasks can produce things faster than thousands of workers all responsible for all the tasks to produce one widget. This makes sense for things like widget production, where one task often does not impact another task and knowledge in one task generally does not impact another task.
In economies like the United States where most businesses are service-based businesses, there are not many widget-producers left. An increasing amount of the S&P 500 is dominated by software businesses. The people who write the code need to know a whole lot about the product, and the people who decide product direction need to know at least a little bit about the code.
I have heard arguments that the second part of the last sentence isn’t true. I have heard scrum masters should necessarily be non-technical; that knowledge of the codebase creates biased constraints about how long something will take. These are good arguments I in part agree with. Good leaders do not get tied to architecture and are willing to scrap everything if scrapping everything and rebuilding offers a higher return than the alternative.
Yet, estimates for how long something will take (one of the inputs necessary to calculate total return, because almost all return estimates are annualized) need to come from somewhere. They come from engineers or people who ask engineers for inputs. If these estimates are non-starters, the product usually gets adjusted so it can be built faster.
What does this have to do with specialization? In a completely specialized world, the engineers don’t understand the product and the product specialists don’t understand engineering. A strange hybrid position (scrum master? product manager? project manager?) tries to bridge the two and the result is that unless the hybrid specialists are executing perfectly, estimates veer wildly from reality. The business cannot execute on projects over its hurdle rate because it can’t calculate ROI. The company fails.
In a less specialized world, everyone is considered responsible for understanding a little bit about the entire business. The CEO has strong familiarity with the software development lifecycle; the software engineer knows estimates for next year’s EBITDA and what the main business drivers are. Each feels empowered to weigh in on areas outside what their core competencies are. Each is quickly building strong skills in things other than the thing they were hired for. Estimates are good because everyone’s bullshit detector is a little stronger. It’s harder to fool someone who knows a little about everything than everything about one thing.
Interestingly, this is one reason why I think people who start companies usually start more companies. The founder is not able to opt out of learning things outside their core competency. The Buffett-Munger compounding knowledge cycle kicks in and founders become more and more capable of starting more companies.
Additionally - and Range really hits on this theme a ton - industry outsiders gaining knowledge on an industry for the first time are likely to have unique mental models for thinking about said industry. If these models provide valuable perspectives and are unique, it’s likely that person can offer value-add ideas that the market isn’t pricing correctly.
Offering opportunities for specialists to become generalists I think is an easy way for companies to add shareholder value. By helping generalists grow, companies 1) improve ROI accuracy by getting estimates that reflect people with growing skills in a range of topics and 2) increase the likelihood of finding business advantages the competition hasn’t valued correctly.
