R&D-Ship Your Research
I’ve had a number of jobs over the years where R&D was in my portfolio as support staff, a participant and a manager and I’ve worked, as an I.T. tech, in pure research facilities. I’ve learned something. Ship your research.
I worked as the hands-on I.T. guy for a now defunct medical devices company. The job was great. I was there while they grew from about thirty people to close to two hundred over the course of about two years. Until late in my tenure there, all the R&D was done in specific support of their flagship product. Whether it was on the accounting ledger as R&D I couldn’t tell you but thousands of staff hours were spent on researching everything from materials science, manufacturing practices and, of course the formal clinical trials of their products. Virtually every dollar spent on this R&D was driven by a product goal. Everything tested and experimented with during my first year there was being tested for use in the product line they actually intended to ship. Nobody was on the clock saying “I wonder if.”. If somebody had an idea, If it wasn’t vetted as having a potential commercial future, it didn’t get done. There was no ‘pure R&D’. That didn’t mean some ideas didn’t get very far along before they died. I remember every man and woman in the company being brought into a room to feel plastic breasts. We went in, we were asked “does this feel real”. A few weeks later we were asked “Can you find a lump?”. The goal was a training simulator for breast examination. As I recall, and I could be wrong, the conclusion they came to was that the stimulants of breast tissue, skin and lumps couldn’t be made meaningfully enough realistic to make it safe to teach to ignore what to feel as case to for concern and what to feel as normal variation. The project was summarily killed and the staff back on in process projects without any kind of merciful pause or mourning period. It was a dead end quickly.
I worked for another company that was ultimately sold to a very large company you’ve surely heard of. I got supremely lucky in my brief tenure there. I arrived at the worst possible time to actually achieve any of what I hoped to when first took the job but the President and CEO were extremely honorable and generous with me despite the chaos that began a week after I arrived. Frankly, I seriously lucked out. It was immediately scary within mere days of my hire but that panic ultimately evolved into the sale to ‘unnamed huge company’ and most of the engineering team went on to jobs there and do major work, on the other side of the country. That company, the one sold, began life as a firm doing very academic R&D funded in large part by SBIR grants doing work for NASA. Things even now not yet, as far as I know, deployed by NASA. The things they built, the prototypes done as R&D were shockingly cool things. Things I still, more than a decade later, haven’t seen make it into mainstream products. The brilliance in what they built is impossible to articulate. These people, from the founder on down were shockingly smart. They built controllers for telepresence and simulations that included touch feedback. Now, we’ve all felt a gun in a console game that jumps in your hand when fired. A steering wheel that rumbles when the virtual car runs over a bumpy patch on the pixel track. Imagine touch feedback so nuanced, so elegantly implemented that you could feel the shape of a virtual space you couldn’t see while walking through it with a joystick. Imagine feedback so nuanced you could draw the shape of a virtual maze based only on what you felt from the joystick. Imagine touch feedback so good that if you used it on a steering wheel in a game, it made you able to drive the car closer to its limits and complete laps faster. The steering of my real car is ‘drive by wire’ more than fifteen years later and it gives me less useful feedback than those prototypes. The R&D that built the prototypes was R&D with a purpose but it wasn’t R&D that was ever intended to end up in anything like the test form in a final product. They weren’t rough drafts, they were proofs of concept to learn from. None of that work was ultimately visible as more than a faint glimmer in the final shipping products. No fault on anyone there, the costs involved and target market of the final products not only precluded it but actually might have made the product inferior.
Before both and after both of these jobs, I’ve been employed as and a consultant to pure academic research facilities mostly in biotech. Academic research is, and should be, a completely different ball game. It’s not technology R&D, it’s science. There are critical differences there. The purpose of science is discovery. Pure, simple, discovery. Sure, maybe it will lead to a new medication, a new procedure or a business opportunity but that isn’t, and can’t be, the purpose. The purpose is “Let’s build a test to see how this works”. You don’t, for example, send the Voyager space probes to invent a product. You do it because we, as a species, need to learn. Of course, there will usually be technology innovations created in support of the research that could lead to business opportunity but the purpose of the work is pure learning. Cancer research may lead to cancer cures. Pure academic metabolic research might also. You have to invest in basic research on cellular metabolism whether or not you’re studying cancer. The current climate of public derision in the press for research that seems to have no probable useful purpose is bad for society. Research, pure research done with scientific rigor is vital for its own sake. Science is enormously important. Our society is investing less and less in true science and that’s deeply disturbing. It is important to remember though that R&D is not science even if we seek to apply scientific rigor.
Finally, I’ve worked on  a lot of new media jobs. All these experiences above taught me this. When you’re doing R&D in a commercial tech company? Ship your research. I don’t mean literally take an idea all the way to a product you sell. I mean treat it like everything will be or will be used for shipping products.
If you want to explore a technical idea, an innovation, invest in it when you think can actually use it. Don’t expend your core resources just fiddling around. Find a business goal you think your idea can support and find a way to make the project fund the research or the research fund another business goal. So, for example, let’s say you want to experiment with a new CMS, find a project that needs the functionality you want to explore. Do structured tests to see if what you want to be true stands a decent chance of being true. Set break points to check your thinking and set about actually doing work with the experimental notion with the idea you plan to ship it. Don’t fund the research out of R&D, fund it out of an actual project. Do the research with the same level of rigor you’d bring to production methods you already know and use. You will, I hope, fail miserably regularly. Failure is the cornerstone of innovation. You have to be prepared to throw an idea away that’s clearly not going to work.
The thing is though, if you don’t treat your R&D with the same level of rigor you would if it was sure to actually ship, you’ll learn nothing. You’ll never stress test the idea. If it’s a new software tool, you’ll never test the vendors support services. If it’s a new version of a tool you already use, you’ll never put it through the mundane day to day processes you’ll have to when you’re actually doing production work.
The worst mistakes, the most disastrous  dead ends, the most massive cost over-runs and delays were almost always something you could trace back to a decision that went like this: “We’ve spent a few weeks looking at this tool and reading up and we want to invest in this tool.” Investment in a tool is sometimes just training and time. Sometimes it’s millions on expensive hardware. All of these messes arose from somebody thinking the technology itself could do magic. People do magic, technology doesn’t. Only applying the same level of self criticism and doubt to your ‘experiments’ as your customers will to your products can you make efficient use of your research.
A concrete example should make this clear:  If you make television shows and you want to try a new editing system (NLE), deploy one and use it. Now, testing a new new NLE may not seem like R&D but it is. It’s what needs to be done to stay at the cutting edge in the video production business. First, use it to produce an internal project. A real project with stakeholders and somebody other than you setting expectations for turnaround time and quality; an internal presentation reel for example. Remember though, don’t cut something that nobody cares about. Cut something that somebody outside the testing group cares about. Something underfunded but low stakes. Use the R&D budget to make a skilled editor available to this project. Use the R&D budget to rent this much desired new system for the important internal project that couldn’t otherwise afford it. Pick something gnarly. Something with footage from disparate sources. Something that relies on your motion graphics group to make assets for. Pick something with a picky stakeholder who will make you make a pile of annoying last minute changes. In the middle of the project? Break the NLE. No, I don’t mean spill coffee into it, but I do mean break it. Install something you shouldn’t. Disconnect the media drive in the middle of a render. Delete some obscure application file and call for support. See how it will be when there’s an air date on the line. If your internal project survives all this. If your experienced editor comfortably adapts to the tool. If they like the tool. You’ve given your senior staff a chance to play with a new tool. They get professional and personal development. Your ‘no paying client’ internal project that was important enough to fund got done with the money set aside for R&D. Your test of the new tool stress tested it.
Next step. Use the new NLE on an actual project. Not one for a client but one that’s complete. One you’ve already shipped that you’re proud of. Assign a junior editor and producer to re-make something that’s already been done from the carefully archived materials for a finished project. Then you’ll test your NLE with a real volume of footage. The previous finished product is the benchmark for the re-make. Everything from lower thirds, to effects to closed captioning gets put through the workflow with the new NLE.
If the new NLE lives through this test, you’ve really stress tested it. You’ve reduced your business risk in deciding to deploy it on paying projects and you’ve done these tests with enough different people involved you can make your choices based on feedback from the people, your people, that will need to rely on the tool. You didn’t just read an article and say “it’s the latest thing we have to use it”.
You’ll have tested your archiving compliance. You’ll have given your senior staff a chance to participate in a strategic choice. You’ll have given your junior staff to learn new things and get their hands on playing with a flagship project.. They’ll learn from how their more experienced colleagues work. You’ll have a low risk letting these junior staff try things and see how they perform.
You’ll get to see how the NLE that survived the stresses of making a five minute internal demo reel. If the new NLE survives that test? Then you deploy in a relatively low stakes project in production. It’s R&D research and development. You researched the viability of the tool and you developed the internal resources to deploy it. Even if it turns out to be badly supported overpriced junk you’d never buy in any volume, you’ve spent your R&D money well.
R&D in I.T. and New Media Production is about testing new tools, new workflows, new ways of capturing, organizing and presenting information. Your time and money should be spent moving to scenarios where you’re actually testing the ideas in real-world scenarios while managing risk. Maybe it’s a new visual metaphor. Prototype it and get it in front of real users not your staff and do it in a structured and objective way. Go in hoping it will crash and burn as much as you’re hoping it will be a breakthrough. If you’re not, very quickly, imposing discipline on your process you’re wasting money and putting your business at risk.
