That's not how you get there

 I've been reading through Bold by Peter Diamandis.  It's an interesting book, with a lot of interesting ideas.  In the same period, I was listening to the audio book of The Traveler's Gift by Andy Andrews.  Despite both books being really good, I find them interesting in different ways.

There's only one big problem: both hit periods where you just need to power through to make it to what you really want to hear.  In the Traveler's Gift, it's the beginning.  If you can power through the first two to three chapters and get beyond how bad life sucks, then you are in for a treat.  The rest of the book is really interesting and well worth the time spent. 

Bold doesn't work that way.  Bold has a tendency to go from very good to slog in numerous places.  Some parts are brilliant, and leave me thinking about places I could go and ways to apply the things listed.  And then you have to slog through a good chunk of stuff to make it back into more interesting stuff.  That's just the way the book is written.  

The big problem I have with Bold is me.  I know I dislike working in large groups, forming companies, and solving the day to day people problems.  I'd rather spend my time working on my things and hope it all goes and works out well.  Or if it doesn't, I sit back at the drawing board and try to rewrite and revise.  Those rewrites and revisions solve lots of problems.  

But it's hard to make it work that way for complex processes and procedures.  It's not the complexity that's the problem.  It's the scope.  Some of the things I envision doing are the work of entire teams, done by one person.  And the pace I have to create these complex machinations just doesn't fit on scale.  Maybe if I had two to three hours a day just to work on my own ideas it might.  But I don't have those.  I have too many other problems to solve, and often it's other people's problems that need resolved.  Or a way to monitor something so a person who's not me can get the information necessary to make the right choice.

If they actually follow the flow chart I created, which is unlikely.

There's always resistance.  No matter how good the idea, there is always resistance.  And trying to get the most resistant person to follow the procedure is the hardest.  Because they don't know what the data means, and won't follow the procedure.  Even if it will lead them directly to what they need to act on. Because they don't understand it, and they won't focus on the material you have told them to focus on.

Simple questions become complex.  Go to this website.  Look at this specific thing.  What does it say?  Does it say X?  Then there is a problem.  If it doesn't say X, then there is no problem.

"What about this thing four lines down the page?"

"Ignore it." 

"But I can't.  It says alsdfhasdlfkhjalgedfj and I need to know what that means."

"It is not relevant to the problem at hand." 

"But I need this information."

And this is how the conversation goes.  From people who won't take the effort to learn LAN switching, router behavior, or any other complex technology.  

I know I need to learn more about cell signal strength and signal to noise ratio, but I don't have time to do that right now.  So I have to accept that when I look at that piece of data, it doesn't mean anything to me.  But the square box that tells me the router is on cell backup?  Yes, that is the important bit.