Be critical or be corrupted
OH how I can relate to the sentiment expressed in &quot;Rise of the Rotation&quot;.<p>On the surface it sounds perfectly reasonable.  As the author explains, it&#x27;s falls apart quickly.  There&#x27;s still going to be people that will make the argument that, given the author&#x27;s specific example, that &quot;it gives everyone a more complete understanding of the product to work that way&quot;.  It&#x27;s wrong (I&#x27;ll elaborate if required).  But I can hear it.<p>This affected me in a way, though, that is even <i>more</i> unreasonable -- &quot;The Wire&quot; rotation example, it&#x27;d be like  ... I don&#x27;t know ... having the person who designed the guns the department uses participate in the &quot;murder investigation rotation&quot;.<p>Due to a company acquisition, I found myself kludged into an Architecture Engineering team ... I was&#x2F;am a developer.  This happened because Infrastructure[0] didn&#x27;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 &quot;unix guys&quot;[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&#x2F;framework&#x2F;tech -- but ... it quacks like a duck?<p>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: &quot;I support write software in .NET for Windows, your legacy team supports software on Unix&#x2F;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&quot;.<p>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 &quot;actually being useful on-call&quot; to my manager during that week at our 1:1 (to which I was brushed off, again), but included my difficulties in &quot;finding people to call&quot; ... he must have thought he found an easy win, there, because he nearly cut me off half-way through with a &quot;Just call my cell if you run into trouble with that.&quot;  So my <i>new</i> 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 &quot;He&#x27;s more likely to answer if you call, would you mind relaying the ticket number to him for me?&quot;  It reduced my TTRTB (Time-to-return-to-bed) from 10-15 minutes to far less than 5.<p>That insanity was the biggest factor in why I left but <i>not</i> because of the apologizing&#x2F;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&#x27;d be taken out and he&#x27;d have taken grief. His options were (a) explain to the rest of the team that &quot;this guy and this other guy don&#x27;t do anything resembling your work so rather than add them as one more delay to waking you up (or worse, breaking something), they&#x27;re going to manage on-call for their own apps amongst themselves and not be part of our on-call&quot; 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 &quot;because that&#x27;s how we have always done it&quot; 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&#x2F;quality -- we operated better ... with far fewer people.<p>[0] We basically had Infrastructure&#x2F;Architecture and Development.  Technically Infra&#x2F;Arch were two distinct VPs reporting to whatever the title was of the interim person considered &quot;the C-Level over IT&quot; during those months of the integration.<p>[1] And I wanted <i>nothing</i> to do with &quot;Enterprise Development&quot; at this place.<p>[2] I wrote nothing that ran directly on Linux&#x2F;Unix at that time.