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...
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.
Everyone else is gradually PTSD'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's main banner.
All companies start small. Only the absolute best survive, so there is tremendous survivorship bias for the remaining companies to comprise of fabulous people.
Naturally, when the company starts growing, it is insanely hard to be able to keep on recruiting only such fabulous people. If nothing else, it would slow the growth, snd as such is usually not prioritized.
That’s when the regression to the mean starts. Then, you start needing more process and more bureaucracy so that the middling people have any chance of keeping up.
Unfortunately, there is no deus ex machina at the end of this path, like in TFA.
I do wonder if there is a U shape here - ie at some point the company get's so large that the central control breaks down and innovation starts to happen in the cracks.
My experience of very large companies is there is an official way stuff get's done, which is different from how stuff actually get's done - which is through peer networks.
it's like... we go like gangbusters in our lives doing the things that positively need to be done.
Then when we get a moment to breathe... we do the things we want to do more than the things we need to do.
Things work better with a slight sense of urgency, but less than full-on burnout (although fighting along up to burnout is probably pretty ruthlessly efficient)
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's sometimes frighteningly easy to convince business leaders that the dev teams are wasting a ton of time, doing the wrong thing, etc. It's even easier when that direction is coming from a consultant (might not be in this case, but I've seen it happen a few times).
Someone who was supposed to be advocating for their team (maybe the author's boss) wasn'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 "development should be faster."
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.
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.
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!
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.
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't know how to do before. I'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.
The most fun I'd say I'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/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.
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.
It's interesting thinking about this. In my career, I would not think nearly anything I've done resembles research. Just pumping out development tasks.
The one thing I can think of that was like research was really enjoyable.
I should think about how to get more of this in my career. Even making personal projects isn't exactly "research".
I was on a moonshot team in a previous role. Research is a lot of fun to get paid for certainly doesn’t necessarily imply academic (being a DS lends to a bit more of this than typical SWE). In my experience it’s big open problems that no one really expects you to solve, and rarely would there be any top down direction on how to do so. And those problems aren’t always e.g. mathematical. It could be figuring out how a new product could enter a market, quantifying demand for some product, testing out a new algorithm, or doing a greenfield rebuild of something that exists but could only be meaningfully improved by starting over.
I think what is satisfying about this is the fact that your day to day is largely self directed and open ended. It’s not the type of thing that lends itself to backlogs and well defined tickets, and typical productivity methodologies like whole/scrum tend to fall flat in teams like this for this reason. You just sort of dive deep on a problem, put together prototypes, figure out how to quantify their utility, and keep trying new things. There also tends to be less pressure on deadlines because of the lack of top down.
In your average job instead of “research” it’s really “discovery”. which is trying to decipher what some business guy at your company or a customer really wants
I've seen a surprisingly low rate of research conducted 'R&D' 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&D technologists employed tend to act as rapid response personnel for tasks not predicted by project managers or systems engineers.
"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."
In labor market conflict situations it is called an Italian strike?
Do work exactly as specified, not including all the little things needed to actually make work happen. All the glue work needed to make an organization function just doesn't sometimes!
Also Soviet civil disobedience. You can’t break the rules or you’ll get punished but you can do things literally and not get punished. You’re not paid to think after all
Many managers will be happy to have people who are showing to work and just do their job. Isn't it the reason why people are hired? To do their job.
Of course everyone wants to get more for free, that is why do many complaints that people are lazy and don't do any extra work which can benefit their employer.
i enjoyed the read and was quite surprised that there was a happy ending. i didn't think that would be possible. probably that speaks to my own personal experience more than anything.
not really relevant, but anyone know where mad ned is at these days? haven't seen any new posts of his in a while, and i enjoyed a bunch of them.
I'm still alive. But I've retired or at least taken an extended hiatus from my writing hobby, which in retrospect was probably a pandemic coping mechanism more than a lot of things lol.
I only came here because my in box is blowing up due to the traffic hacker news is driving to my site, and so then I see that this article is like #3 today. Not bad considering I don't really remember writing it!
The classic management-empire-driven-development where each management rung up to the lowest common ancestor wants credit for their own teams "moving the needle". They don't want to collaborate too much with other branches and in fact, want to dominate other branches.
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.
research without experimentation anyone can do. "What if we had lasers strapped to the heads of sharks? what if dolphins could do the work if we gave them waterproof paper?". It almost seems trite to call that research. Of course, you can use previously existing statistics to come to these ideas in a way that feels like work. But its still deeply unhelpful
Chip design software GUIs are known to be unintuitive and unfriendly. I'm using them daily and it's in the way all the time. So I don't know what changed after these but I'm not seeing it as a user.
Oh, also, when will we get version control support? It's 2023 an no chip design SW has this.
I am scratching my head as to why Cadence Virtuoso is de-facto standard in custom analog design. Barely anyone uses Synopsys Custom Compiler. Having worked at SNPS I prefer schematic entry features of CC. Probing is more efficient, adding stubs to instances as well, lot of QoL stuff like these dynamic alignment guides, and finally most tool options are not hidden under F3 (as in Virtuoso) and show on the toolbar instead. Now I work at a small company which uses Virtuoso and have to re-learn a lot of stuff even if keybinds are 95% the same. I don't know how ADE compares to PrimeWave (formerly SAE), as we at Synopsys did not dogfood it and used custom text-based DSLs for all simulations instead.
This team did it to themselves. “R” has little to do with it.
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.
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.
It seems that the appropriate design skillset was lacking in the R&D group. Also maybe it was a first attempt to make something, and they did not get through a second iteration to improve it.
Why do we expect that skilled SEs are also skilled UX designers? As everything, design requires training. The problem seemed to be such people trained in design were missing from the R&D team, which sounds like management's fault rather than the engineers' in the first place. Then, the management, while correctly identified the lack of design skills, instead of strengthening their R&D team with that missing talent, they put designers in a different group, creating a different set of issues within the company. Seems a case for an overall bad management in my eyes.
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.
Our situation at work isn't quite analogous to this, but boy oh boy did this part stand out to me:
> 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:
> “When captured by the enemy, it is best to display model prisoner behavior.”
> 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.
btbuildem|2 years ago
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.
Everyone else is gradually PTSD'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's main banner.
shandor|2 years ago
All companies start small. Only the absolute best survive, so there is tremendous survivorship bias for the remaining companies to comprise of fabulous people.
Naturally, when the company starts growing, it is insanely hard to be able to keep on recruiting only such fabulous people. If nothing else, it would slow the growth, snd as such is usually not prioritized.
That’s when the regression to the mean starts. Then, you start needing more process and more bureaucracy so that the middling people have any chance of keeping up.
Unfortunately, there is no deus ex machina at the end of this path, like in TFA.
DrScientist|2 years ago
My experience of very large companies is there is an official way stuff get's done, which is different from how stuff actually get's done - which is through peer networks.
m463|2 years ago
it's like... we go like gangbusters in our lives doing the things that positively need to be done.
Then when we get a moment to breathe... we do the things we want to do more than the things we need to do.
Things work better with a slight sense of urgency, but less than full-on burnout (although fighting along up to burnout is probably pretty ruthlessly efficient)
unknown|2 years ago
[deleted]
debacle|2 years ago
Someone who was supposed to be advocating for their team (maybe the author's boss) wasn'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 "development should be faster."
hinkley|2 years ago
Someone two, three levels above us in the org chart.
rm445|2 years ago
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|2 years ago
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|2 years ago
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!
DrScientist|2 years ago
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.
karmakaze|2 years ago
The most fun I'd say I'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/rotate my to-scale bedroom furniture outlines around to see what layouts were possible and may be good to actually move the furniture.
jfim|2 years ago
mildchalupa|2 years ago
daveguy|2 years ago
Waterluvian|2 years ago
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.
There’s a balance I’m still fighting to find.
zck|2 years ago
The one thing I can think of that was like research was really enjoyable.
I should think about how to get more of this in my career. Even making personal projects isn't exactly "research".
appplication|2 years ago
I think what is satisfying about this is the fact that your day to day is largely self directed and open ended. It’s not the type of thing that lends itself to backlogs and well defined tickets, and typical productivity methodologies like whole/scrum tend to fall flat in teams like this for this reason. You just sort of dive deep on a problem, put together prototypes, figure out how to quantify their utility, and keep trying new things. There also tends to be less pressure on deadlines because of the lack of top down.
coffeebeqn|2 years ago
Prcmaker|2 years ago
jruohonen|2 years ago
In labor market conflict situations it is called an Italian strike?
datadrivenangel|2 years ago
Do work exactly as specified, not including all the little things needed to actually make work happen. All the glue work needed to make an organization function just doesn't sometimes!
coffeebeqn|2 years ago
vasco|2 years ago
ponector|2 years ago
Of course everyone wants to get more for free, that is why do many complaints that people are lazy and don't do any extra work which can benefit their employer.
avg_dev|2 years ago
not really relevant, but anyone know where mad ned is at these days? haven't seen any new posts of his in a while, and i enjoyed a bunch of them.
mad_ned|2 years ago
I only came here because my in box is blowing up due to the traffic hacker news is driving to my site, and so then I see that this article is like #3 today. Not bad considering I don't really remember writing it!
tester756|2 years ago
I don't know how things must be going wrong that you decide to sabotage / avoid collaboration like that
nine_zeros|2 years ago
Entirely a problem of deep nested trees in corporate hierarchies that is so easily alleviated with better incentive structures.
oaiey|2 years ago
bdcravens|2 years ago
RugnirViking|2 years ago
ablob|2 years ago
bgnn|2 years ago
Oh, also, when will we get version control support? It's 2023 an no chip design SW has this.
RicoElectrico|2 years ago
shermantanktop|2 years ago
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.
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.
dimask|2 years ago
Why do we expect that skilled SEs are also skilled UX designers? As everything, design requires training. The problem seemed to be such people trained in design were missing from the R&D team, which sounds like management's fault rather than the engineers' in the first place. Then, the management, while correctly identified the lack of design skills, instead of strengthening their R&D team with that missing talent, they put designers in a different group, creating a different set of issues within the company. Seems a case for an overall bad management in my eyes.
jdeaton|2 years ago
goalieca|2 years ago
devaiops9001|2 years ago
1vuio0pswjnm7|2 years ago
unknown|2 years ago
[deleted]
pavel_lishin|2 years ago
> 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:
> “When captured by the enemy, it is best to display model prisoner behavior.”
> 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.
unknown|2 years ago
[deleted]
lowbloodsugar|2 years ago
dimask|2 years ago