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.
Agreed. I work in medical device engineering, and >50% of our time relates to simulation in some way. A big part of our responsibilities is designing, implementing, or reimplementing models of various subsystems relevant to our devices so we can do preliminary estimates of safety or efficacy. Analyzing real world outcomes is also important, although I haven't been at the company long enough yet for that to catch up with simulation in terms of how much time we spend on it.
I'd say the closest description to us in the article is the practical research team. We have fairly clear business goals we are fulfilling with our work.
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.
Seems fairly lightweight to me as well, but I think that is the point - this is a teaser for content the author intends to expand upon in later posts. So as just an intro, it seems fine. I do hope if they continue to write up this content, they focus more on why this categorization matters and what benefit it offers an organization to conceptualize their teams in one of these ways.
In general, unless it's very pre-market and exploratory/academic, research and development almost implies BigCo--and it tends to tilt towards development over time. The obvious exceptions are both pretty rare and last about as long as the company has a bunch of extra money to toss around.
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.
To be fair, in those pictures at the bottom he does actually look a lot like The Dude. I was thinking it was all bluster until I scrolled down and saw them!
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.