In startup context, when still experimenting with product-market fit and trying to win early customers, you need generalists to be able to quickly change direction when necessary. Specialists have too much inertia in such cases.

When searching for product-market fit the last thing you need is changing your tech stack on the fly. Generalist can help you to bootstrap your initial stack if she has a good knowledge of all components, but specialists allow you to focus on what really matters, building foundation of your ops while you experiment.

A good generalist will not change your tech stack on the fly. Of course that’s a bad idea.

I think what GP meant is more like they will be willing to change what they are working on day to day in response to what you learn from the market, and will be fine with throwing lots of things away if they don’t work.

If you focus on foundational work too much that comes with the trade off that you can’t spend as much time building features. It’s common to see engineers fall into this trap.

If we are not talking about one person team, frequent context switching is counterproductive and same jobs are better done by two specialists (e.g. FE and BE) than two generalists. It’s also a common trap to build a lot of features without any evidence that users need them, 30-40% of effort wasted on something that does not have enough business value or on validating with code hypotheses that could be validated by one email with typeform.

Nooo, as literally a person doing this right now, splitting up the work is a terrible idea.

Almost everything you do is "wasted" effort at this stage (until it suddenly isn't, and arguable if failed experimentation is "wasted" in the first place), you need to be okay with that when in this role, and everyone needs to know how to do everything if you want to even have a prayer of a chance at a normal life.

You must learn new tech quickly, and pivot to different decisions if it makes more sense to do something another way. You also must be okay with terrible code written hastily, as long as it's good enough to not have any fatal bugs in it, and the only way I know how to do that is to have another person to validate/refute your work.

> What do you mean by smart? A well organized moderately smart person is more productive to a company than a disorganized genius.

Maybe Yes, maybe No, depends entirely on the job function they're in, the assumed style and heaviness of management and how much communication (if any), let alone oversight, they are obligated to have with their peers and subordinates. I have seen people who rarely emerged from their room/cubicle yet consistently produced brilliant code; versus people who looked and sounded amazing in meetings yet didn't deliver. There is definitely such a thing as too much communication, btw, which Elon Musk points out regularly. Have you ever been inside a company that talked and meeting'ed and memo'ed itself to death? I have. Sometimes you need a crew that simply quickly agree a sensible plan, shut up and build the dang thing lightning-fast before the cash runs out and the lights get turned off.

There are organization styles that thrive on lone wolves and ICs and know how to manage them hands-off, and ones that thrive on big-company style corporate 'team players'. There's a place for everyone.

'smart' IME is far less a measure of IQ/EQ and more 'robustly adaptive to whatever arbitrary management structure you try to force on them'.