Skunk Works

Forgive me for indulging in a bit of armchair management. I want to talk about organising an R&D team, something I have no experience with, but plenty of opinions, and it is the internet, so listen up!

If you don't know, the Skunk Works was (is) a small 'research group' inside Lockheed Martin formed around 1943. They invented and built some of the most incredible aircraft to ever fly, including the SR-71 Blackbird, U-2 spyplane, and F-117 (the first 'stealth' aircraft). If you're interested, the book by Ben Rich is a great read (although a bit over-the-top macho, which is not surprising given the time period and the products).

The Skunk Works did some awesome stuff and they are unsurprisingly idolised by a lot of tech folk. In fact, it's become almost a cliché to compare any group that is doing even vaguely novel engineering to the Skunk Works. It kind of makes sense to want to emulate them and their work, so sometimes organisations try to copy the structure. However, I think there is a misunderstanding about how the Skunk Works actually worked, what they did, and the lessons that can carry over to software engineering under modern management practices.

An exaggerated version of how people think the Skunk Works worked.

"We need to do some R&D!" realises the CTO. They've read the Ben Rich book or were into planes as a kid, so they know how cool the Skunk Works was (or they just think this is how R&D has to work). They create a new team, hire brand new people (the smartest they can find). The new team doesn't have to work on existing product or talk to customers or all that boring stuff, they work on high risk, high reward technology that could make the org's products 10x better. They get their own offices and license to do their own thing without too much management oversight. And they get t-shirts and stickers so everyone knows how smart and special they are.

A year later, they've done some cool things and the CTO gets to go up on stage and tell the rest of the company how smart and special this new team of ninjas are, and how their work is 10x better than the existing product and now we just need to integrate it and everything will be golden.

Why this goes bad

It's optimising all the wrong bits. Doing the research is actually pretty easy, it is integrating it with real life which is difficult. By taking real life constraints away, of course you can come up with new awesome and technology, but it is the 'tech transfer' from research project to product which needs work.

Furthermore (and most importantly) this model is terrible for the team 'jel' of the organisation as a whole. By treating a small group like elites, the morale of a small group has been improved at the expense of the morale of the rest of the organisation. Working on new, exciting tech is fun and I bet 90% of engineers would rather do that than slog away on thankless bugs in existing products. Instead, that privilege has been given to a bunch of new engineers without product-specific experience, and the long-time engineers get more thankless work integrating the new tech (which is probably missing important conventions, constraints, etc.) which takes a surprising (to management) amount of time, is not that exciting, and usually doesn't get much credit because there are fewer exciting graphs.

How to do it better

Give 'regular' engineers space to do greenfield research. They're smart people and have experience and I promise they've been thinking about how to do things 'properly' if they could start from scratch. Either let them take a 'sabatical' to work on new, exciting tech, or give them 20% time, or just makes sure they are not so snowed under with bug and feature work that they have some time to experiment.

Don't isolate the research group from the product group. Sometimes greenfield research requires skills that are not present in the main org. That's a fine reason to hire new people. Not having upper management breathing down their necks is certainly a good thing (as it is for everyone else in the org, to be honest). But they should work closely with product - to make sure they are aware of technical constraints, and to benefit from experience with previous experiments. This also gets the teams working together, rather than have the R&D folk be outsiders.

Emphasise and invest in tech transfer. Make sure engineers get credit for the hard work of turning prototypes into products and for integrating research into existing products. Make the excited announcements when a product is improved, not when a prototype shows improvement. Make sure the R&D group are involved in integration and don't just through stuff over a wall to engineering.

How the Skunk Works actually worked

The Skunk Works was not really an R&D group in the sense of most software companies. The Skunk Works built planes, not just prototyped them. They were essentially their own product unit, a company within a company. The planes which the Skunk Works developed were never built by the rest of Lockheed Martin (at least not during the 'golden age'). Technology only indirectly filtered out of the group - there was no tech transfer goal.

That's a fine model for a kind of R&D, but I'm not sure it crosses over to software tech. In the best case, an R&D group should be force multiplier for product engineering, not a dead end (albeit a useful and profitable one) for smart people and good ideas.

(Note that this whole post is talking about R&D as opposed to foundational research. Some organisations have groups doing foundational research (which is more often found in academia). In that case, the structure is completely different).