Some thoughts on email inspired by a recent New York Times opinion piece by Adam Grant, “No, You Can’t Ignore Email. It’s Rude.” My favorite rule of thumb: To get less email, send less email. Other people will be less inclined to fill my mailbox with replies if I don’t send requests/replies to them in the first place.

Gary Klein’s 2013 book “Seeing What Others Don't: The Remarkable Ways We Gain Insights” is a good read, as I’ve found with his his other books. He likes to explore a topic from stories and search for corroborating links to draw together new conclusions. And as this book is about insight, the overall story of this book describes his journey of discovery as he delved into the topic. I particularly liked his discussion of the challenges that organizations face in gaining and using insights.

Systems thinking guides us to step back and look at the system. What created the environment in which the error occurred? Even beyond “errors”, what makes the system operate in some way that we find objectionable? What is the system that we are describing? What do we WANT from the system? Then we can dive in and look for understanding behind what is creating the undesirable results. It is incredibly rare that the root cause can be placed at the foot of an individual. It’s the system.

Mark Graban has written a great book on statistics, Measures of Success: React Less, Lead Better, Improve More. He focuses on Process Behavior Charts that help highlight the natural variability of a process and can really show when there has been a change in the underlying system. He does a nice job (for me) of simplifying the concepts and the underlying reasoning. He’s even put the math at the back of the book, in favor of providing clear reasoning and project flow.

I recently read a pair of books that talk about project management shifting into product management - both of which seem to blame the woes of organizations on project management. One is Mik Kersten’s Project to Product: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework, and the other is more of a work-in-process book (and free) #noprojects: A Culture of Continuous Value by Evan Leybourn and Shane Hastie.

Overall, these books present some interesting ideas on how to think of delivering value - whether it is in a project environment or not. And they present a few frustrations for me in that I don’t think the core problem is due to “projects.” I think it is deeper embedded into organizations that are so fractured that the flow of value has been lost. Lets get that righted, and project management AND product management work much better.

My review of Kevin Kohl’s Addicted to Hopium - Throughput: Using the DVA Business Process to Break the Guesswork Habit. The book is a fictionalization of the long history that Kohls has had in bringing Theory of Constraints and related approached to GM and other organizations. Kohls gives us the story of MegaCo and engineer Andrew Wright and their journey from barely being able to keep their heads above water to applying a strategic approach to improvement, thanks to the impetus of a guru in the form of a possible customer.

Another piece on dealing with collaborators and personal relationships from Adam Kahane in Strategy+Business, this time “There’s No Such Thing as Difficult People.” His suggestions revolve around the idea that whenever I am upset or angry or in a pique, it is me that is upset. What is it about me that is causing that scenario? How can I “wear the world as a loose garment?”

In essence, this book is about taking the Lean Startup concepts and applying them much more broadly - inside companies, non-profits, governments, and or even a lemonade stand. Most of the ideas and proposals in the book make a lot of sense, and it is useful for me to have them collected in this fashion.

Gene Kim and John Willis recorded a set of conversations called Beyond the Phoenix Project to talk about the DevOps movement since the publication of The Phoenix Project.  (It’s available as an audio and a transcription.) I very much appreciate that the thinking behind DevOps has been geared around learning and applying concepts and ideas from all of these areas. I'm sure there are cargo-cultists who simply try to mimic what they see other people doing, but the people who are developing and growing in DevOps are clearly those who are looking at the giants that have come before them, climbing up on their shoulders, doing something new that is relevant to their current view of the world, and then sharing that back with the community to test and refine and develop further. I got a strong sense of excitement and desire to learn from this.