One of the biggest changes I have noticed since changing companies is that I now get to meet many more people from other organizations. Along the way, I hear a wide range of stories and get to exchange views.
Recently I met someone wrestling with a topic close to my heart: global R&D. Their question was, “What work should we assign to our overseas research centers?” It is a short question, but a genuinely hard one.
At a basic level, large companies run multiple research sites overseas because the headquarters has its own research capability and because the environment allows them to source a wide range of technologies.
When I was responsible for an R&D portfolio, the question I ran into most often was, “Do we get better results when several research centers collaborate on a particular technology or project?” So I am taking this opportunity to set down my thinking.
To start with the conclusion: when dividing up work, I recommend always asking one final question.
“When this project is over, what capability will the research center have built up? And does that fit the long-term strategy for running and managing the center?”
And where possible, I think it is better for a single center to own the work from start to finish, provided the technology is closely related to what that center does and it has the capability to deliver.
There are three reasons.
First, the language barrier.
These days many tools, AI in particular, help with translation. But human nuance is more complex and sensitive than we tend to think, and translation does not guarantee that what I said was understood the way I meant it. When people work in different languages, many sensitive issues in meetings and verbal discussions pass by quickly without being fully understood. The gap only surfaces when the outputs are put together, and by then time and resources have already been spent. In almost every case, the 1:10:100 rule holds remarkably well.
Second, cultural differences.
This is not a claim that one culture is better than another. The way problems are defined, the way decisions are made under uncertainty, the timing of sharing interim results and the definition of “done” all differ. For example, on one project I asked a research center in Eastern Europe to summarize the project’s risks. I remember they identified every detail and sent back an exhaustive list. I was grateful for such a thorough review, but the feedback from the development team at headquarters was: “With this many risks, I can’t tell whether they want to do this project or not. I question their commitment.” Similar episodes happened again and again, and I believe they reflected cultural traits. This happens more often than you might expect, not only across national cultures but also across the cultures of organizations and job functions. Diverse perspectives are a strength, but when you are building a single deliverable, the plan has to include the time it takes to reconcile those differences, and that takes considerable time and effort.
Third, and most important, the assets that remain in the organization.
When an R&D project ends, it leaves behind more than code and design documents. In most cases the work is written up, and those documents remain as organizational assets. Yet outside of urgent situations they are used less than you might expect, and quite often they are only truly understood when what they describe meets real experience. What remains is an understanding of why a method was chosen, what was tried and failed, and under what conditions problems arise. That understanding cannot all be transferred into documents; it accumulates in the people who did the work and in their organization. Over time it becomes a powerful weapon and asset.
If you split each project into small work packages and hand them out, you will collect the deliverables, but building the capability to keep advancing that technology is a different matter.
That is why I believe the basic unit for dividing work should be the ’technology domain’, not the ‘project’.
For example, if one center is given image processing, its responsibility should not end with a single feature in this product. The responsibility to advance that technology should carry over to the next product as well. Within that domain, you separate advanced research, productization and maintenance, and set the scope to match the center’s capability and size.
Even when other centers take part or take over the work, the owner of the domain must be clear, and that should be settled by strategic decisions at the company level. And when work is handed over, it is only an effective, proper transfer if the reasoning behind decisions and feedback from the field go along with the deliverables. Of course, this is very hard. The handing-over side wants to pass things on quickly, the receiving side wants to take them over carefully, and the longer this drags on, the faster the costs climb.
Of course, it is not easy to bring talent and customer knowledge together in one place. So the overall architecture and the standards for connecting centers should be set jointly, and collaboration between centers should actively draw on each center’s expertise.
In short, it is a structure in which each center is the owner that keeps growing the technology it is responsible for, while also taking clear responsibility for a shared outcome. I see this as one of the key principles for allocating work in global R&D.
With these thoughts in mind, we talked about many things, and if there was just one thing to remember, I recommended starting and ending with this question:
“When this project is over, which research center will have built up what capability? And does that fit the company’s strategy?”
#GlobalRnD #RnDManagement #TechnologyManagement #OrganizationalLearning #Networking #Knowhow
