Dan is actually referring to Google where "complexity" for a very long time was an explicit requirement for career progress to Staff level and beyond.
I bet it's the same way even now, unofficially. For better or worse, engineers do not seem to sufficiently value simplicity, so people hated the rules, but played the game, producing insane rube goldberg like backends all over the place that you need whole teams of experienced SREs to run successfully. The fact that this is ridiculous was not at all lost on people either - memes on Memegen (an internal meme site) were pretty vicious. But, not a heck of a lot you can really do if you want those golden handcuffs to turn into platinum ones.
I'd be remiss if I did not mention the silver lining in all this: Google's SRE team is very likely the most experienced in the world, and SREs are respected there. Stuff wouldn't run at all if this wasn't the case, and certainly not with five nines of reliability.
Another bullshit requirement in the general case is "cross-team impact". No matter how valuable you are as an IC, you gotta get a bunch of other people involved so they write your peer feedback and endorse you for a promo. Sometimes this makes sense. Often it does not. And those people better be one or two levels above you, which is a problem in a remote office.
There was a whole slew of antipatterns like that which might have made sense at some point in the past, but now are perceived as an immutable thing nobody can do anything about. So in a way, "culture" is not necessarily an _universal_ good, although at the time I was there the good outweighed the bad IMO.
This cultural stuff is also why Agile by itself does not mean you'll be particularly "agile", nor is Agile required for high agility. As a manager I've found that if I can get people to care about things and give them autonomy, most of them will not require close supervision and will move faster than they'd otherwise. Some will require supervision, reminders, incentives, and all that, and those are best sequestered from the rest and grouped with folks with similar working styles and put to work on tasks that tolerate that kind of thing, or in clinical cases let go.
IIRC it is still for "Software Engineers" but it has been replaced with Simplicity for "Site Reliability Engineers". Of course just changing the written rules doesn't change everything, and it creates an interesting friction.
I bet it's the same way even now, unofficially. For better or worse, engineers do not seem to sufficiently value simplicity, so people hated the rules, but played the game, producing insane rube goldberg like backends all over the place that you need whole teams of experienced SREs to run successfully. The fact that this is ridiculous was not at all lost on people either - memes on Memegen (an internal meme site) were pretty vicious. But, not a heck of a lot you can really do if you want those golden handcuffs to turn into platinum ones.
I'd be remiss if I did not mention the silver lining in all this: Google's SRE team is very likely the most experienced in the world, and SREs are respected there. Stuff wouldn't run at all if this wasn't the case, and certainly not with five nines of reliability.
Another bullshit requirement in the general case is "cross-team impact". No matter how valuable you are as an IC, you gotta get a bunch of other people involved so they write your peer feedback and endorse you for a promo. Sometimes this makes sense. Often it does not. And those people better be one or two levels above you, which is a problem in a remote office.
There was a whole slew of antipatterns like that which might have made sense at some point in the past, but now are perceived as an immutable thing nobody can do anything about. So in a way, "culture" is not necessarily an _universal_ good, although at the time I was there the good outweighed the bad IMO.
This cultural stuff is also why Agile by itself does not mean you'll be particularly "agile", nor is Agile required for high agility. As a manager I've found that if I can get people to care about things and give them autonomy, most of them will not require close supervision and will move faster than they'd otherwise. Some will require supervision, reminders, incentives, and all that, and those are best sequestered from the rest and grouped with folks with similar working styles and put to work on tasks that tolerate that kind of thing, or in clinical cases let go.