This seems very software focused and in my experience doesn't really apply to e.g. an engineering company.

Completely missing is e.g. simulation or in general evaluation of designs. In my experience teams also do multiple tasks, e.g. when you are doing simulations you also have to look at how the simulation can be improved or whether repetitive simulation tasks can be automated. Nobody besides your team could do do this research on new methods, simply because nobody else really understands your tasks and activities.

This doesn't look like the R&D I see in actual research centers - like places where you can play with particle accelerators, big pools, wind tunnels, microscopes.

This article reminds me of The Art of War, wherein Sun Tzu often classifies different war-adjacent concepts in terms of the number 5 - - 5 types of terrain, 5 types of spies, etc. As you read you can tell there are obviously more than five types of something. Yet the classifications are not without use. They serve to focus the reader on perhaps the "top 5" things, and serve to keep the text short while also still useful.

Surely there are more types of corporate research teams than four, but I still find the formulation instructive. I can see why these types of research activities deserve treatment and discussion. Further, the article made its point neatly in just a few paragraphs.

I worked in an R&D team at a bigco. My team didn't cleanly fit in any of these archetypes. Our goal was to do the same thing as the core ML team, but with higher tolerance for risk (2x the timeline allowance on new ideas before calling it quits for example) and with a higher bar for success (small launches that would be okay for the core team were not big enough for us). We had pretty free reign over the approaches - whether that's looking at academic or industry breakthroughs, porting existing internal breakthroughs to other areas, or new innovation.

Not really sold on this take. It seems pretty bigco-focused and a bit weak and arbitrary.

You could equally divide R&D teams in many other ways, eg. academic vs. startup vs. bigco, shipping vs. pre-market, targeted vs. wandering, focused vs. scattergun, single domain vs. cross-domain, business focused vs. possibility focused, full time vs. part time, dedicated space and facility vs. shared with production, etc.

I once worked for a company where their R&D team just acted as a middleman between the company and research organizations like universities and national labs. It worked well as the universities and national labs have funding for out-there stuff, but lack actual data and often a true understanding for how things work in industry. A lot of the companies in industry often don't have the resources (or priority) to do their own research, so sometimes both camps benefit.

You could probably add like 10 more categories to this if you include actual traditional engineering companies (e.g. mechanical engineering). I do a lot of simulations myself with real models and haven't done any super theoretical journal work yet.

I felt like this take was pretty spot on, and I think a lot of dissatisfaction can arise when folks feel like they are on the research team, but are actually on the spy team.

That spy team sounds fun to be on. Any advice/reading recommendations to built such a team?

Can someone please explain to me how this is not an https page in 2024?

The http://www.newardassociates.com/bio.html has enough information about this person that I really don't think their explanation of R&D makes sense.