Pondering about the relation between worker agency/ownership and the susceptibility of the tech industry to hype cycles
Hypothesis: the fact that tech workers have little genuine agency over the work they do and how they do it (the boss decides in the end, not them) leads to bad technical choices sticking around institutionally because the inertia is hard to overcome if you don't have power over the direction, and those bad technical choices are introduced in the first place through hype cycles because "banding together around an exciting new tool" is the closest thing that anyone has to community organizing.
(This is an unrefined thought)
@freakazoid I sort of treat those as agency issues, personally, because they tend to indirectly result *from* a lack of agency.
In a healthy organization, the amount of power that someone has over something, corresponds with the amount of responsibility they have over it. That's ultimately what agency is about in a project context, IMO.
But in the examples you mention, there is an (implicit) responsibility of keeping the thing running, because you will definitely be blamed if it fails, but no corresponding power to actually do so in the best way (eg. refactoring the code). Instead the priorities are set by someone else, who ultimately isn't the responsible party despite what the org chart says.
Likewise, peer feedback needs a healthy balance of power and responsibility; in this case it sounds like the power was functionally with senior folks, but the responsibility was passed off to others (by eg. punishing them in peer review).
I think something similar applies to a lot of workplace issues, where they derive - directly or indirectly, sometimes across multiple steps - from what is fundamentally a problem of agency.
@joepie91 That makes sense. And I've almost always seen organizations react to the problems that arise from this by further centralizing power and reducing people's agency. It's a downward spiral that eventually either destroys the organization or turns it into a bureaucracy, i.e. an organization which tries to make everyone interchangeable.
Which I guess is what Google was *trying* to become at the end of the day. Only they seemed to think they could do it better than others and have people still do decent work. I think it's pretty obvious at this point that they were wrong.
@joepie91 I think as well novelty/progress tends to be valorized and like maintenance work is deprioritised especially by managers but also by technical folks
@teo Right, but the question I am trying to answer with this hypothesis is *why* that is, especially on the "by technical folks" side. Because that's a cultural thing, and that comes from somewhere!
@joepie91 yeah that's fair! I think the reason you give is definitely part of it. I think another big part is whether these things are masculine/feminine coded, which is what I had in mind with like novelty vs maintenance
@teo Hmm, I haven't quite observed that pattern before, but it's very possible that I missed it. Could you give some examples of what you mean?
@joepie91 sure! I'm thinking of things that are seen as "household chores" like general maintenance, dealing with tech debt, and like glue work things. Also things that are seen as communicative/secretarial work like writing docs. I feel like this categorisation is quite fuzzy (often gender norms are contradictory) and are counteracted by the fact that these things are in fact quite important. But in general I feel like folks internalise the idea that computing is like "men's work" so these things are seen as less important or for someone else to do. I feel like you get this type of stuff quite often with heavily gendered professions like how folks think of nurses vs doctors in very different ways.
@joepie91 Not just lack of agency, but lack of recognition for doing good work. Often quite the opposite, in fact; I've certainly been penalized for taking extra time to refactor code instead of just adding more copypasta.
Peer feedback could overcome that to an extent, but in my experience people at most companies don't have the time to pay much attention to what their coworkers are doing, or which coworker did what. I imagine that this has become the case even at Google and Facebook, which were the main places I noticed any decent use of peer feedback.
On the other hand, even when I was at Google the main use I saw of peer feedback was actually to punish people for not following the outdated practices senior people told them to follow. Had someone on my team miss out on a promotion because he chose to use Go instead of C++ for a project, despite the fact that Google was pushing really hard for people to use Go.