Yep, "staying on message" and "taking one for the team" are just part of leadership. That said, being the messenger doesn't feel that good when King Leonidas kicks you into a bottomless pit. Especially when it wasn't your fault.
Career Tip #84: Suck it up!
I guess I should be fair... Phil Simon's too BIG to IGNORE is really NOT a book for technologists, much less those well on their way on their own "Big Data" journies. It is clearly labeled as a primer for chief executives, company owners, industry leaders, and business professionals. Those surely must be the folks that rated this book 4.7 (out of 5.0) "stars" on its Amazon listing.
For that audience, this book may be good, but I don't really know. I read this book because I've been trying to start up a "professional book club" at my employer and a bright colleague recommended we read this book. From reading the synopsis, I knew it wasn't the book for me, but... my desire to create a more "collaborative organization" got the best of me and started me down the path of reading this book that clearly was not targeted at me.
So... if you are looking for a book to help you understand what all the buzz is about around "Big Data", and you don't want to be bogged down with techno-jumble (there is a high-level chapter on Hadoop, NoSQL and the like!) then this might be the book for you. I'd love to hear some feedback if that's you and you decide to read this book as it quite possibly is a decent publication for the target audience.
On the other hand, if you can already conceptually explain what Hadoop is and can share 2-3 examples of what big data is and how it could help your organization, then only buy this book if you are suffering from extreme insomnia as you'll be lucky to make it 10 pages at a time before your eyelids will feel like a ton and you'll be drifting off to sleep. 
The (in)famous "cat herding" EDS video describes a big chunk of my day and still cracks me up every time I see it. If it is new to you, enjoy!
My heart sank today at work -- but first some background. We are a large organization with teams spanning technologies from the mainframe to mainstream Java and .NET frameworks; not to mention a deep investment in C/C++. With that, it is not hard to image we have a variety of software development maturity levels across all of our teams. Additionally, our big push (some here call it an experiment!) to agile has taken many different paths due to our very decentralized/autonomous model.
I realized today that one of those paths has surely taken a wrong turn when one of our senior architects said, "as an agile team we have a lot of meetings" when another technology leader was trying to schedule some time with him for a discovery effort. Wow! It doesn't seem this gentleman gets it. More upsetting is that his whole team just might not get it either. I'm starting to wonder what that high-priced "agile coach" has been telling them!
Hopefully, I'm not as clueless at the boss above, but obviously, this statement is a warning sign and I need to get more engaged to make sure this team hasn't gone too far astray. The first thing I'm going to say is Stop "Doing Agile" and Start "Being Agile" (stole the line from the following ThoughtWorks video).
First thing on the plate is to make sure this team sees agile as the ability to create and respond to change in order to profit in a turbulent business environment and not as a rigorous & immutable process that has to be followed to the letter. The second thing is to help them get out of the meeting room and to get them at their workstation and collaborating in small teams as needed.
Anyone else have any "Agile Is _______" horror stories to tell?