When the "R" goes missing from R&D (2021)

Tangential, but it seems to me that as organizations grow, more and more resources are poured into everything other than what made them successful in the first place. Bureaucracy grows, hierarchies increase, teams upon teams organize, things are envisioned and realized and KPId, volumes of messages and emails shift back and forth, endless hours are met in meetings...<p>At the same time, productivity is reduced, actual communication diminished, gatekeepers slow everything and everyone down, fiefdoms form with their territorial turf wars, naked emperors run amok fanned by yes-men. On average three people out of a hundred are doing something actually useful, while the company slowly loses its grip on whatever niche monopoly has allowed it to so grotesquely exist thus far.<p>Everyone else is gradually PTSD&#x27;d into a corpo version of Homo Sovieticus, filling out time sheets and RTO attendance records while duly marching towards V17 in the most recent two-year plan, aligned with the corporate values writ large on the HR site&#x27;s main banner.

In my experience, this was likely entirely driven by one person, my guess would be two levels above the author in the org chart. It&#x27;s sometimes frighteningly easy to convince business leaders that the dev teams are wasting a ton of time, doing the wrong thing, etc. It&#x27;s even easier when that direction is coming from a consultant (might not be in this case, but I&#x27;ve seen it happen a few times).<p>Someone who was supposed to be advocating for their team (maybe the author&#x27;s boss) wasn&#x27;t, or was being out-advocated by others, and that led to breakdowns. As a manager, I keep a lot of KPIs and do a lot of postmortems (lean), because you need to be able to counter the gut feeling of &quot;development should be faster.&quot;

Nothing in this article pertains to actual research - development has always included elements of design. Interesting article otherwise though.<p>I&#x27;ve been in an organisation that was actively winding down the research side of R&amp;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&#x27;s really weird is that every step seemed pretty reasonable, but the overall capability was much less in the end. It&#x27;s really tricky.

I know this story is about company scale RnD. It can also be applied at any level. Research lives on a gray scale. At its core is growing understanding of your area so that you can do things you didn&#x27;t know how to do before. I&#x27;ve always gravitated to the hardest problems to be solved so that I can learn something and make something that no one else had the vision or perseverance to make. So almost all my jobs have been RnD though only a few formally.<p>The most fun I&#x27;d say I&#x27;ve had was recognizing something ineffective and making (software) tools for it. Now that I think about it one of the first programs I made on my Atari 400 as a kid was Room, which let me move&#x2F;rotate my to-scale bedroom furniture outlines around to see what layouts were possible and may be good to actually move the furniture.

I have a new one. PM had determined that their work load is diminished if a project is killed. So they deliberately recommend that projects be terminated and or do things that would cause the likelihood of termination to increase.

Research is one of those things that feels like “work” for me. My least favourite part of grad school. I just want to dive in and touch stuff and prototype. I find myself often jumping to the prototype phase as a way to justify skipping research. Maybe I’ll review a few related libraries and some blogs and such.<p>It’s definitely something I’d like to work on while not losing the practicality of not being caught in research hell like some peers have in the past. Their end products ended up late and no better than my third iteration of the same thing.<p>There’s a balance I’m still fighting to find.

It&#x27;s interesting thinking about this. In my career, I would not think nearly anything I&#x27;ve done resembles research. Just pumping out development tasks.<p>The one thing I can think of that was like research was really enjoyable.<p>I should think about how to get more of this in my career. Even making personal projects isn&#x27;t exactly &quot;research&quot;.

I&#x27;ve seen a surprisingly low rate of research conducted &#x27;R&amp;D&#x27; roles through my admittedly short career. The research segment of any work had been limited to testing of ideas that are highly likely to work, the bulk of the work is product or prototype development. The R&amp;D technologists employed tend to act as rapid response personnel for tasks not predicted by project managers or systems engineers.

&quot;And that was exactly what had happened here. It wasn’t that people were deliberately trying to sabotage progress, they were showing up to work and doing their jobs as instructed. But nothing more.&quot;<p>In labor market conflict situations it is called an Italian strike?

i enjoyed the read and was quite surprised that there was a happy ending. i didn&#x27;t think that would be possible. probably that speaks to my own personal experience more than anything.<p>not really relevant, but anyone know where mad ned is at these days? haven&#x27;t seen any new posts of his in a while, and i enjoyed a bunch of them.

&gt;Various attempts of mine to convince the UX team to meet with us were rebuffed.<p>I don&#x27;t know how things must be going wrong that you decide to sabotage &#x2F; avoid collaboration like that

The classic management-empire-driven-development where each management rung up to the lowest common ancestor wants credit for their own teams &quot;moving the needle&quot;. They don&#x27;t want to collaborate too much with other branches and in fact, want to dominate other branches.<p>Entirely a problem of deep nested trees in corporate hierarchies that is so easily alleviated with better incentive structures.

I think most bigger organizations have left and right to the RD product manager, architect, program managers and UX groups. The head of that is the real head of RD. The real question is whether you want interdisciplinary teams. And the answer to that is more often than not: no. Why: because the illusion of control by management.

The missing letter in R&amp;D is E (experimentation). You have to validate assumptions and ideas and bridge the gap.

Chip design software GUIs are known to be unintuitive and unfriendly. I&#x27;m using them daily and it&#x27;s in the way all the time. So I don&#x27;t know what changed after these but I&#x27;m not seeing it as a user.<p>Oh, also, when will we get version control support? It&#x27;s 2023 an no chip design SW has this.

This team did it to themselves. “R” has little to do with it.<p>They worked on the technical bits that they liked, created a terrible UX that sounds user-hostile, and then shocked-pikachu discovered that their jobs got cut in half.<p>The decision to whisk UX duties to a team miles away was moronic, of course. But that was a reaction to the bad acts this team did - to their customers, to the business, and to themselves.

This sounds like a classic case of someone (&#x2F;whole team) mistaking their title for their role.

I think the first mistake is when companies try to diversify when they haven’t quite nailed their first product or service. Perhaps they are forced by investors because of the valuation or perhaps the founders always had a greater vision.

Kinda reminds me of <a href="https:&#x2F;&#x2F;kevingoslar.medium.com&#x2F;build-micro-organizations-not-just-micro-services-b109e377379c" rel="nofollow">https:&#x2F;&#x2F;kevingoslar.medium.com&#x2F;build-micro-organizations-not...</a>

Hope the IRS has seen this blog post.

Our situation at work isn&#x27;t quite analogous to this, but boy oh boy did this part stand out to me:<p>&gt; <i>But a larger part of it was that people in the development team were just showing up to work, and not much else. I had a friend once at Digital who gave me this unforgettable advice, right after we were bought by Compaq:</i><p>&gt; <i>“When captured by the enemy, it is best to display model prisoner behavior.”</i><p>&gt; <i>And that was exactly what had happened here. It wasn’t that people were deliberately trying to sabotage progress, they were showing up to work and doing their jobs as instructed. But nothing more.</i>

2021: When programmers still sourced images for their blog from Getty Images rather than just generating whatever they needed.