Summary
This article discusses some of the challenges facing corporate research groups. This is a splinter discussion motivated from comments by Frank Sommers in entry entitled "On Avoiding Being Pigeonholed." What are your experiences with research?
Advertisement
In my prevous topic, "On Avoiding Being Pigeonholed," Frank Sommers provided a teaser for this topic on corporate R&D:
> Finally, I thought your comments subtly addressed the
> challenges many organizations' R&D departments face. I
> don't have first-hand experience with the workings of such
> departments, but I always sensed that R&D departments'
> roles are somewhat reversed. Instead of R&D coming up with
> product ideas, they often try to "push" their inventions
> onto product development. I would be interested in hearing
> others' comments on the subject of corporate R&D and
> product development.
Below I discuss four major challenges facing research departments: measuring success, gaining traction, flowing technology, and fostering a corporate culture that justifies having a research organization.
Measuring Success
From my admittedly limited experience, the challenge of capitalizing on research dollars seems to be quite daunting. Every corporation would like to see a significant positive return on research investment. I wonder what percentage of large corporations actually do see a positive balance? I suspect the actual numbers are tightly held (if it is even known with sufficient precision).
It is confoundingly difficult to measure the success of a research organization. We spent X dollars on research this year. How much money did that make us? Research organizations work on many projects, so a more useful question is, how much money did each project make? Answering that answers the first question.
One problem is time. A unit of research can realize actual profit anywhere from a few months to many years. A project can operate for a very long time on potential value before someone realizes it's a waste of money. On the other side of the coin, a key invention could be a jackpot but it is not realized until a decade has pasted. That's got to drive the corporate accountants crazy.
From the 10,000 foot level, there are two kinds of projects: those that have the attention of one or other organizations, and those that don't. Any project that is engaged with an internal customer has instant credibility, even if it never makes a dime. The other kind of project exists only on hope. Hope that another group will become interested; hope that a new market will emerge or be defined; hope that the results will "change everything", etc. Again time is the key. If it's fundamental research with a huge potential win, then a grace period of several years may be in line. If the project is targeting an existing market, technology or product, then it won't have long to succeed or fail. Conditions will change and make the project obsolete.
There are other, fuzzier ways to measure the value of research. When I say corporate research, most people in our industry would probably think of AT&T, Xerox PARC, IBM, or Microsoft. Good research organizations generate another kind of capital that isn't measurable in dollars and cents. People identify with these companies as technology companies and this is a key part of their branding. A good brand is nearly priceless. Consumers want products from these companies and employees want to work for these companies.
A useful measure is the ability of a research organization to capture intellectual property. This is pretty easy to measure and therefore, should be relied upon; but not too heavily. Patents and publications are ways in which research can generate significant protection and revenue from inventions.
And then there's visibility. Through publishing, speaking, committees, standards, etc, researchers make a positive name for the parent organization.
All this is good for a corporation, but unfortunately, when money is tight, it requires incredible discipline for a corporation to resist viewing research as overhead. Research investment is typically determined as some percentage of revenue or profit. As the companies revenues shrink or grow, so do research dollars. I was let go because we'd reduced our business dramatically (50K employees) and research spending was out-of-whack. Unfortunately, someone has to pick who goes and value (as described above) plays a part. Some other factors are important too: relative pay, performance, individual overhead, work location, etc. Surprisingly other factors weigh heavily: sex, race, visa status, litigation history, liklihood of future litigation, etc.
Gaining Traction
In my organization, we referred to engagement with another organization as "gaining traction." Until you actually had a sponsor, you were just spinning your wheels. Living on hope. One of the hardest parts of our job was to get connected with an internal customer. We faced several inherent challenges.
The product organizations tended to have short delivery horizons. This meant that they were busy churning out products with incremental improvements. It was difficult to get them interested in anything that didn't fit into their short-range way of thinking. The trick was to get on their mid-term roadmap and work with them to achieve the release. Unfortunatley, many groups felt they were too busy to afford the overhead of coordinating with research. From a research perspective, one had to be careful that the work actually was research. We weren't going to be in the business of subcontract development. So right off the bat, there was a potential timeframe mismatch and a content mismatch. Development wants it now and the deliverable has to work out-of-the-box, researchers are focused on ideas that take time to evolve. This leads to the next inherent challenge.
Product teams often view researchers as ivory-tower types who can only throw together shakey code unfit for customers. Researchers view developers and primitive and narrow-minded; unable to recognize an opportunity if it hit them on the head. The problem is a lack of understanding of one-another that leads to an inability to adapt to each other and their proper roles within the corporation. Researchers are supposed to elaborate ideas to the point where they could be made into product. Developers are supposed to, well, develop. That is not to say developers should shun their own ideas or that researchers shouldn't take care when coding. Both parties ought to view each other as part of a continuum rather than as opposing philosophical entities trying to do each other's jobs.
Similar problems and prejudices can arise between marketing organizations and research groups. When a research idea doesn't fit within exisiting product groups or when it is disruptive in nature, marketing is the appropriate target. But, if it's hard to get development and research to talk the same language, it can be nearly impossible with marketing types. At least that's the perception. My preference is to work with competent marketing people as they seem to be more creative and less entrenched in their thinking. Regardless, in the absence of a corporate culture that intentionally fosters collaborative relationships among product teams, marketing, and research, each organization can become isolated.
Back when my employer had more money, many of the product (and even marketing teams!) had their own "advanced development" groups. In fact, until about four years ago, the company didn't have a research organization. AD groups were how research got done. Later, after the research organization was created, some of the remaining AD groups recognized the benefit of working the middle between their parent team and research. Most, however, felt research was a redundant function that they shouldn't have to pay for. When the lay offs started over two years ago, ADs were some of the first to go. They were the redundancy! For a while, this was a boon to our research group because people who never had a need for us began to work with us.
That brings up another can of worms: who pays for research? In our company, we had several diverse product organizations and each one payed a tax. They were told to pay it, but they didn't like it. Improperly handled, this set up a confrontational situation where the new research organization had to prove their worth. This negative attitude didn't make working together easier.
Push-Me-Pull-You
Research organizations talk about pushing and pulling technology. A research organization independently comes up with a good idea and then must push it into other organizations. Or conversely, some other organization has an idea and pushes it into research to get it elaborated for future use. For this to work, the other organization must be willing to pull the idea in. A healthy corporation fuses these models through strong relationships, kind of like the Push-me-pull-you is a fusing of two llamas in Doctor Dolittle. They look in different directions, but they are both part of the whole. Ever notice that the two half of the animal are rarely at odds?
Ideally, a product or marketing group recognizes gaps in its roadmap that it knows it cannot fulfill and tries to pull-in research. After rational vetting of the idea (to ensure suitablility), the research organization responds by providing resources. Likewise, when research has a good idea to push, the other organizations entertain the idea in a logical fashion and pull it in if it makes sense. Sure sounds easy.
Culture Shock
I believe that all this only works when there is a corporate culture that demands cooperation. Organizations tend not to work together unless 1) it is blatently obvious to be in both their best interests, or 2) they are required to.
One of the very strange things I had to adjust to when I started at my previous place of employment was how they managed corporate culture. That company could modify the culture in a matter of weeks, and it usually worked. Here's how they did it.
They start with a good idea like "we need to drastically improve our product quality." (I'm picking one of many real examples). They prove that the idea is good by producing the research that shows it's a good idea. In this case, metrics that show our product quality was costing us customers and money. Then they develop a solution to the problem (e.g., Six Sigma). They pilot the solution to see if it works. If it does, they develop a rollout plan. Finally, the CEO gives an edict that the company values X and will do Y to improve it. They give it a catchy name, they promote the heck out of it, they provide training, they measure performance, and they reward compliance.
(I included this for the naysayers who would say that it's almost impossible to change corporate culture. It ain't and there's proof. But in the model I described, it takes corporate awareness and will.)
Summary
I mentioned up front that it's unclear to me just how valuable corporate research organizations really are. I suspect the bean counters were asking the same questions a few years ago when more companies were flush with money. Cisco made popular the idea of buying your research in the form of acquisitions. Just about everyone else tried it with varying success. What's harder, getting your own organizations to work together or getting your organizations and acquisitions to work well together? I don't know if this approach was financially better or not.
There's so many other things that could be said about the challenges of successful corporate research. My perspective is limited to just a few companies. I'd like to hear what others think.
This may be a little off topic, but I'd like to know if Sean or anyone else can provide some tips on how to land a research position - coming from a Software Delopment backgound. It seems to be an entirely different market than that of more typical IT jobs. I'm used to going to Dice, ComputerJobs, Monster, etc. for job postings. I never see research positions posted...Where should I look? Also, how have you found the salaries to compare with those of more typical IT/Software Development positions.
Previous Topic
