OH how I can relate to the sentiment expressed in "Rise of the Rotation". On the surface it sounds perfectly reasonable. As the author explains, it's falls ap

OH how I can relate to the sentiment expressed in "Rise of the Rotation". 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.