But while you're along for the ride (or trapped on the slowly sinking ship), it can be really helpful to see where the big company's policies and procedures are outright dysfunctions. Not everything they do is merely "this is how things are done in all large organizations." Then you can take a list of a few practices that result in ossification and a slow death to your next small startup. Maybe you won't take away a polished playbook on how an industry leader handles product development, but having firsthand experience on what breaks at "scale" is also useful.

Some hypothetical examples: What happens when there are more than four engineering teams? What changes when dedicated scrum masters are introduced and begin arguing about whether work belongs in sprint 133 or sprint 134 while walking past your cubicle? How do enterprise contracts for PaaS providers work? And, at my current employer, what happens when more than 100 engineers' work is shelved for holiday "frosts" and "freezes?"

Afterwards, you'll have more interesting conversations with the bright-eyed 23-year-olds working with you at The Next Startup. Instead of "I feel like this is a bad idea," or--heaven forbid--"Because I said so," you can confidently state "Company X tried Y. Z was the tragic result. How can we implement Y, but avoid Z?" It's one thing to have head knowledge of why frequent releases are beneficial, but watching what happens the moment a code freeze is lifted and hundreds of commits hit production? That's priceless.