Some reflections:

Culture

  - The "all engineering is organized by business function" is a business trick i've seen old dot-coms implement. When you have a business function that goes from making you money to costing you, just fire everyone in that business function and sell it off. You quickly get rid of what's dragging you down and continue your profitable business functions. However, this also creates duplication of some jobs, waste, and an insidious bureaucracy where teams are fighting each other. (I could have read that section wrong, but that's what it reminded me of)

  - Engineering Swaps: Really? You just uproot people so they have to re-learn how something else works and take time away from getting stuff done? Couldn't you just do a couple hour-long knowledge sharing sessions between developers?

Random thoughts

- Don't design too far ahead - doesn't fighting fires and coming up on sudden, unexpected deadline changes due to lack of foresight kind of drag on your employees? You can't keep overworked code monkeys forever. It's one thing to code "quick and dirty" to get a job done. It's another thing not to plan for the future.

- Put end to end responsibility on a single engineer - so when that guy's on vacation nobody knows how to fix the thing he owns that broke?

- Process - Doesn't say if you require change control, but some sort of change alert/control system is really useful to tell people when you're changing something which may affect others, so they can immediately see what could have affected the broken thing and call the person who could have broken it.