When the "R" goes missing from R&D (2021)
madned.substack.com
madned.substack.com
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.
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)
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.
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.
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."
Someone two, three levels above us in the org chart.
imo, this all comes down to the fact that management is still not able to assess the quality (or even the real nature) of developers work. Of course there are managers who are developers but they themselves speak a very different language with the people above them so it’s really easy for them to convince upper management that they (and their team) are doing the good thing.
I’m not blaming anyone here, we are just workers that are a little less abused than the others. But as a developer who is not really fond of tinkering things (at work), I’ve seen things. This industry never stopped to promote developers based on their LoC count regardless of the business efficiency.
In fact I’ve seen people become millionaires because they wrote extremely generic frameworks (akin to netcore, angular or bootstrap but "invented here") which then became the company’s SPOF once they left. Good for them, but I’m still amazed that upper management never realizes when they are paying someone during 4 or 5 full time years because he didn’t like Bootstrap (won’t blame him) and convinced his hierarchy that we needed to develop our own competitor.
Oh and don’t read any jealousy in my comment, the only bitterness I have is against myself, because at the end of the day, if management doesn’t care about the real output, they deserve to be served a $500k brand new css framework.
I come across lots of situations, with legitimately bright developers, who have replaced a standard subsystem either a home-grown one, usually for performance reasons.
In that moment in time, in that context, the general solution was less performant or had an ugly bug, or whatever, so they replaced it with something designed for the one specific context.
But then the context changed, and now heres this bastard-child that's been narrowly designed, and optimised for performance (so hard to maintain or change. ). And the developer is somwhere else.
But equally I've spent a career writing the "new standard solution", which of course started out as an alternative to "the standard solution". And in our context that -has- made a huge difference. So it eould by hypocritical if me to say "stay inside the box".
If you do need to get outside the box, I would give some advice though.
A) documentation. Nobody likes doing this, but this is the most important part. If it's not documented properly, it doesn't exist. And just the act of documentation will show you where the design is deficient.
B) write your code as clean as you can. Make it easy to follow. Make it easy to read. Try not yo be clever and where you are clever don't skimp on the comments. You'll thank yourself for this later.
C) as much as possible try and build for the general case, not the one in front of you. The more useful this vote is the more it'll be used. The more it's used, the easier it is to identify flaws.
In summary - stay on the main road. But if you do need to forge your own path, make sure it's done properly, not some single lane gravel dirt thing.
However, that’s just my personal experience, it’s possible that I’ve only seen the wrong kind of companies.
Sometimes the person really is brilliant and you should do anything to keep them. But if it's because they're the only one who understands their code, then they are a liability.
Or is the hero deliberately sabotaging such efforts to maintain scarcity, and thus their higher value?
If you a middle manager that's really, really good at upmanagement, they can make things a little better.
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.
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!
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.
Also accumulated know-how can be partially visible by writing out docs, patents, guides and the like. Definitely not enough but can increase visibility.
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.
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.
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.
How is paper not accessible? Do people not have note paper? What about junk mail? The last few pages of a book? You can make a scale ruler with any uniform markings.
Pieces of paper are also likely to shift if you need to move things around frequently.
In a small apartment, surface space could be limited.
It's one thing to draw a rough sketch of a part, and have someone else do the creative effort of turning it into an object. But quite another to specify in exacting detail how that part should be, so that given to several manufactories you would get back parts that are even remotely interchangeable. In that way it's a lot like the difference between a specification for a computer program, and the actual program.
When designing parts I often use pencil and paper when in an initial meeting with stakeholders, to quickly demonstrate ideas. But these sketches are not analogous to the real thing. They simply represent a direction work could be done
My computer goes with me everywhere and is ready as soon as I open the lid. Unless I forgot to charge it.
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.
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 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 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!
1. Personal Growth is limited, or further upward movement is undesirable.
2. They intend to be with the organization a finite remaining time, or would welcome an early exit
A proper strike can be differentiated from a lazy workforce, self-sabotaging work cannot be.
Typically, work to rule is used to highlight specific bad rules, regulations, or enforcement practices at a company.
Say a company expects employees to do non-rule “glue” work to keep the company functioning. But, randomly and capriciously the company punishes workers for doing this “non-rule” work. A union can then announce that they will only be sticking to the letter of the rules until either the rules are changed, or the arbitrary and capricious enforcement of the rule is changed.
So I switched my focus to completing tickets. A few weeks later I overheard my manager complaining about a breaking change made by another team that I had previously been coordinating with: "Why is this happening so much? We didn't used to get surprised by these sorts of problems."
Being a great team player can't be quantified, and gets dropped.
Work-to-rule doesn’t really accomplish that.
Work-to-rule is most effective when you’re trying to highlight particularly bad individual rules, or arbitrary punishments, etc. The work to rule action serves to clearly highlight to management why the current status quo rules are broken. This is, naturally, the most effective when there are very specific problems that lead to pretty direct consequences.
Work-to-rule would be much less effective when used for the kinds of things a strike might be used (increased pay, improved benefits, etc).
Basically, they’re just different tactics that highlight different things, and are each best used to achieve different kinds of goals.
- Homer Simpson
This is an unfortunate issue with most of modern society. It's often compared to communism, yet how many capitalist bosses really want you to do much other than implement their "vision?"
> When I give food to the poor, they call me a saint. When I ask why they are poor, they call me a communist. - Hélder Câmara
Most of them? Or, more accurately to my knowledge, most of the ones I've had. I mean, hell, even when I delivered pizza, they didn't really get all bent out of shape when I tried to do things differently as long as it was something vaguely towards the goal they wanted.
In my experience, unless someone is really hardwired for micro-management, people cool of and let you do things your way once you have a couple months at the place and have demonstrated some competence (this includes in some very traditionally corporate environments).
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.
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 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!
I don't know how things must be going wrong that you decide to sabotage / avoid collaboration like that
Entirely a problem of deep nested trees in corporate hierarchies that is so easily alleviated with better incentive structures.
Oh, also, when will we get version control support? It's 2023 an no chip design SW has this.
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.
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.
But everyone needs some of both - the most purely technical engineer still needs the personal judgment to hit dates that matter, show up when others need them, and avoid overinvesting in purely play activities.
In this case, better managers would help but honestly any experienced engineer would know that constant customer complaints mean that something is going to change.
Sometimes that's true. Sometimes it isn't, and the bad UX is the seed that leads to a terrible destructive management overreaction.
Should an engineer be able to tell the difference? In some companies, I think that's a reasonable expectation, but in other companies, engineers are cordoned off and told what to do.
I'm reading the same article that others are, so I don't know. But I do see a lot of engineers get surprised in a way that could be prevented by just a bit of proactive thinking.
> 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.