Ok, I’m sorry, I’m going to ruffle feathers here but… I’m trying to read some newer development process books and… oh my… even super popular ones are so immensely long winded and unconvincing in their dogmatic argumentation: this is bad, this is good, because I said so that’s why.
Recent examples that I’m struggling to finish: “Team Topologies” and “Data Mesh” - I mean they might be great but I’m getting strong “this should’ve been a blogpost” feels.
I can’t. “This is how you simplify things for these silly dev folks who struggle to understand even basic stuff.”
“How to break down large domains”
If you think that there is a Perfect Org Breakdown for all the things I believe you don’t know anything about anything.
“Here is example number four of a team who struggled to keep up with requests after a lot of people started to use, love and depend on the thing the team had built”
“They are struggling because… actually… they are extremely dysfunctional and not actually… extremely successful”
Grrrrr 😡
@Patricia The idea that google works that way is a fantasy and whoever says it does, I want to talk to them right now.
Google *looooooves* meetings. YAQS is dying. Everyone is encouraged to run office hours. Documentation is often dramatically out of date.
@Patricia I still want to meet them so I can deride them. I am a google sre. I'm on one of the top 10 highest incident load teams, one of the few tier 1 rotations.
I know how this works. I know how SRE does and does not scale. This process you're describing sounds a lot like "if you have a bunch of SRE you can dump all your problems on them and becuase they're a distinct org it'll all get hashed out at the VP level and you can collect promo and leave before it's done."
Patricia Aas
⛈️ Information ⛈️