[p4wnc6]

One problem with this that many orgs face is that later down the road when your business has grown, now you need to hire a lot of specialists (usually in a big hurry), and in fact at that point hiring the new specialists often matters way, way more than continuing to take care of the generalists who got you to that point.

On one hand, if you defer to the market, you'll end up being forced to pay high wages to those later-on specialists, and probably also more equity than would otherwise be warranted for their time of entry to the firm. Lots of early-on generalists could get mad that they aren't paid well and that even if they have more equity, it's not fairly proportioned to how much up-front work they put in.

On the other hand, if you don't agree with this market problem, then you end up hiring only specialists who don't know how much they are worth, or else have other factors that make them cheaper to hire -- generally meaning you hire crappier later-on specialists to save money and to keep the equity proportions "fairer" to the early-on generalists. These firms often get a bad reputation for doing crappy work in the specialist area, and specialists stay away from it.

I see this a lot with machine learning. A smart machine learning specialist is not going to join a Bay Area start-up for $150k and 0.1% equity as employee number 40. If you waited until employee 40 to start investing in highly specialized machine learning talent, and it's something your business needs, then you're either going to have to raise the wage super high (much higher than the early-on employees who may resent this), or you're going to have to offer completely disproportional equity, or both; or else, you're going to have to hire inexperienced and/or crappy people who don't mind taking a job as employee #40 for that kind of "conventional start-up wisdom" pay/equity range.

To me, this suggests one hypothesis is that start-ups preferring generalists is actually a bad idea. Instead, they should excel at forecasting which specialists they'll need, then hire the best of that speciality very early on. To entice them to put up with generalist work for a while, pay them a lot or give them better than market equity, and be as flexible as possible with what kinds of working style / environment you offer them.

Then when the time comes to really turn up the heat on specialist labor, you'll already have the specialists, and they'll already know how the systems work. At that point, you can expand hiring on the generalist front, which should be relatively easier to do at the current start-up wage level, and have those later-on generalists take over the maintenance and generalist work from the early-on specialists.

This is way easier said than done, of course, but it would be interesting to see whether there's a relationship between start-ups that succeed and start-ups that choose to specialize early and generalize later. Most start-ups fail, and anecdotally, most start-ups also seem very inflexible about accommodating what an early-on specialist might want (like say, to avoid working in Agile or to work in a quiet office) and seem more geared toward hire pools of generalists (mandate team-wide Agile, have lots of social outings, use open-plan offices). Maybe this is a big part of going wrong?

[zaidf]

Problem with that is most specialists suck or have very little interest in generalist work.

People became specialists because they particularly enjoy that kind of work. When you put them in an environment where things are changing rapidly, including their day to day nature of work, in my experience most specialists don't respond well to it.

I actually think hiring too many specialists is one of the biggest mistakes early stage startups can make.

[p4wnc6]

I agree specialists will not be satisfied with just doing generalist work without any other offsetting compensation, but this is why I said you have to pay them well and be very flexible about work style and work environment. You're already selecting for specialists who were open enough to the idea of working at a start-up that they even applied at all. That self-selects for some things, and an open mind towards generalist work is probably part of it. But just because they are open to the idea of sacrificing time they could otherwise have spent gaining more specialist experience in order to do early-on generalist work for your start-up, that doesn't mean they'll do it cheaply or be willing to fit into cultural situations they don't feel compatible with.

It's hard for me to believe most start-ups can really say anything conclusive about the quality of early-on specialists, because so few start-ups are willing to be flexible with office layouts, introvert v. extrovert working styles, and many other things. If a start-up is simultaneously rigid about those types of things and also claiming they can't get a good early-on specialist, well it's no surprise why they can't.

For legitimately cash-strapped start-ups, I think your point would hold true. Even if they are very flexible, they just won't be able to afford a good early-on specialist at all, even such a specialist who is already sympathetic to start-up lifestyle and willing to trade some salary for flexibility on certain working conditions won't go for it.

[pottereric]

The other factor to consider here is that not all specialists are focused on a technology. Some specialists focus on a process or a business domain. If a startup is working on financial software, finding someone that has a deep knowledge of finance software might be incredibly valuable. This could be very true if your software needs to meet regulatory requirements like Sarbanes Oxley.

[zaidf]

I assumed the context here was developers. For other kind of specialists, they can be INSANELY valuable from the get-go. In fact, one of the first hires I'd recommend anyone doing enterprise startup is hiring a domain specialist. These people are relatively inexpensive and add tremendous value in giving product feedback between early iterations. They can also talk to early customers with more credibility and thus help adoption of certain features that the customer may other not see much value in.

[pottereric]

Actually, I was talking about developers. In my experience working on projects that needed FDA part 11 compliance, it can be incredibly helpful to have developers that know how to write software that meets to compliance rules from process, validation, and auditability standpoints. I presume the same is true for SOX or HIPPA.