[rm445]

Nothing in this article pertains to actual research - development has always included elements of design. Interesting article otherwise though.

I've been in an organisation that was actively winding down the research side of R&D. Lots of chemists and physicists let go, or at least not replaced. Projects that had gone nowhere for years canned; people with no output for years canned. More focus on product roadmaps. What's really weird is that every step seemed pretty reasonable, but the overall capability was much less in the end. It's really tricky.

[hinkley]

The opposite hasn't really worked out in Detroit, and I don't think it worked particularly well for Boeing either, but I still think organizing R&D under one human is a huge part of the problem. Too much 'efficiency' in research and effectiveness drops to zero. Lack of urgency or excessive urgency (read: burnout) will lead to team after team running out of fucks to give, and one day someone will look up and see nothing has been accomplished with the last several millions of dollars.

I believe having different people running 'competing' groups that report to the board instead of a tall narrow org chart with clear choke points may not fix the problem entirely, but it would slow down the cycle. Worst case you disband one of the orgs and create a new group to replace it, run by someone from one of the more efficient divisions, or new blood from outside.

[ok_dad]

> people with no output for years canned

Often I see this happen, and the result is the company loses out somehow. I think maybe metrics for “output” are wrong in many cases, and you’ve just canned someone who had a useful or even critical role you didn’t know about. A lot of people who are important to company operations are invisible!

[bgnn]

output doesn't capture accumulated know-how. If you fire researchers you loose know-how, hence you loose potential.

[a_bonobo]

Output also doesn't capture 'enabling' functions: as a researcher I love to help others get to their goals, I love working on tricky problems and using my know-how to feel needed. I think I'm not alone in that.

Unfortunately that means that on paper, I have zero output while the people I help have all the output. Especially in computing/data science it's easy to fall into this trap; it takes a daily check-in to make sure that I'm working on the stuff that counts for me and my group.

[mjcohen]

You need to document everything you do.

[pdimitar]

lose*. It's not so hard, man.

Also accumulated know-how can be partially visible by writing out docs, patents, guides and the like. Definitely not enough but can increase visibility.

[bgnn]

yeah lose. I don't know why I keep typing this wrong..

[DrScientist]

One of the challenges is that there are always more smart people outside the org than in - so the chances of the same company out innovating the world again and again is slim.

On the other hand, if your management decide to cut R, and just buy in the innovation at the right time to develop it - if you don't have any internal R people trying to do the same sort of things you will find it really difficult to make the right acquisitions at the right time.

So you need both - and treading that line is really tricky.

I also think that having people with an R mindset is important - people who are interested in pushing the envelop, doing things better etc.

Having people like that in the organisation means you are less likely to be blindsided by a shift in technology that could kill the company.