Comments
In the show, both groups of individuals are subject to their institutions: power figures come and go (and bring changes that superficially alter the state of affairs), but the game fundamentally remains the same. This repeats itself in every explored institution: industry, schools, news, &c.
In other words: there is no avoiding "corruption," only moving it around. The show's few "good" characters are characterized primarily by the ways in which their personal corruption does or does not affect the corruption of the larger institution they belong to (Daniels' FBI investigation, for example, or Kima's personal descent.)
In general, compartmentalizing a few clear limited-scope areas for each team member is an effective management task. In this manner, there is direct accountability when something goes wrong, and a user-base focuses attention on a flaw... a growing number of regression tests helps some do their job properly... rather than sidetrack the rest of the team.
This can be brutal to laggards getting hazed, but a blessing to senior staff now avoiding spending half the day reverting garbage. ;)
I've been back and forth with multiple managers and C levels that any metric chosen can and will be gamed. But they again and again want some quality assessment to use.
For a while, they used tickets closed. So we all started submitting BS tickets to do tasks like "send email". You all can imagine the inanity of that.
From my experiences there is no good way to track... Well, perhaps having a grab bag of conflicting performance metrics, and then choosing one at random? (But again, even that can be gamed)
Milton Friedman, for example, famously said that 'Corruption is government intrusion into market efficiencies in the form of regulation.'
This mentality, when applied to the food / medicine / drug trade, has some curious results. On one hand, it suggests we eliminate all criminal penalties for buying, selling and consuming all drugs, while on the other the normal criminal penalties for theft of drugs would apply. Note also that sellers could adulterate their product (no regulations, remember?) in any way they saw fit as long as it maximized their market efficiency (profit margins, basically), based on the belief that customers could shift to other producers if they didn't like the product.
The real result of criminalization of drugs, rather than regulation of drugs, is that a black market develops, characterized by violent conflicts between sellers over access to that market, control of production and supply, etc. This is why decriminalization makes a lot of sense, coupled with things like public health campaigns aimed at reducing usage, bans on advertising drugs and marketing drugs to children, etc.
I've had an unsettled feeling for some time that managers, perhaps many execs, are mostly liabilities... Far to often I have seen someone categorize _something_ as not a _something else_ to ensure it doesn't raise any suspicions of their superiors, manipulates the metrics etc. It's lead me to wonder if investment/effort is better invested to cultivate ethos more than measurement.
Ethos like "We do what's best for the customer" or "We fix errors when we see them" instead of "Did we hit the SLO?"[1] or "How many open bugs are in the system"[2]
Anyone else felt this, or am I just the burnt out, toxic, outlier?
[1]: people start to categorize things as not downtime
[2]: People start to chastise those who open JIRA bug tickets as "too many!"
This threw me for a loop.
I asked a contact on the PD of a neighboring town some years back how Naperville, IL is consistently the lowest general crime rate and "Safest Town in America", and this was the answer.
Having lived there and heard the stories about police interactions with victims, I believe it.
I read that as "we just have to stop behaving in the characteristic way we're predetermined to forever behave in"
The "corruption" related to rotations arises from the obvious failings of the system and a need to both work around it enough to get by and cope with it enough to not go insane.
So long as the incentives remain perverted, so will the behavior.
On the surface it sounds perfectly reasonable. As the author explains, it's falls apart quickly. There's still going to be people that will make the argument that, given the author's specific example, that "it gives everyone a more complete understanding of the product to work that way". It's wrong (I'll elaborate if required). But I can hear it.
This affected me in a way, though, that is even more unreasonable -- "The Wire" rotation example, it'd be like ... I don't know ... having the person who designed the guns the department uses participate in the "murder investigation rotation".
Due to a company acquisition, I found myself kludged into an Architecture Engineering team ... I was/am a developer. This happened because Infrastructure[0] didn't want to lose their developer (me[1]) and my role at this place over 17 years had expanded to the point that I fit on any team and no team. I gathered I was put in Arch due to my elevated title (and a misplaced concern of insulting me) and because that specific team because it had "unix guys"[2], they often know how to write shell scripts, which are kind of ... oh, and this other guy is a developer in Ops, too -- completely different language/framework/tech -- but ... it quacks like a duck?
They had a two-week on-call rotation between 5 (now 7) men. I managed to hold off being worked into it for half a year using the same argument: "I support write software in .NET for Windows, your legacy team supports software on Unix/Linux. I expect to be woke up at 3:00 AM if anything of mine fails, all the time and nobody on your team is qualified to log into the box let alone troubleshoot it ... and vice versa".
The first few days of my first on-call rotation consisted of being woken up at 2:00 AM for some server-or-another, me finding someone capable of resolving it, then finding their off-hours contact info, and about 20 minutes later apologizing to them, repeating what I was just told and going back to sleep. My toddler (at the time) could have done that part of my job. I repeated my difficulties in "actually being useful on-call" to my manager during that week at our 1:1 (to which I was brushed off, again), but included my difficulties in "finding people to call" ... he must have thought he found an easy win, there, because he nearly cut me off half-way through with a "Just call my cell if you run into trouble with that." So my new on-call work flow became: (1) Wake up at 2:00 AM to a ringing phone, (2) Write down the ticket number, (3) wake up my boss to find out who to call, (4) thank him, finishing the call off with "He's more likely to answer if you call, would you mind relaying the ticket number to him for me?" It reduced my TTRTB (Time-to-return-to-bed) from 10-15 minutes to far less than 5.
That insanity was the biggest factor in why I left but not because of the apologizing/dislike of it all. My boss knew he was operating in a tricky spot. If his boss knew I was even slightly unhappy with being on-call, I'd be taken out and he'd have taken grief. His options were (a) explain to the rest of the team that "this guy and this other guy don't do anything resembling your work so rather than add them as one more delay to waking you up (or worse, breaking something), they're going to manage on-call for their own apps amongst themselves and not be part of our on-call" or (b) continue to accept calls from me at 2:00 AM reminding him of how dumb it was to put me on call. He chose the latter. And as I evaluated their (much larger than the company I had come from in the merger) IT operation, I saw a pattern of "because that's how we have always done it" and similarly ridiculous -- astronomically expensive at times -- operational choices. That culture was pervasive throughout IT because the merged company had far more people (2:1?) that made up the new organization because -- despite the companies having similar IT services/quality -- we operated better ... with far fewer people.
[0] We basically had Infrastructure/Architecture and Development. Technically Infra/Arch were two distinct VPs reporting to whatever the title was of the interim person considered "the C-Level over IT" during those months of the integration.
[1] And I wanted nothing to do with "Enterprise Development" at this place.
[2] I wrote nothing that ran directly on Linux/Unix at that time.
When senior engineers tell you they can't do anything without more headcount, maybe consider believing them.
I'd seen this several years before watching the series, and it was this lecture specifically which sold it to me.
<https://yewtu.be/watch?v=nRt46W3k-qw>
The bit on statistics starts at about 8m20s.
Nutshell: If you want to find out where the dirt is done, parse some statistics.... I learned as a reporter to start despising statistics and to regard anything that was ever cited to me in advance of an argument as dubious just because somebody was pulling it out and using it. I was that cynical about it. As I got better as a reporter I realised that as soon as any of our institutions create a means of measuring how things are going in terms of quality, someone will run behind them within the institution to destroy that statistic as a meaningful measurement of anything.
There's exposition around this both ahead and after, and again, there's a ton of meat in this talk.
E.g., Azure: there's customer support, but they only do the "make customer's problem (or really, the ticket) disappear" side of it. Woe be unto you should your problem be caused by a bug in Azure: they have no means of dealing with that. Eventually the ticket dies — usually because my patience has limits — and I am sure they count that as a "win". Ticket closed, after all … even if my problem is no longer a problem b/c I've just abandoned ship.
And the amount of software/stuff out there with no means to report bugs/defects is rather astounding.
But taking life lessons from fiction is a serious mistake. I made those mistakes many times. They're fantasies dreamed up by writers, and being fantasies, those imaginary worlds work in the way the writer thinks things ought to work.
The real world doesn't work that way. Real interactions among people, if they have any relationship to movie plots, is simply accidental.
This is a large reason why I have slowly gravitated over the years towards reading history books rather than fiction. History is real, and it doesn't work like fiction (a beginning, a middle, an end). The life lessons in them actually work.
For just one example, Star Trek is the fantasy of the benevolent dictator, embodied by Kirk, and his idiot savant advisor, Spock. I love ST as much as anyone, but the benevolent dictator is a pure fantasy.