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

The point of a strike is often to make a big statement, say “fire me if you dare,” and show that your unit has cohesion and resources. You want something dramatic and noticeable. For example, if you want to kick contract negotiation out of stagnation, you want to do something that the business can’t ignore for a couple months.

Work-to-rule doesn’t really accomplish that.

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.

There’s a balance I’m still fighting to find.

I think they’re typically targeting different changes and different outcomes in an organization.

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.

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

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.