Lessons scaling from 10 to 20 people
Interesting read, though I&#x27;m a little wary of the turning generalists into specialists point being taken too far. There are a lot of unwritten assumptions behind that idea.<p>For example, let&#x27;s consider a business that does something many of us here are familiar with: making a web app. There&#x27;s a trend in web development world these days to put every little thing into its own silo. We separate front-end and back-end people. We separate back-end developers from DBAs and operations people. We separate designers and front-end developers. We invent whole new job titles using trendy terms like &quot;user experience&quot;, as if making a good UI hasn&#x27;t always involved doing the same things.<p>The real world does not work like this. In the real world, all of these things are related, and what matters is the overall result. In the real world, there are many different skill sets, but almost no-one is an expert at one thing and has little if any knowledge of the others. And crucially, in the real world someone can often do one part of a job much better if they also have substantial knowledge of some of the related parts.<p>So I think generalist vs. specialist is almost always a false dichotomy once you get beyond the crude &quot;Yes, the CEO probably shouldn&#x27;t also be the guy spending all day debugging a tricky rendering glitch&quot; level. One &quot;generalist&quot; with skills&#x2F;knowledge in more than one area can easily be more productive than multiple &quot;specialists&quot; who each know their own area but don&#x27;t really understand the relationships to adjacent areas, and thus need significant process and management to work effectively at all and still probably incur significant overheads. IME, the principle of keeping a level of generalism scales up just fine as well: those with the broader knowledge and skills often become good candidates for technical leadership roles in growing organisations.