01 June 2024
Many developers get really excited when they join an R&D team, because it signals in their minds that they're among an elite group looking to move the needle for a company. We imagine the business suddenly soaring in revenue and profit because of the whatever-thing we just built. We can hear--in the mind's ear--the kudos and praise raining down from the C-Suite as the whatever-thing we just built is rolled out company-wide and maybe, just maybe, industry-wide. We're excited!
Wait, what was it we were trying to do again?
In my last post, I talked about some of the problems with R&D teams and how they're run. What I didn't really get into in that post, however, was the idea that (I believe) there are four different kinds of R&D teams, each with very different actions and goals, and each with very different outcomes. The success of the team often depends on aligning the activities of the team with the intended goals, and it's actually quite reasonable for a company to have two or more teams, each operating independently and towards different ends.
In brief, there are four kinds of R&D Teams:
In each of those subsequent posts, I address each of these in some level of detail, but here's summaries for each:
The Scout Team is what most corporate R&D teams go after: The hunt for new technology that will somehow provide the company with a competitive advantage over its competitors, despite the fact that the competitors are all themselves out there scouting the industry just like this team is. New programming languages, new databases, new architecture styles, new whatever-fill-in-the-blank, just so long as it is (a) new and (b) not yet mainstream, it's a candidate for the Scout Team's infinite desire to create prototypes that bear a remarkable resemblance to the demos that the new thing has on its website or in its documentation.
The Library team is the team given responsibility for managing reusable artifacts within the company--libraries, tools, frameworks, services (cloud or on-prem), whatever--because achieving actual reusability, it turns out, requires a degree of commitment of time and resources to maintaining and homogenizing those artifacts. Doing this work, at the same time a team is trying to manage a product release, ends up becoming a distraction to the product release cycle, particularly as the shared "thing" becomes more widely shared.
The spy team's purpose is pretty much as its name implies: Take a strong look at what competitors and adjacents are doing in your industry, and how they do (or might) affect your company's activities. The spy team doesn't get industry press articles written about the things they are doing, but they do often adopt a technology quickly enough to make a difference without paying the cost of finding all the mistakes and wrong assumptions about it.
The Research team (also more recently called "the innovation team" or the "disruption team" in more "hip" companies) is the one most people think about with respect to an R&D team. It's important to note, however, that the team cannot be just focused on research--like the Scout team, the Research team has to have a constant eye on what they build having a practical impact on the company that sponsors them. For that reason, I often make the conscious decision to put the word "practical" in front of the name, so that the emphasis is on practical research that will have a direct effect on the company's ability to execute.
Last modified 01 June 2024