Erik on Software

New Book Review: "The Threshold"

New book review for The Threshold: Leading in the Age of AI, by Nick Chatrath, Diversion Books, 2023:

Copy provided by Amazon.

In the introductory pages of this book, Chatrath states that "this book functions as a first foray into exploring what good leadership looks like in the present and coming ages of AI. John McCarthy defined AI as the science and engineering of making intelligent machines. I hope to expand your concept of what it is to be a human leader in a time that challenges our former ways of being with technology. Where technologists start with the question 'What can we automate?' and ethicists start with the question 'Should we automate this?', I start with the leadership question 'How can leaders promote flourishing as technology advances?' This book therefore equips you to forge a new synthesis between machines and humanity in the face of future technology-related disruptions. This new synthesis, which I have termed 'threshold leadership', is the subject of this book."

The author later states that "Things that ideally should not happen unfortunately happen all the time in organizations. Is there an individual who thinks, 'Oh my, I should not have done this'? Sadly, I have found this ownership of error to be rare. Software product developers are often so removed from the consequences of their work that many don't even think of themselves as leaders who have a disproportionate impact on the world. As one senior leader in a large tech company recently told me, 'For all I know, I might have been in a situation where I contributed to an AI algorithm written wrongly,' Looking down she added quietly, 'Do I even know?' This is not about throwing software developers under the bus. The reality is that software developers don't have any say in, or any perspective about, what they are building. They often work on a very small slice of a bigger vision."

Chatrath mentions that threshold leadership is actually a fifth metaphore that follows the four discussed in a 2014 book by Frederick Laloux called "Reinventing Organizations: A Guide to Creating Organizations Inspired by the Next Stage in Human Consciousness": "wolf pack", "army", "machine", and "family". The wolf pack leadership approach is typified by executives who disregard others, disconnecting their thinking from their full humanity, and prioritizing short-term personal success and wealth. In contrast, leaders at the army stage of leadership often slump into superficial, derivative thinking who cling to norms too tightly, instead of bringing their whole selves to their thinking. The behavioral therapy that provided support for the army leadership approach also paved the way for the machine stage, in which leaders usually live in the future, hardly ever making it back to the present, pursuing growth just for the sake of growth. Interestingly, Laloux likened this pursuit, or condition, to be akin to, using medical terminology, a "cancer". The family leadership approach, however, views formal structure to be less important than values and inspirational purpose, with leaders comfortably drawing selectively on the benefits of earlier stages.

The author comments that "in the recent past fewer than 10 percent of leaders have progressed beyond machinelike approaches to leadership", and that "each step leaders take - from wolf pack to army to machine to family to threshold - moves them further from merely cognitively led leadership models and onward to embodied thinking, thinking-as-feeling, and thinking with all you have got." According to the author, "threshold leaders will contribute most and will be most satisfied in an era where distinctions between humans and machines disappear", and that "the new story is of connecting thinking and being via four pathways: cultivating stillness, thinking independently, embodying intelligence, and maturing consciousness", each topic of which is dedicated to a separate section of this book, with three chapters apiece. 

Based on the dog ears that I created over the course of reading through this book, I found the first two sections on cultivating stillness and thinking independently to be more interesting than the latter two sections, with the first chapter (entitled "Coding Error") in the second section (entitled "Thinking Independently") the most dog eared relative to all the other chapters. Chatrath summarizes this chapter by stating that it "investigates why human independent thinking matters as AI improves", considering "three interruptive thinking disrupters, before starting to explore what independent thinking looks like practically." It makes sense why this particular section chapter might stand out for me, considering my software engineering career which thrived working as a consultant for a wide variety of firms from startups to multi-billion dollar corporations. 

The three interruptive thinking disrupters that the author covers were taken from a group of fourteen identified by Nancy Kline and her colleagues. While Chatrath fails to mention where readers can find out more about the complete list, it appears that these interruptive thinking disrupters are covered in a book by Kline entitled "The Promise that Changes Everything: I Won't Interrupt You." In his discussion on persuasion, the author mentions in closing that threshold as profound truth means at least three things: (1) "being at ease with, even seeking out, the sometimes contradictory contribution of different disciplines, (2) inviting others into the conversation, regardless of how they currently relate to belief or faith, and (3) nurturing openness and provisionality as to what latest AI and other scientific experiments show. And in his discussion on this third aspect of threshold as profound truth, he states that "this provisionality is the heartbeat of science, as later discoveries frequently disprove or reshape earlier 'certainties.' "

A mantra many heard earlier this decade is to "just follow the science", but the mantra "just follow the scientists" is probably more accurate because research, and opinions based on research, varies over time, keeping in mind the challenges in determining whether research has really been performed and what this research looks like on the ground. Quite some time ago, I recall an article in The Economist magazine stating that computer science really lies at the base of all the other sciences. While I realize this may have been a controversial article, especially because most sciences came before computer science, and many would argue that computer science is not truly a science, I know as a software engineer that the application or data engineering code I write will process data, that the inputs and outputs are based on rules, and that tests can be written to determine whether these inputs and outputs meet expectations, but with use of AI (including all its subsets, such as ML), there aren't hard rules like those that exist with application or data engineering code, because models take the place of rules. 

While I've never watched the Black Mirror series before because I don't watch much television, Chatrath mentions that the Black Museum episode explored the assumption that a person's value is no more than what is reducible to equations. "This assumption is similar to the assumption that 'you are just your brain' - or, similarly, 'your value lies 'only' in your brain. In the context of advancing technology, these assumptions arise frequently and persuasively. The assumptions matter since, in the words of essayist and novelist Marilynne Robinson, 'whoever controls the definition of the mind controls the definition of humankind itself.' " The author later comments that "the assumption that you are just your brain often rests on a philosophical view known as materialism, which is the view that the observable physical world is all that exists. The word 'observable' is key. Materialism can also include the belief that science is the only way to truth, a belief known as scientism. A significant number of scientists and philosophers think that scientism omits vital parts of reality."

After covering the inevitable that "all scientists, whether neuroscientists or computer scientists, have belief or faith", and that "it is important to consider what is persuasion and what is established fact", Chatrath in his closing statements on persuasion that professor Frank Wilczek, recipient of the 2004 Nobel Prize in Physics, accepts the fact that no current AI research enables AI to get close to two "big advantages" that human have over AI (connectivity and interactive development), but unfortunately takes a leap of faith in the following sequence: (1) "human mind emerges from matter", (2) "matter is what physics says it is", (3) "therefore, the human mind emerges from physical processes we understand and can reproduce artificially", and (4) "therefore, natural intelligence is a special case of artificial intelligence." While the author explains that these first two statements are "beliefs or worldview statements, not testable scientific hypotheses", however, he doesn't explicitly address these second two statements. Perhaps this is the case because these first two are foundational to the other two, but it's important that people understand why Star Trek featured human transporters will never be built.

The author repeatedly argues for the "practicality" of what he seeks to lay out in this book, but unfortunately, I don't think he ever achieves this goal. The "threshold resources" sections he provides at the end of every chapter were written with good intentions, but I don't find these to be very inspirational, mainly because these are written very dryly: largely a series of bullet points, with no diagrams. I received this book from Amazon a week or so prior to publication date, and while ChatGPT had already become a short-lived phenomena by late-2022, the output of these sections feel at first glance to be generated by ChatGPT. But the assembly of words Chatrath has written is novel, not to be replicated by current day AI. As a takeaway for the author, perhaps he could expand on these end-of-chapter sections to form a companion guide to this book.

Community Post: Part 2 ("Colleague" Meets DALL-E)

Gfesser via DALL-E: "Hieronymus Bosch painting of male and female business colleagues respectfully disagreeing with one another while running together along the Chicago lakefront."

A well-received community post I recently made:
https://www.linkedin.com/posts/erikgfesser_career-wordorigin-respect-activity-6998107676408770560-dHt_

Early in my #career, I called individuals with whom I worked "co-workers", and later, "teammmates", but got into the habit of calling them "colleagues" quite some time ago. I've been reading a great book called "The Ideal Executive: Why You Cannot Be One and What To Do About It", by Ichak K. Adizes, which in chapter 7 discusses the (surprising) #wordorigin of "colleague".

"What I'm going to say now may sound very simple and obvious, but it took twenty years and a lot of personal pain to discover it. I wish it *were* obvious. A colleague is not someone who agrees with you. A colleague is someone who *disagrees* with you but for whom you have #respect. Why? Because you don't learn from those who agree with you. You learn from those who *disagree*, in the course of the debate that evolves out of the conflict between you. Learning from differences is painful, but we also enrich ourselves through being different. The root of the word 'colleague', in fact, comes from the Latin word 'Collegum', which means 'to arrive together'. In other words, we started with different points of view, but through interacting we have arrived at the same point. And in Hebrew, the words Amit (colleague) and Imut (conflict) derive from the same root. Words that share the same root are interrelated; in this case, the connection is that there are no collegial relationships without conflict. And the reverse can happen: Good conflict can make people to become colleagues, if they learn from each other because and not in spite of the #conflict. Used appropriately, it can help legitimize and unite our differences. Like a spouse, who is ezer keneged (helpful against), colleagues help each other cross-fertilize ideas and expand horizons - through conflict. Without conflict, then, you don't have a #colleague. For good decision-making, team members who both respect and disagree with one another - colleagues - are essential."

After deciding to post this, I thought this might be a good occasion to experiment with the DALL-E #deeplearning image synthesis model for the first time. After generating dozens of images, I ended up choosing the attached image, which was generated by the following description I wrote: "Hieronymus Bosch painting of male and female business colleagues respectfully disagreeing with one another while running together along the Chicago lakefront." More on this in the comments below. :-)

---

Gfesser: So about the description I input into DALL-E: I ended up needing to play with the wording, and choose a variation that met my needs. My original wording simply stated "business colleagues", but all the images kept generating seemingly male images, so I explicitly added "male and female". Another interesting aspect of the generated images was that almost every single one depicted people running into each other as though they were going to collide, rather than running alongside each other, and the few which depicted people running in the same direction also had them facing forward rather than toward each other. All of this said, I'm liking DALL-E and will continue to experiment with it in the future.

Associate Professor of Computer Science and Engineering: Erik, as we know now so well, many words assume meaning with usage over time or as a matter of current convention/jargon. Most org cultures might only grudgingly accept frequent disagreements, but frequent conflicts would seem dysfunction to them. Be as that may, I think, parties need to be sure that they have facts right and POVs well-grounded. They place it respectfully as their individual submissions and do not push it beyond their powers (pay grade etc.). Some of this subject would have to do with personalities and people unwilling to take feedback/advice; [Psychologist] is a great expert here.

Gfesser: True, terms can assume different meanings over time, and as we know from the technology space, organizations can't even agree on how to define commonly used terms in the present. Adizes discusses colleagues from the perspective of the same team and same level, and argues that while leadership requires a variety of strengths, a given individual by nature cannot typically exhibit all of these, so executives should specifically look to hire those who fill these gaps: hiring individuals who repeatedly bring the same strengths to the table leads to redundancy. Per my explanation of the reason why I chose the image I posted, most of the generated images demonstrated unhealthy conflict by showing people about to collide with one another, possibly due to analysis paralysis (for lack of a better term) or different goals.

Associate Professor of Computer Science and Engineering: Erik Honestly, I've kinda firmed up away from a strengths-based approach to one that strives to match techno-project requirements of a job/assignment with my preparedness (e.g. skills, knowledge, domain etc), self-awareness & that X-factor, which definitely has to be courage, but could be grit/risk-taking/persistence as well. For example, there might not be much scientific evidence for the strengths-based approach.

Regarding the peripheral topic of etymology, off-hand I can say, the Hebrew root (Afro-asiatic family) "mit" or "mut"--which seems to mean view or thinking--have the same form "mat" & almost the same meaning in Indo-European family members--Punjabi & Hindi. So, for example, in both Hindi & Punjabi, ek-mat means unanimity, sam-mat (seh-mat in Urdu) means consensus, lok-mat means people's say, etc. Off-hand, I can't say, whether the root is Proto-Indo-European (PIE) or came across via Persian/Arabic from the Afro-asiatic family. Or the other way around--went from these Indo-European members via Persian/Arabic to Hebrew. Of interest here is that another Indo-European root sounds similar if not the same--English mate, mit (Punjabi), meet (Hindi or Urdu), mitr (Hindi/Sanskrit) all mean the same.

Gfesser: Tracing natural language lineage is always harder than doing so for computer languages, isn't it. As far as the workplace is concerned, I would agree with respect to "hard" skills, and this topic can be an especially opinionated subject due to the variety of the human experience: one-size-fits-all solutions are rare.

Associate Professor of Computer Science and Engineering: Erik True. Genomic studies seem to settle some issues there. For example, they seem to be lend credence the old steppes hypothesis that the origin of PIE is the steppes north of Black Sea & Caspian Sea :)

New Book Review: "Hero on a Mission"

New book review for Hero on a MIssion: A Path to a Meaningful Life, by Donald Miller, HarperCollins Leadership, 2022:

Copy provided by Amazon.

Just after I had first started reading through this book, someone commented to me that they had also started reading another book, entitled "Man's Search for Meaning", by Victor Frankl. In response, I remarked on a coincidence: Frankl's book is not only cited throughout "Hero on a Mission", the author of this other book is actually cited at the outset within the introductory pages. While I had heard about Frankl's book, I had also never felt any interest in reading it, because I've not only already read numerous war-themed autobiographies, I've also heard spoken accounts directly from victims of the second world war and immediate post-war period from my own family members, who suffered extreme hardships.

However, upon hearing about Frank's book again, I took a closer look to determine whether I might want to read it as a personal follow-up to "Hero on a Mission", and came to the same conclusion. In my view, the differentiator between these two works is the practicality that Miller seeks to provide to readers. Frankl's account of his experiences is provided in the first part of his book, and a paper on logotherapy is provided in the second part, but at this point I'm not interested in hearing more war stories or theories about a particular life philosophy, and am instead interested in hearing what logotherapy, the therapy created by Frankl, might look like from a practical perspective as applied to one's life.

Miller doesn't explain logotherapy in his introduction, but explains Frankl's pragmatic, threefold formula to experience a life of meaning in the third chapter: (1) "take action creating a work or performing a deed, (2) experience something or encounter someone that you find captivating and that pulls you out of yourself, and (3) "have an optimistic attitude toward the inevitable: challenges and suffering you will experience in life." And later in this chapter, the author makes these three elements more relatable as he discusses the life plan he has been using for the last ten years, a plan that continues to evolve, and a plan without which he feels his personal story would "devolve in entropy and ultimately a narrative void. The existential vacuum."

(1) "Life invites us to be important and necessary. If we wake up each day and have a task to accomplish, especially a task in which other people are involved or without which other people might somehow suffer, we become necessary in the world. We sense we have a purpose (because we do). By requiring a work or a deed, I think Frankl was saying: Get yourself a great reason to wake up and get out of bed in the morning. If you do, it will help you avoid the existential vacuum."

(2) "We should acknowledge that we are not alone in this world and in fact the world and the stories unfolding upon it inspire awe. We all know the greatest experiences we have in life are dramatically enhanced if they are shared with others. According to Frankl, to experience meaning, we should get involved with a small group of people we love and who love us, or we should find something that invites our focus beyond ourselves to the beauty of the world around us. A lone walk through the forest is good for the soul just as a trip to a gallery can offer inspiration and a sense of mental expansion. The point is this: encounter something that pulls you out of yourself so that you world becomes larger."

(3) "While I've found each of the three elements of Frankl's formula helpful, it's this last one that helped me transform the most. Essentially, Frankl argued there was no negative event that could happen to us that could not be somehow redeemed. "Redeemed" is my word, not his, but I think it's fitting. By redeemed I mean that, as humans, we are able to take the most painful of tragedies and turn them into something meaningful. Frankl believed that while tragedies should be acknowledged and grieved, they can also produce something beneficial. This doesn't mean tragedies are good. Nobody wants or should have to experience a tragedy. It only means that from the ashes of our tragedies we can create something beautiful, and by creating something meaningful with our pain we begin the process of healing our wounds."

Just recently, I mentioned in my review of "Do Something for Nothing: Seeing Beneath the Surface of Homelessness, through the Simple Act of a Haircut", by Joshua Coombes, that one of the author's passages reminded me of Romans 5:3-5: "...we also glory in our sufferings, because we know that suffering produces perseverance; perseverance, character; and character, hope. And hope does not put us to shame...". Interestingly, these verses also correlate with the third part of Frankl's formula. The hardships my family has experienced have been extremely challenging, and in the midst of these experiences, seemingly unbearable. But what's this? Hardship is actually the first step in a sequence, if we permit the rest of this sequence to play out. 

The author's presentation is broken down into sixteen chapters across a story's three acts: (1) "how to create a life of meaning", (2) "create your life plan", and (3) "your life plan and daily planner." In the first act, the author discusses the four roles we play in life - the victim, the villain, the hero, and the guide - followed by a focus on the hero, who accepts their own agency, chooses a life of meaning, and knows what they want. In the second act, the author discusses the eulogy, short-term and long-term visions, and the daily planner, and in the third act lays out the templates for each of these tools.

One of the most impactful chapters for me is the fourteenth chapter. While the role of the guide is discussed earlier in the book, the focus up until this point is the role of the hero. "Life requires experts. We need people around us who know what they are doing and can save us from our own mistakes. In a way this book has been deceptive. It has taught you to become a hero on a mission even though the hero is not the most evolved role. The most aspirational role for any of us is the role of guide. So why spend so much time teaching people to live as heroes when the goal of life is to become the guide? The reason is, of course, that we cannot become guides unless we have lived as heroes on a mission."

The author later comments that "Victor Frankl's ideas do not ensure that life will go well for us. They simply ensure that we experience meaning whether or not life goes well. His theories, after all, were crystalized in a concentration camp. Mental, physical, and spiritual competence happens when we move into the challenges life offers us. Victims do not face these challenges because they cannot. Villains cause many of these challenges. Heroes walk into and through the challenges and are transformed in the process. Guides, then, teach heroes all they know about how to surmount the challenges. Guides teach us how to have courage because they have lived a life of courage themselves. The reason we want to live as heroes on a mission is, the more we do so, the sooner we will transform into guides."

Subsequently, Miller presents the four characteristics he believes are most critical to develop in order to help others: experience, wisdom, empathy, and sacrifice. I particularly appreciated his explanations of wisdom and sacrifice, perhaps because, while I personally feel as though I'm well on my way in all these areas, I also feel more developed in the other two areas. On wisdom, for example, the author comments that "we know a hero is going to have to gain strength in order to meet the villain as an equal. The hero will have to be strong and wise, and the only way to gain strength and wisdom is to fail and then succeed, over and over." While as a software developer and innovator the need for failure comes naturally for me in the workplace, I can't say the same for life in general.

In the closing paragraphs of the sixteenth chapter, as he wraps up his presentation, the author makes some especially profound statements. "Life can be very difficult, I know. There are tragedies all around us. There is darkness. But don't forget, there is also light. We get to participate in the making of that light. When the existential vacuum comes for you, and it will, remember there is a hope that is very real in the world. We can always make meaning." Interestingly, Frankl focuses on "meaning", and Miller periodically uses the term "purpose" somewhat interchangeably, but he clarifies his intent in the third chapter, something for readers to ponder: "meaning feels like purpose."

"When I experience meaning, my life feels as though it is playing an important role in an important story. I have never been able to prove that sense of purpose is justified, but it hardly matters. When I am experiencing meaning, it *feels* as though my life is a story that is interesting to myself and also good for the world." While I don't particularly care for this explanation, I also value Miller's further thoughts on the subject. "How many people sit in church pews hearing lectures about God only to return home and feel restless? And why? Perhaps it is because we do not experience meaning by studying meaning. Rather, we experience meaning by taking action. Even Jesus said *follow* Me rather than *figure Me out*. What if the experience of meaning requires action?"

Media Query Source: Part 36

The responses I provided to an "anonymous" media outlet series of queries on February 20, 2022:

Media: Best business books for leaders.

Media: Entrepreneurs are short on time. If you could recommend one business book that should be on every entrepreneur's must-read list, what would it be and why do you recommend it?

Gfesser: My recommendation is "The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses", by Eric Ries, Crown Business, 2011. As a prolific book reviewer, Amazon had sent me a pre-publication uncorrected proof of this book for my review in 2011, which not only introduced me to the concept of the minimum viable product ("MVP") at that time, but also provided substantive maturity to the product approach my colleagues and I had already started using several years prior to build a healthcare product, an approach I've continued to use ever since.

Every business offering can be viewed as a product, even services which lack the properties of traditional products, such as consulting. I've noticed that many business books still don't discuss the product approach to business offerings, often still clinging to projects which are planned for specific time durations. The author provides a good introduction to the application of Lean principles, which seek to eliminate any waste that does not add value to the end customer. Lean enables entrepreneurs to determine what customers want during product development to help minimize wasted efforts when rolling out products to the marketplace.

In the midst of his presentation, Ries provides a particularly good quote by Peter Drucker: "there is surely nothing quite so useless as doing with great efficiency what should not be done at all." He furthers this thought by explaining that most people believe projects are inherently failure prone, that a more careful, slowed down process will reduce the failure rate, and perhaps a small, select group of people just happen to have the innate gift of knowing what to build the first time around. The author explains these approaches as relics of nineteenth century management practices, and as I've witnessed firsthand the continued use of these approaches in the current century, I continue to highly recommend this book for the entrepreneur's bookshelf.

---

See all of my responses to media queries here.

New Book Review: "The First 90 Days"

New book review for The First 90 Days: Proven Strategies for Getting Up to Speed Faster and Smarter, by Michael D. Watkins, Harvard Business Review Press, 2013:

Copy provided by Deloitte.

The introduction provided by Benton actually offers a realistic look at what is offered in the rest of the book, unlike many other business texts I've read over the years which initially entice and subsequently disappoint, offering only an article's worth of information watered down to fill hundreds of pages. And I personally have the dog ears I left behind over the course of reading this text as evidence that this is the case. That said, however, the introduction provides enough value that it could actually stand on its own as an article, briefly walking the reader through glimpses of several pertinent topics such as avoiding transition traps, creating momentum, assessing transition risk, mapping out one's first 90 days, and hitting the ground running.

"Even though a lot has been written and discussed about how to be a more effective leader in general, little research and writing addresses how to successfully accelerate through leadership and career transitions. People will go through these all-important career crucibles with little preparation and no reliable knowledge or tools to help them. That's what this book is designed to give you. Your goal in every transition is to get as rapidly as possible to the break-even point. This is the point at which you have contributed as much value to your new organization as you have consumed from it. New leaders are net consumers of value early on; as they learn and begin to take action, they begin to create value. From the break-even point onward, they are (one hopes) net contributors of value to their organizations."

"The root causes of transition failure always lie in a pernicious interaction between the new role, with its opportunities and pitfalls, and the individual, with his strengths and vulnerabilities. Failure is never only about the flaws of the new leader. Indeed, all the failed leaders I studied had achieved significant successes in the past. Nor is it only about a no-win situation in which not even a superhuman leader could have carried the day. The business situations facing leaders who derail are no tougher than those in which others succeed brilliantly. Transition failures happen because new leaders either misunderstand the essential demands of the situation or lack the skill and flexibility to adapt to them."

"The good news is that there are systemic methods you can employ to both lessen the likelihood of failure and reach the break-even point faster. The specific business situations that confront transitioning leaders vary. But specific types of transition situations, such as start-ups and turnarounds, share certain features and imperatives. Further, there are fundamental principles - for example, securing early wins - that underpin success in all transitions at all levels. The key, then, is to match your strategy to the situation."

This book was actually gifted to me by a new manager of mine soon after accepting his offer to work as director and chief architect for the company. As I mentioned in my recent review of "Executive Presence for the Modern Leader: A Guide to Cultivating Success and Thriving in the Workplace", by D. A. Benton, I've spent the vast majority of my software delivery career in hands-on software architecture and development roles, increasingly working with executives over time. Unlike this other book, which likely would have been more beneficial to me at an early stage in my career, if I had wanted to focus on leadership rather than building software, what Watkins offers here is coverage of a much deeper topic that I've revisited time again throughout my career: tackling the first few months of a job, and for someone like me who doesn't have the tendency to job hop, tackling the first few months of a new project or product.

Because the last decade of my work experience has largely revolved around building new software products rather than being parachuted into ongoing projects as is the case with my current roles, I've been spending a lot of time revisiting how I approach my work, gathering together my thoughts on all of the software development and architecture efforts I've lead while working through the suggestions offered in this book. And now that I'm well past the hypothetical 90-day time period covered by the author, regardless of calculation, as I tend to view this as an 18-week time period of 5-day weeks rather than a 13-week time period of 7-day weeks, I've been revisiting what the author does and does not cover.

The biggest drawback of this book, from the perspective of an ongoing software development effort, is not recognizing the need for ramp-up time at the outset. In other words, the need to get up to speed from day 1 on how the product has been built, what development processes look like, and the culture and history of the product. The index to this book doesn't even include an entry for "product". While taking a product approach to both development and non-development efforts is relatively new, it's not like this was an unknown when this book was written in 2013. As a prolific book reviewer, Amazon had sent me a pre-publication uncorrected proof of "The Lean Startup" for my review in 2011, introducing me to the concept of the minimum viable product ("MVP"), but tackling work with a product approach had already started taking root in industry by this time. My experience taking this approach with colleagues, for example, started at least 5 years prior building a product for a healthcare client of mine.

The content of this book is broken down into ten chapters: (1) "Prepare Yourself", (2) "Accelerate Your Learning", (3) "Match Strategy to Situation", (4) "Negotiate Success", (5) "Secure Early Wins", (6) "Achieve Alignment", (7) "Build Your Team", (8) "Create Alliances", (9) "Manage Yourself", and (10) "Accelerate Everyone". Each of these chapters is only about 20 pages, but I found myself reading through the content much more slowly than usual because it is so dense. Unlike my reviews of other books in which I easily recount which chapters brought me the most benefit, I found this book to be actually pretty consistent throughout, especially surprising for a book from Harvard Business Review Press. 

That said, I especially appreciated chapters 3, 5, and 8. The third chapter covers the start-up, turnaround, accelerated growth, realignment, sustaining success ("STARS") model, which explains the five common business situations leaders may find themselves moving into, outlining the characteristics and challenges of, respectively, (1) launching a venture, (2) getting one back on track, (3) dealing with rapid expansion, (4) reenergizing a once-leading business that's now facing serious problems, and (5) inheriting an organization that is performing well and then taking it to the next level.

After this explanation, the author walks through data from the Harvard Business Review transition survey, in which participants were asked which of the STARS situations they thought were most challenging and in which they would most prefer to be. The most challenging situation was assessed to be the fourth type of business situation, the realignment, followed by the fifth and second, respectively, sustaining success and turnaround. As I've thought through my current roles, I think a hybrid of the turnaround and accelerated growth situations is the closest match. While respondents said that accelerated growth was the least challenging, both it and turnaround are in the middle of the pack with respect to respondent preference.

The bulk of my career has been spent on start-up situations, followed by turnaround. Interestingly, respondents rated the start-up the second-to-least challenging, but overwhelmingly the most preferred situation. From a software development perspective specifically, I definitely view the start-up as preferred, but relatively less challenging? I don't think so. While the STARS model helped put things into perspective for me with respect to considering opportunities related to the five types of business situation, I'm not sure it takes a holistic view.

For example, cited opportunities for the start-up are (1) "you can do things right from the beginning", (2) "people are energized by the possibilities", and (3) "there are no rigid preconceptions". However, note a couple key words here: "can" and "possibilities". These words are very optimistic, but as I've been known to say to my clients in the past, everything is possible, but not everything is probable, so saying that something is possible doesn't really provide value. Additionally, individuals far removed from the tasks being discussed tend to think in the realm of their own definitions of possibility rather than probability, so when this term gets brought up by someone it makes sense to explore what they are really trying to say. One important question to ask about the start-up is whether the work has been done well, and whether the overall product has been successful. Respondent preference and perception of challenge don't really speak to either of these aspects of the work. Just take a look at the track history of industry successes and failures. And again, from the perspective of software development, I know from experience that start-up work is an especially challenging endeavor. 

The fifth chapter discusses the fact that executives in transition plan and implement change in distinct waves: (1) transition, (2) immersion, (3) reshaping, and (4) consolidation. As such, the author explains the implications as to how one should manage transition, keeping one's ends clearly in mind when planning to secure early wins. Following an early period of focused learning, an early wave of changes then commences, involving a slower pace to permit consolidation and deeper learning about one's organization. Implementation of deeper waves of change is enabled by the additional insight gained, followed by a less extreme wave that focuses on fine-tuning to maximize performance, by which time leaders are ready to move on.

This chapter later provides the "early wins evaluation tool", which is intended to help assess the potential of candidate focal points for securing early wins. The four questions asked are the following: (1) "does the focal point offer an opportunity to make a substantial improvement in the performance of your unit?", (2) "is this improvement achievable in a reasonably short time with available resources?", (3) "would success also help lay the foundation for achieving agreed-to business goals?", and (4) "will the process used to achieve the win help you make needed changes in behavior in the organization?"

The eight chapter provides a simple checklist for framing the types of arguments one needs to convince people as a leader, in the form of categories and questions: (1) logos: data and reasoned arguments, (2) ethos: principles, policies, and other "rules", and (3) pathos: emotions and meaning. For example, this first type asks whether there "are there biases to which they are falling prey and, if so, how might you demonstrate this?", the second asks "if you are asking them to act counter to a principle or policy, can you help them justify making an exception?", and the third asks "if they are reacting too emotionally, can you help them step back and get perspective?" In a similar vein to this last question, while I appreciate many aspects of this book I think the author should consider working on an updated version that addresses software as a core business function, and provides coverage of products, not just projects.

New Book Review: "Executive Presence for the Modern Leader"

New book review for Executive Presence for the Modern Leader: A Guide to Cultivating Success and Thriving in the Workplace, by D. A. Benton, Rockridge Press, 2021:

Copy provided by Amazon.

The author mentions in her introduction that in conjunction with a new business venture she had started, she took on a personal research project to ask every CEO she met the following question: "If two people start in their careers with similar experience, intelligence, and ambition, why, over time, does one get to this level and one only get to that?" Her research was later published in an article which called this ability "executive charisma", something she came to call "executive presence". According to the author, "this book will work for you whether you are an aspiring or current leader, whether you are hoping to land a great job, thrive in your current role, or secure a promotion. It will help you build the career you dream of. This is the most up-to-date, accessible, and practical guide to developing your own executive presence to thrive in the ever-changing workplace. The lessons I've learned have given me a very good life, and I hope they provide the same to you."

This 150-page book is broken down into 7 chapters: (1) "Executive Presence", (2) "Leadership Styles", (3) "Emotional Intelligence", (4) "Communication", (5) "Comportment", (6) "Appearances", and (7) "Authenticity". While the author doesn't define "executive presence" in her introduction, she argues at the beginning of the first chapter that "there is an unwritten code of behavior among successful executives. They don't admit it. It's almost as if they don't want to talk about it for fear of jinxing it. They may even deny that a code of behavior exists. But it's there. It's executive presence. It doesn't matter how you feel about it; what matters is how your colleagues perceive you. The good news is that it can be learned." In later chapters, she discusses a variety of leadership styles, emotional intelligence as the trademark of a good leader, why communication is more than the words one verbalizes or writes, not leaving to chance what others see about oneself, the power of appearances, and identifying roadblocks and adjusting approach as situations change.

It wasn't until I was asked by a Chief Architect to take on the work of a recently departed Director of Architecture several years ago that I heard the term "executive presence", and it so happens that one of my colleagues at the time used this expression to describe a quality she saw in me. Admittedly, I wasn't quite sure what she meant. I had spent the bulk of my software delivery career in hands-on software architecture and development roles, increasingly working with executives over time, but nobody had explicitly commented on this topic. In retrospect, however, it makes more sense why my roles continued to evolve. While I arguably continued to remain a top technologist throughout my career, my relatively stronger communication skills, discussed in chapter 4, were often cited as one of the core attributes which helped set me apart, with the attributes and behaviors described in the following three chapters also periodically mentioned in passing along the way.

A book such as this would have been more beneficial to me at an early stage of my career, if I had wanted to focus on leadership rather than building software. But what does "leadership" actually mean? At some point in my career, I started hearing clients call their managers "leaders", but these are two different concepts: managing isn't the same thing as leading. As a longtime consultant, it was interesting to witness many clients in leadership positions who had little to no software development backgrounds, which is ironic because unless one is able to relate to the work that is being done it is almost impossible to be an effective leader in the field. A mantra that I've heard in the field over the years is that "leaders lead, others do". What does this really mean? A better mantra that I've heard is "lead by example", implying that in order to be a leader one not only needs to be able to do the work, but actually do it. Fortunately, in the consulting world I had enough people around me who understood all of this. Something to think about if you are early in your career exploring possible paths ahead of you.

All of this said, the two chapters of this book I most benefited from are chapter 2 ("Leadership Styles") and chapter 3 ("Emotional Intelligence"). I think many of the situations I recounted earlier are probably due at least in part to emotional intelligence, something everyone (including myself) can continue to improve, and I always appreciate learning about how different approaches can end up being effective, having learned over time to be careful not to view any particular method as "the" way but simply "a" way. If anything, Benton has provided me with these reminders. The author presents several leadership styles ("visionary", "coaching", "affiliative", "democratic", "pace-setting", and "commanding"), and I enjoyed the included self-assessment along with her recognition that it can be most helpful for people such as myself to possess some traits exhibited by every style. However, to speak to a traditionally introverted ambivert such as myself, the author should arguably weave personality into her next presentation to better speak to a wider audience of readers.

Erik Quoted by CIO Magazine

Some IT project efforts succeed, and some fail. Do warning signs typically arise en route to failure? What might be done to heed these warnings? Can lessons be learned from failing early in a project? And perhaps most importantly, how are "success" and "failure" defined by stakeholders?

I addressed these subjects as part of a media query by CIO magazine, and ended up being quoted by the publication on September 14, 2017 alongside other technology leaders on the subject of project failure. What follows are the original responses I provided alongside some additional sidebars I wrote following publication.

(Extent of quote highlighted in orange, paraphrased quote highlighted in gray, and the CIO magazine article can be found here.)

CIO: Why are organizations so reluctant to kill IT projects that are clearly doomed?

Gfesser: From my experiences as a consultant, the most common reason organizations can be so reluctant to kill doomed IT projects is because of incurred costs that cannot be recovered. The idea is that a significant cost has already been paid, and one might as well make furthered attempts to succeed so that this initial cost is not all for naught. But the problem with this reasoning is that if the direction of the project is unchanged it will continue to fail, leading to even greater incurred costs.

The second most common reason I have seen is that reputations are at stake, and leadership would really like to get the project back on track to some extent so that they don't look incompetent. In all of my years in consulting, I've never seen a project which was significantly behind ever get back on track, but partial success can be met by scaling back the original scope, or moving in a different direction than was originally planned, both avenues of which are enabled my agile methodologies. At the same time, it is important to remember that some leaders define "success" so rigidly as to prevent these alternatives from ever taking place.

Two common reasons doomed IT projects are not killed:

• Incurred costs that cannot be recovered
• Leadership reputation and competency

CIO: How can project leaders determine whether it's the project concept or the project execution that's fundamentally at fault in a failing project?

Gfesser: Additional questions to ask here involve inquiring as to how "concept" and "failure" are actually defined, and the stage at which the project started to fail. From the context, "concept" likely refers to either a conceptual description or representation of what the product or output might look like, or what is often called a "proof of concept", although this latter possibility typically takes place after an initial inception phase. Either way, the distinction between these two is important, because a proof of concept might not be viewed by stakeholders as being part of the execution. However, construction of a proof of concept is often a needed step between the inception and the execution, because taking this additional measure can help mitigate risks that might not otherwise materialize until additional costs are incurred.

In other words, the question as to whether the project concept or project execution is at fault becomes much less necessary if the team actually takes the time to go through the often needed steps of building one or more proof of concepts followed by a prototype which will serve as the actual foundation for the end product that is to be created. Proof of concepts are often built to make sure that adopted technologies will actually do what is claimed, and once it is determined that this is the case, it makes sense to take the next step of building a prototype, and later an MVP ("minimal viable product") in order to start getting the product in front of stakeholders for the purposes of feedback. Project execution is typically the most difficult part of a project, but taking these steps will help ensure success, and if failure takes place in these early stages it can also be seen as success because you found out what you can't or don't want to build! Going back to my earlier comment, stakeholders need to realize that even a flawed idea can be carried out successfully - but is the end product or output really what stakeholders want?

Questions to ask on project concept versus project execution:

• How are "project concept" and "project execution" being defined?
• Viewing a project as just two stages is likely a gross oversimplification. At what stage did the project actually start to fail?
• What do stakeholders actually need or want? Are users actually going to use what is being built?

CIO: Is there a stage at which projects are most likely to fail?

Gfesser: Signs of failure typically appear early in a project if project execution was performed in an agile manner. Failure is not necessarily a bad thing, because it can lead to a more successful product by understanding what doesn't work. One of the benefits of using agile methodologies is to help ensure that the product being built is what the users of the product will actually want to use. If after a series of one or more agile sprints it is determined that the product is going in a wrong direction, the course can be corrected. And in such a scenario, the product owner should actually want project execution to fail so that it can succeed down the road. I've actually never seen a project that failed solely due to choice of product or technology. Failure is almost always due to people or processes, and processes are often comprised of people.

As I think about this topic, I still recall a particular project from early in my career that I have used many a time as an example of how not to execute project management. The consulting firm for which we were working at the time had instituted an executive dashboard - every project being executed at the company was displayed on this dashboard so that executives could see projects at risk. My project manager at the time admittedly spent most of his time tweaking the formulas of the spreadsheets being used under the covers until every cell in the dashboard visualizations turned green. Such a project is simply in the wrong hands from the start! Since this particular manager didn't run projects in an agile manner, visibility into accurate status really was not made possible until a later phase when the product started becoming available for stakeholders to see. If these projects had been run in an agile manner, stakeholders would not only have seen from an early phase that failure was taking place, but they could have had an active part in making a course correction!

Do not hide failure. Hiding failure will likely lead to a product that will not be used, will be used grudgingly, or will be targeted for heavy modification or replacement by another product. If used properly, agile practices will bring failure to light at an early stage, enabling opportunities to change. The later the course correction, the greater the cost.

CIO: Are there any specific types of IT projects that are more prone to failure?

Gfesser: Essentially, any projects involving some degree of innovation, or a relatively high level of uncertainty. All projects face some level of uncertainty, and it is projects with high uncertainty that are more prone to failure because not all uncertainty can be addressed. Projects which have been carried out in a similar way in the past, or involve significant repetitive work are less prone to failure, because precedent exists. Projects which are the result of some level of innovation are more prone to failure, because risks are being taken to build something new or in a new manner, and this latter category of projects frequently involve new software development.

CIO: What are the warning signs that indicate a project is in trouble?

Gfesser: The warning signs that indicate a given project is "in trouble", rather than "failing" typically include not meeting end user stakeholder needs, and missed deadlines. Again, if a project is being carried out in an agile manner, these signs will be seen early because at the end of every sprint the team evaluates how it executed its work in comparison to what it decided to take on at the beginning of the sprint. In cases where not as much was accomplished, the team will adjust its velocity expectations for future sprints. And in cases where users were not pleased with the incremental delivery at the end of the sprint, the team will incorporate the feedback they receive into the next iteration of work.

CIO: What lessons can one learn from a failed project?

Gfesser: The lessons learned from participating on a failed project are innumerable. But in my opinion, the additional thing to keep in mind here is that there are many lessons to be learned from failing early in a project, and then shifting direction in order to succeed. And what makes this redirection possible is adoption of agile principles which enable changes in requirements throughout the project so that failure is not postponed until a late stage at which point accumulated losses have already become too great.

---

Media Query Source: Part 1, Part 2, Part 3, Part 4, Part 5, Part 6, Part 7 , Part 9

Media Query Source: Part 8

---

My responses ended up being included in an article at CIO magazine (September 14, 2017). Extent of quote highlighted in orange. Above image from cited article.

---

The responses I provided to an "anonymous" media outlet series of queries on August 18, 2017: 

Media: When to Abandon an IT Project.

My responses addressed the more detailed questions as follows: 

Media: Why are organizations so reluctant to kill IT projects that are clearly doomed?

 

Gfesser: From my experiences as a consultant, the most common reason organizations can be so reluctant to kill doomed IT projects is because of incurred costs that cannot be recovered. The idea is that a significant cost has already been paid, and one might as well make furthered attempts to succeed so that this initial cost is not all for naught. But the problem with this reasoning is that if the direction of the project is unchanged it will continue to fail, leading to even greater incurred costs.

 

The second most common reason I have seen is that reputations are at stake, and leadership would really like to get the project back on track to some extent so that they don't look incompetent. In all of my years in consulting, I've never seen a project which was significantly behind ever get back on track, but partial success can be met by scaling back the original scope, or moving in a different direction than was originally planned, both avenues of which are enabled my agile methodologies. At the same time, it is important to remember that some leaders define "success" so rigidly as to prevent these alternatives from ever taking place.

 

Media: How can project leaders determine whether it's the project concept or the project execution that's fundamentally at fault in a failing project? 

 

Gfesser: Additional questions to ask here involve inquiring as to how "concept" and "failure" are actually defined, and the stage at which the project started to fail. From the context, "concept" likely refers to either a conceptual description or representation of what the product or output might look like, or what is often called a "proof of concept", although this latter possibility typically takes place after an initial inception phase. Either way, the distinction between these two is important, because a proof of concept might not be viewed by stakeholders as being part of the execution. However, construction of a proof of concept is often a needed step between the inception and the execution, because taking this additional measure can help mitigate risks that might not otherwise materialize until additional costs are incurred.

 

In other words, the question as to whether the project concept or project execution is at fault becomes much less necessary if the team actually takes the time to go through the often needed steps of building one or more proof of concepts followed by a prototype which will serve as the actual foundation for the end product that is to be created. Proof of concepts are often built to make sure that adopted technologies will actually do what is claimed, and once it is determined that this is the case, it makes sense to take the next step of building a prototype, and later an MVP ("minimal viable product") in order to start getting the product in front of stakeholders for the purposes of feedback. Project execution is typically the most difficult part of a project, but taking these steps will help ensure success, and if failure takes place in these early stages it can also be seen as success because you found out what you can't or don't want to build! Going back to my earlier comment, stakeholders need to realize that even a flawed idea can be carried out successfully - but is the end product or output really what stakeholders want?

 

Media: Is there a stage when projects are most likely to fail? 

 

Gfesser: Signs of failure typically appear early in a project if project execution was performed in an agile manner. Failure is not necessarily a bad thing, because it can lead to a more successful product by understanding what doesn't work. One of the benefits of using agile methodologies is to help ensure that the product being built is what the users of the product will actually want to use. If after a series of one or more agile sprints it is determined that the product is going in a wrong direction, the course can be corrected. And in such a scenario, the product owner should actually want project execution to fail so that it can succeed down the road. I've actually never seen a project that failed solely due to choice of product or technology. Failure is almost always due to people or processes, and processes are often comprised of people.

 

As I think about this topic, I still recall a particular project from early in my career that I have used many a time as an example of how not to execute project management. The consulting firm for which we were working at the time had instituted an executive dashboard - every project being executed at the company was displayed on this dashboard so that executives could see projects at risk. My project manager at the time admittedly spent most of his time tweaking the formulas of the spreadsheets being used under the covers until every cell in the dashboard visualizations turned green. Such a project is simply in the wrong hands from the start! Since this particular manager didn't run projects in an agile manner, visibility into accurate status really was not made possible until a later phase when the product started becoming available for stakeholders to see. If these projects had been run in an agile manner, stakeholders would not only have seen from an early phase that failure was taking place, but they could have had an active part in making a course correction! 

 

Media: Are there any specific types of IT projects are more prone to failure? 

Gfesser: Essentially, any projects involving some degree of innovation, or a relatively high level of uncertainty. All projects face some level of uncertainty, and it is projects with high uncertainty that are more prone to failure because not all uncertainty can be addressed. Projects which have been carried out in a similar way in the past, or involve significant repetitive work are less prone to failure, because precedent exists. Projects which are the result of some level of innovation are more prone to failure, because risks are being taken to build something new or in a new manner, and this latter category of projects frequently involve new software development. 

 

Media: What are the warning signs that indicate a project is in trouble? 

 

Gfesser: The warning signs that indicate a given project is "in trouble", rather than "failing" typically include not meeting end user stakeholder needs, and missed deadlines. Again, if a project is being carried out in an agile manner, these signs will be seen early because at the end of every sprint the team evaluates how it executed its work in comparison to what it decided to take on at the beginning of the sprint. In cases where not as much was accomplished, the team will adjust its velocity expectations for future sprints. And in cases where users were not pleased with the incremental delivery at the end of the sprint, the team will incorporate the feedback they receive into the next iteration of work. 

 

Media: What lessons can one learn from a failed project? 

 

Gfesser: The lessons learned from participating on a failed project are innumerable. But in my opinion, the additional thing to keep in mind here is that there are many lessons to be learned from failing early in a project, and then shifting direction in order to succeed. And what makes this redirection possible is adoption of agile principles which enable changes in requirements throughout the project so that failure is not postponed until a late stage at which point accumulated losses have already become too great.

 

---

See all of my responses to media queries here.

Media Query Source: Part 5

---

The responses I provided to an "anonymous" media outlet series of queries on May 12, 2017:

---

My responses ended up being included in an article on "The Enterprisers Project" (June 8, 2017), a collaborative effort between CIO magazine, Harvard Business Review, and Red Hat, alongside 8 others including the CEO of Sencha and CIOs from ServiceNow, Humana, and Adobe. Extent of quote highlighted in orange. Above image from cited article.

---

Media: Change is a constant in IT. How as a leader have you become more comfortable with uncertainty?

Gfesser: Being comfortable with uncertainty is a must in IT. Early in my career, I attempted to eliminate all uncertainty, but came to realize that this goal is unrealistic in most scenarios. Some might recall the Donald Rumsfeld quote that addresses what is known, what is unknown, and the four permutations consisting of known knowns, known unknowns, unknown knowns, and unknown unknowns. Recognizing that these latter two permutations exist but are potentially not discoverable is necessary as an IT leader.

Media: How do you quickly refocus when thrown off course?

Gfesser: I remind myself that working in an agile manner helps enable the ability to steer in a different direction than was otherwise planned. While it is important to understand that planning is important in IT, focus directed toward creating detailed plans that are likely to change tends to lead the creator to think about the sunk costs involved in this type of activity, potentially increasing the likelihood of change resistance.

---

See all of my responses to media queries here.

 

New Book Review: "Leadership Conversations"

New book review for Leadership Conversations: Challenging High Potential Managers to Become Great Leaders, by Alan S. Berson and Richard G. Stieglitz, Jossey-Bass, 2013, reposted here:

The content of this book centers around different types of leadership conversations: to build relationships, to develop others, to make decisions, and to take action. A discussion on management versus leadership begins the text, and a discussion on how the reader might take next steps within the context of personal level within the management and leadership hierarchy ends the text. The content is broken down well into chapters consisting on average less than ten pages each, and comprises some of the most organized content that I have recently seen in business publications.

For my personal consulting career, the following chapters were probably the most appreciated: chapter 4 ("Where Do You Stand on the Leadership Ladder?"), chapter 16 ("Develop Your Judgment Gene"), chapter 18 ("Be Curious - Ask Great Questions"), chapter 21 ("Planning Successful Actions"), chapter 22 ("When Things Change"), and chapter 23 ("Lessons from Success and Failure"). Apart from chapter 4, which falls in the introductory section, the rest of these chapters fall in part 4 ("Conversations to Make Decisions") and part 5 ("Conversations to Take Action") of the text.

In my opinion, the title of this book along with the summaries that I had read prior to acquiring this book are somewhat misleading, which is in agreement with some other reviewers here. Quite simply, there are very few actual examples of dialogue provided. So although there is some good content, the practical aspect of much of this content simply does not stand on its own. If you have read similar books in this genre, and especially if you have some level of management or leadership experience, the content provided by the authors will be much more easily applied, as long as you are willing to dig at the content a bit.

One of the more interesting aspects of this book is that "leader" is seen to be a step up the typical organizational ladder from "manager". My consulting career views these functions differently, with "manager" typically corresponding to title, and "leader" typically corresponding with role. Essentially, what this means is that anyone can be a leader regardless of title. Manager functions can be situational as well depending on consulting assignment, but these are typically reserved for clients, since the bulk of the work is typically performed by leaders, and management functions at the project level are typically not deeply engaged.

Readers should be aware that this book centers around the traditional organizational structures created by consulting firms decades ago, updated for the modern workplace. Chapter 4 explains the "first-line manager", "manager of managers", "executive leader", and "CXO leader" maturity levels for managers and leaders well, synching up each of these levels with the four different types of leadership conversations mentioned previously (building relationships, developing others, making decisions, and taking action). Based on the presentation, my experience falls within the first two maturity levels.

The discussion in chapter 16 expands this earlier discussion to explain how each of these maturity levels tackle what the authors indicate are the six decision-making elements that leaders do well every time: defining the problem, identifying the alternatives, evaluating pros and cons, assessing risks, acquiring resources, and producing results. Within this discussion, the authors argue that from their experience, leaders who consistently make good decisions teach their people to use a structured and repeatable process to make decisions, which might provide a sanity check for readers who work with those who seem to think that this is not the case.

Chapter 23 provides what I consider one of the more important personal take-aways. "Most leadership decisions are made at substantially lower confidence levels. The opportunity cost of gaining near certainty is generally too high compared to the benefits (when lives are not at stake). Ask your team what would be an adequate confidence level, have conversations about the completeness and reliability of the information you have, and then make the decision and take action. Operating in the leadership mindset, let your people figure out the details as they move forward with the actions. Toggling between a leadership mindset and a management mindset in making decisions and trusting people is difficult for some technically minded executives. Yet they must do so to inspire their high potentials into action."

New Book Review: "Team Geek"

New book review forTeam Geek: A Software Developer's Guide to Working Well with Others, by Brian W. Fitzpatrick and Ben Collins-Sussman, O'Reilly, 2012, reposted here:

Arguably the best text on the software development process that focuses on the individual contributor within the context of a team. When I initially discovered this text, I was wary whether it would have anything to offer, and if so, whether it would cater to new development staff or seasoned professionals, but after a reading I am convinced that Fitzpatrick and Collins-Sussman have something to offer regardless of technical career stage, and even offer significant insights to managers who are willing to learn.

After discussing the myth of the genius software developer, the authors present their thoughts on a healthy team culture, followed by discussions on effective team leadership, working with difficult people, using organizational manipulation to get things done effectively, and user engagement. At first glance, the discussion on user engagement might seem out of place, but my consulting experience has shown that this aspect of the software development process is important, and the authors tie it in very well.

The best part of this text is that Fitzpatrick and Collins-Sussman, both at Google at the time of writing this book (they have worked with each other at three jobs, and also written three books together), simply tell it like it is, and offer no fluff. Some of the topics that the authors touch are not really found anywhere else to any significant degree, and I hope that a signficant portion of the software development profession has a chance to read what they have to offer at some point in the near future.

Judging by the number and distribution of dog ears resultant from my reading of this text, the strength of the content is consistent throughout, unlike many other texts in this genre which tend to offer good content up-front, but then taper off over the course of the second half. While the reward for this quality will result in this book sitting alongside the best of the best on my bookshelf, it also adds difficulty to the review process, because I do not have the space for a "The New Yorker" magazine review here, so I offer a few quotes that will hopefully increase potential reader interest.

In Chapter 1 ("The Myth of the Genius Programmer"), the authors recount their speaking engagements over the past six years, and point out the distinctive trend in the types of requests they were getting for Google's open source Project Hosting service, which revolved around hiding specific code branches, hiding new open source projects until they are ready to be seen, and deleting code version history.

"The key motif here is insecurity. People are afraid of others seeing and judging their work in progress. In one sense, it's just a part of human nature - nobody likes to be criticized, especially for things that aren't finished. This attitude tipped us off to a trend within software development. Insecurity is actually the symptom of a larger problem." The resultant discussion then leads to their presentation on the foundation that all healthy interaction and collaboration is based (humility, respect, and trust), and point out the following important maxim: "Don't equate your self-worth with your code quality."

In Chapter 2 ("Building an Awesome Team Culture"), the authors discuss an important aspect that is all too often ignored in books of this genre: team culture. "Calm, easygoing cultures built on respect are more vulnerable to disruption by aggressive people than aggressive cultures are vulnerable to disruption from more easygoing people. Easygoing cultures need to be aware of this and not let the aggressive newcomer take over, typically by refusing to engage this person in an aggressive tone. In some cases, one or more of the more senior team members may have to meet the aggressive newcomer head-on to prevent her from harming an easygoing team culture."

In their discussion of the team leader in Chapter 3 ("Every Boat Needs a Captain"), the authors address risk in their presentation of team leader as catalyst. "Risk is a fascinating thing - most humans are terrible at evaluating risk, and most companies try to avoid risk at all costs. As a result of this, the usual modus operandi is to work conservatively and focus on smaller successes even when taking a bigger risk might mean exponentially greater success."

"One thing we often say at Google is that if you try to achieve an impossible goal, there's a good chance you'll fail, but if you fail trying to achive the impossible, you'll most likely accomplish way more than you would have accomplished had you merely attempted something you knew you could complete. A good way to build a culture where risk taking is accepted is to let your team know it's OK to fail."

Chapter 5 ("The Art of Organizational Manipulation") contains one of the many important take-aways from this book. "As an engineer, try to focus your energies on launching products over just about everything else. Shipping things gives you credibility, reputation, and political capital more than just about anything else in a company. Launching your product is a high-visibility event that shows you've accomplished something."

"As tempting as it might be to spend a ton of time cleaning up your code base and refactoring things, we've learned from experience that if you dedicate more than half of your time to this kind of defensive work, it's hardly valued at all and you'll find yourself in the somewhat embarrassing position of having nothing (politically) important to show for your time. This is not only a good way to get no recognition, but it's also a good way to get your product canceled."

New Book Review: "The Trusted Advisor Fieldbook"

New book review for The Trusted Advisor Fieldbook: A Comprehensive Toolkit for Leading with Trust, by Charles H. Green and Andrea P. Howe, 2011, reposted here:

Almost exactly four years ago today, I wrote the following about the predecessor to this text: "Truly, the content that Maister, Green, and Galford provide in 'The Trusted Advisor' is absolutely brilliant. The only other consulting text that comes to mind which meets the quality of this work is 'The Secrets of Consulting', by Weinberg (see my review). And while 'Secrets' is an incredibly informative and entertaining masterpiece, the three authors who collaborated for this piece have provided a great service to anyone involved with advising other individuals, regardless of profession." What Green and Howe offer with this recent effort follows well in these earlier footsteps. In the words of the authors, this is "a more detailed how-to guide for people in any professional role", and I could not agree more. This book is not a replacement, but a compliment, providing a hands-on approach to developing and maintaining trust-based relationships that will certainly cause me to recommend it to colleagues.

The material that the authors present is broken down into five parts: Part 1 ("A Trust Primer"), Part 2 ("Developing Your Trust Skill Set"), Part 3 ("Developing Business with Trust"), Part 4 ("Managing Relationships with Trust"), and Part 5 ("Building and Running a Trustworthy Organization"). These parts are broken down into 31 chapters, each typically containing just a few pages, which greatly helped my digestion of the content as well as my focus on specific areas of trust. In addition, the conclusions of each of the chapters provide truly thought-provoking worksheets that challenged me during my reading and will continue to challenge me, as I expect to revisit these worksheets in the future as I grow as a professional. And one of the specific aspects about this book that I appreciated, as with "The Trusted Advisor", is all the lists throughout the book (164 in total, more than a 5-fold increase from the earlier effort!) that are also contained in a comprehensive appendix.

As a consultant, chapter personal favorites include Chapter 1 ("Fundamental Truths"), Chapter 3 ("The Dynamics of Influence"), Chapter 4 ("Three Trust Models"), Chapter 6 ("Listen"), Chapter 7 ("Partner"), Chapter 8 ("Improvise"), Chapter 9 ("Risk"), Chapter 15 ("Talking Price"), Chapter 21 ("Accelerating Trust"), Chapter 23 ("Shifting from Tactics to Strategy"), Chapter 24 ("My Client is a Jerk: Transforming Relationships Gone Bad"), and Chapter 25 ("Dealing with Untrustworthy People"). Based on my experience, all professionals will find valuable what the authors present within the chapters of Part 2. While many other texts address the fact that self-knowledge is essential, if any potential readers of this book do not have time to read everything that the authors have to share, the other chapters within this portion of the book (on listening, partnering, improvising, and risk-taking) should be considered required reading for everyone who works with clients to any degree.

The "Trust Equation", Trust = (Credibility + Reliability + Intimacy) / Self-Orientation, or T = (C + R + I) / S, is revisited and expanded upon by the authors alongside two other trust models in Chapter 4, resulting in one of the best discussions in the text. "Self-orientation, which we like to call your 'S', rears its ugly head most often when you feel some sort of fear: fear of looking bad, fear of rejection, fear of loss. All of these fears are perfectly normal. And they are what makes your S look big. What makes a difference is having the ego strength to see the fear, acknowledge it, 'get off your S', and move on. After all, obsessing about Big S mistakes is just more Big S." Following this discussion, "The Trust Creation Process", a five-step model (engage, listen, frame, envision, and commit) in which the authors stress order, is presented, followed by "The Trust Principles" that include a focus on the other, a collaborative approach, a medium-to-long-term perspective, and a habit of being transparent.

As the authors explain, "being or becoming trustworthy cannot be reduced to pure behaviors. Your actions are driven by your beliefs, and your beliefs are driven by your values or principles. Trustworthy behavior is far too complex to fake without beliefs and values behind it. If your values don't drive you to behave in a trustworthy manner all the time, you will be found out quickly. Hence, the trust equation and the way you use the trust creation process are really just outcomes of the principles you hold, the trust principles. The way to become trusted is to act consistently from those principles." And later, the authors introduce a refrain that is common throughout the rest of the text, especially echoing throughout part 3, which personally brought to mind the negative repurcussions an ABC (always be closing) mindset made famous by Alec Baldwin in Glengarry Glen Ross is likely to bring: "Focusing on relationships nurtures transactions, whereas focusing on transactions chokes off relationships."

New Book Review: "Influence"

New book review for Influence: Science and Practice, by Robert B. Cialdini, Pearson Education, 2009, reposted here:

The quote by Tom Peters on the cover of the fifth edition is what helped compel me to purchase this text: "If everything were on the line in a negotiation, I can't think of anyone I'd rather have advising me than Bob Cialdini." A colleague of mine noted after the fact that this book recently appeared on a top-20 list of leadership books to read this year, but I have read my share of leadership texts, so what interested me was its apparent focus on negotiation. To some extent, this book is faintly reminiscent of an audio tape called "The Psychology of Selling" by Brian Tracy that a former colleague of mine recommended early in my career, because the focus here is looking at the factors that cause individuals to say "yes", and the techniques that most effectively use these factors to bring about such a decision.

This book is organized around the 6 psychological principles that direct human behavior and give these techniques their power: reciprocation, consistency, social proof, liking, authority, and scarcity. Although this book may have been written to engage the popular reader, the conclusions that the author, a psychology professor at Arizona State University, reaches are based on controlled, psychological research. As Cialdini entertainingly walks the reader through what he learned during his 3-year period of participant observation that served as input to this book, in my opinion although he is both successful at instruction as well as keeping the reader engaged, as with many texts the reader will need to extrapolate in order to apply personally, especially if what is sought is application to the workplace.

Judging by the location of dog ears that were left behind after my reading of this text, the portions I especially appreciated are the first chapter, "Weapons of Influence", the last chapter, "Instant Influence: Primitive Consent for an Automatic Age", and the many sidebars throughout the body of what the author provides called "Reader's Reports". In fact, it turns out that the author has found that the "Readers's Reports" are one of the most popular aspects among readers, and in my opinion these are similar to the "Letters to the Editor" one might find in a newspaper or magazine: people writing in to the author to share how the principles and techniques that are presented in this text have been encountered in the real world. Fascinating lessons learned rooted in science. Recommended reading.

New Book Review: "Diagnosing and Changing Organizational Culture"

New book review for Diagnosing and Changing Organizational Culture: Based on the Competing Values Framework (Third Edition), by Kim S. Cameron and Robert E. Quinn, Jossey-Bass, 2011, reposted here:

In the introduction to this book, the authors share the familiar Tom Peters quote, "If you're not confused, you're not paying attention", because the purpose here is "not to offer one more panacea for coping with our turbulent times or to introduce another management fad." In the words of the authors, this book "provides a framework, a sense-making tool, a set of systematic steps, and a methodology for helping managers and their organizations adapt to the demands of the environment. It focuses less on the right answers than it does on the methods and mechanisms available to help managers change the most fundamental elements of their organizations" at the cultural level.

While the authors also state that other proposed approaches to measuring organizational culture have been proposed, and that their intent is not to provide an extensive review of this literature, they also provide what I consider important background information to the Organizational Culture Assessment Instrument (OCAI), which includes the facts that the OCAI (based on the Competing Values Framework) is probably the most frequently used instrument for assessing organizational culture in the world today, and that although some versions are longer, some including up to 24 items that together describe organizational culture, the 6 items that are used in this book provide a simpler synthesis that addresses fundamental manifestations of organizational culture.

After walking through the OCAI current profile worksheet, which addresses basic assumptions (dominant characteristics, organizational glue), interaction patterns (leadership, management of employees), and organizational direction (strategic emphasis, criteria of success) that typify the fundamentals of culture, the authors present the two major dimensions organized into four main clusters that define organizational effectiveness. The first dimension differentiates effectiveness criteria that emphasize flexibility, discretion, and dynamism from criteria that emphasize stability, order, and control. The second dimension differentiates effectiveness criteria that emphasize an internal orientation, integration, and unity from criteria that emphasize an external orientation, differentiation, and rivalry.

These four main clusters can be visualized as the Clan, Adhocracy, Hierarchy, and Market quadrants of a graph. Because these quadrant names were derived from the scholarly literature, the authors also conveniently provide counterpart names to which they think business executives and other nonacademic audiences might better relate (Collaborate, Create, Control, Compete). The authors note that while designed to assess organizational culture, these clusters can also be used to assess leadership roles, organizational effectiveness, and management roles, and provide several examples that demonstrate applicability to these other areas. In chapter 6 and Appendix B, the authors even provide an extension to the Competing Values Framework based on the Management Skills Assessment Instrument (MSAI) to address the personal behavior change on which a change in organizational culture depends.

In my opinion, the nine managerial competencies addressed for management across the four quadrants are more tangible (Clan = managing teams, managing interpersonal relationships, managing the development of others, Adhocracy = managing innovation, managing the future, managing continuous improvement, Hierarchy = managing acculturation, managing the control system, managing coordination, Market = managing competitiveness, energizing employees, managing customer service), although while the authors present at length the fact that the four quadrants for organizational culture depend on a "Means-Does Not Mean" analysis to be completed by stakeholders in order to determine what chosen future state organizational culture actually means in a relative sense, this analysis is not provided in the context of managerial competencies directly since these are intended to lead to the desired future state organizational culture.

Overall, however, Cameron and Quinn present the process to diagnose organizational culture extremely well, and they do note repeatedly, as can be expected, that it is not possible to present a cookie-cutter approach because of the continuum nature of culture. From the perspective of a consultant, I especially appreciate the many examples that the authors provide that demonstrate example company profiles and shifts in company culture over time. The average culture profiles for various industry groups that the authors present are also well received, although it is important for potential readers of this book to realize that the categorizations for these groups are very broad.

For example, consulting services might technically fall under the "services" group, which obviously encompasses a wide spectrum of companies, although in such a case it might be beneficial to look at cultural profiles of client industry groups. As a consultant in the software industry, I could not help but notice that this book ties in well with a book I read several years ago entitled "Balancing Agility and Discipline: A Guide for the Perplexed", by Barry Boehm and Richard Turner. While that text is narrowly focused on choosing a software development methodology, a culture dimension of plots reminiscent of those seen in the book under review here can be seen as output from what Cameron and Quinn provide.

Interestingly enough, while the term "changing" sits alongside "diagnosing" in the title of this work, it is really not until Appendix C and Appendix D that the former is addressed with any substance. It is actually understandable why this is the case - change is multifaceted and covered by numerous other titles - but I would personally like to see the authors expand on these appendixes in another book, because the content provides hints for initiating organizational culture change and improving personal management competencies that specifically address the quadrants discussed in the book. Well written and focused business text recommended to anyone seeking understanding of organizational culture or personal management competencies as they relate to their own situations or to situations of customers and clients.

New Book Review: "The Servant"

New book review for The Servant: A Simple Story About the True Essence of Leadership, by James C. Hunter, Prima, 1998, reposted here:

Recently recommended by the instructor of a University of Illinois leadership training course my colleagues and I attended, this book is one of the best leadership texts I have read during my career. Although readers may be initially drawn to this text for the lessons in leadership it provides for the business world, what Hunter presents here is intended to be holistic, covering relationships both inside and outside the workplace. In the words of the author, at the time of writing a general manager of a large manufacturing facility, his life was falling apart at home and work, and after discussions with his wife and reluctant talks with his pastor, ended up spending a week at a monastery in northwestern Michigan "to sort things out". While financially successful, his wife made it clear there were issues with the dynamics between he and his family, and his human resources manager suggested  that he take a look at his leadership style after employees campaigned for union representation.

In sharing his experience at the monastery, Hunter tells a good story and masterfully weaves in the principles he learns discussing leadership with several other individuals, including the former CEO of an airline turned monk who led the discussions, a drill sergeant, a public school principal, and a women's basketball coach. The teacher first discusses the differences between leadership and management, and power and authority, and then presents the pyramid style of management paradigm and how it came to be so popular in the United States, followed by Maslow's hierarchy of human needs with which many readers will already be familiar, and the servant leadership model which he discusses one element at a time and that serves as the focal point throughout the remainder of the book. The simple explanations of sometimes weighty topics, classroom dynamics between individuals of varied backgrounds, and author vulnerability are what makes this book work. The ninety other consistently positive reviews here that stretch over a ten-year period are a testament to the effectiveness of what Hunter, at the time of publication a consultant at a labor relations and training consulting firm, has to share with readers in this quick, but engaging text.

Past Book Review (November 16, 2008): "Medical Errors and Medical Narcissism"

Past book review (i.e. posted prior to starting this blog) for Medical Errors and Medical Narcissism, by John D. Banja, Jones & Bartlett Learning, 2005, reposted here:

 

Published almost four years ago at the time of this review, it is rather interesting that other readers have not yet shared their thoughts about this book. Quite simply, this is an extremely well written, well organized text, and the subject matter is relevant to a large segment of society. Health care touches almost everyone, and understanding the mind of the health care worker, especially the physician, is important when assessing medical errors. According to author Banja, Associate Professor in the Center for Ethics at Emory University, behavior that he refers to as "medical narcissism" can have a profound influence on how the physician reacts to occurrences of such errors. Before Banja discusses narcissism in health care, he first explains error and rationalization, and follows the discussion of narcissism with chapters on forgiveness, remedies, and empathic disclosure.

The author indicates that "it is important to note that the variance, departure, or straying from the standard of care that is presently being offered as a definition of error must be morally problematic, or uncomprehending, or unintended by the actor. Simply calling an error 'a failure to accommodate the standard of care' would imply that medicine could not have progressed since Hippocrates without its practitioners making 'errors', which seems intuitively wrong. The failure to follow the standard of care, then, must be unwarranted and, overwhelmingly, the errors discussed in this book are just so". And "it is grossly unfair to hold health professionals to a standard of competence that defines 'error' in a way that exceeds ordinary and reasonable levels of performance. Because imputing error can have onerous repercussions, health professionals and especially risk managers must insist on a coherent understanding of error and resist imprecise definitions that could confuse or compromise hospital policy on patient safety and managing adverse outcomes. Consequently, the definition of error that will be used throughout this book is: 'An error is an unwarranted failure of action or judgment to accommodate the standard of care'."

Following his discussion of medical errors, Banja then takes a look at how such errors are handled, providing many examples of such scenarios, which suggest "a temporally tight juxtaposition of immense anxiety and concern for the patient's welfare, followed closely or even simultaneously by the provider's intense anxiety about his or her own welfare. The lock-step nature of these dual anxieties is key". As the author continues with his presentation, he indicates that it is unfortunate that there is no national consensus (i.e. within the United States) that dictates how such errors need to be communicated to affected parties. According to cited studies, what is often the case is that information associated with such errors is withheld, and in one study where disclosure practices of over 200 hospitals were examined, the conclusion was that only 10% to 20% of serious, preventable, iatrogenic harms that occurred to patients were disclosed. What is often the case, according to surveys of physicians, is that harm-causing medical errors are often rationalized.

One of the most interesting portions of the text is the discussion on the origins of medical narcissist characteristics (emotional disengagement, ideological rigidity, and compulsiveness), which often start in childhood and are later reinforced during medical training. And the author's later secular discussion of forgiveness is superb. While Banja indicates that there is no consensual definition of forgiveness, a very compelling presentation is presented of what true forgiveness might look like from psychological and moral perspectives, beginning with a quote which reads as follows: "What is annulled in the act of forgiveness is not the crime itself but the distorting effect that this wrong has upon one's relations with the wrongdoer and perhaps with others". The cognitive-emotive-behavioral triad that the author presents is powerful. Forgiveness for the forgiver from each of these, respectively, might be: "I will stop thinking about the offense", "I will cease to feel anger and hatred toward the offender", and "I will not seek revenge"; forgiveness for the forgiven might be, respectively: "I will acknowledge and admit my wrongdoing", "I will feel and express sorrow for what I did", and "I will desist from committing that wrong again and make amends".

The stumbling block for the medical narcissist, however, is that forgiveness "requires a humbling of the self and a relinquishment (at least temporarily) of grandiosity". Considering the lengthy discussion on errors and how errors are handled, this book would not be complete without the chapter on remedies, which includes sections on tort reform, the blameless and nonpunitive environment, and mindfulness. And the following chapter discusses the empathic disclosure of medical error, how errors arguably should be handled. Within the closing pages, the author indicates that he "wrote this book with a particular kind of health professional in mind. He or she is one who believes it is immensely important to: (1) maintain a professional distance or guardedness with patients that largely precludes empathically reacting to their anxiety or suffering, (2) appear utterly competent always, (3) understand and ground that competence in scientific method and a densely clinical vocabulary, (4) never admit ignorance, hesitation, or error, (5) direct and control the conversation with patients always, and (6) use the power of his or her white coat to direct how the patient should behave and feel".

New Book Review: "Your Brain and Business"

New book review for Your Brain and Business: The Neuroscience of Great Leaders, by Srinivasan S. Pillay, FT Press, 2011, reposted here:

It is apparent that one has a controversial text on their hands when some reviewers assign the label "too scientific", and some reviewers assign the label "pseudoscientific". Reading through the other reviews here, if I had not recently read this book myself I might be hard-pressed to find any answers to what the author provides in his discussion, and rather than make a decision to read this book based on facts, give up trying due to lack of information.

According to Pillay, "at the end of this book, the coach or executive will have a good idea of several concepts in brain science that can be applied to his or her own coaching relationships and interventions so as to add to the available tools for coaching." The author later elaborates by noting that "these interventions are a reframing of conventional  coaching methodologies but they also add new insights. At a time when leaders are tiring of old concepts and are therefore not receptive to them, this reframing can be very helpful in informing the appropriate coaching, management, or leadership plan."

The author explains his view that there are 6 basic ways in which brain science can enhance understanding within the executive environment: repackaging advice with biological explanations rather than psychological jargon, decreasing threats by depersonalizing explanations of behavior, debunking myths when brain science provides a different explanation than personal or organizational psychology, providing further insights and evidence beyond what has been traditionally provided in the past, providing a system for targeted interventions, and developing coaching protocols and tools.

On several occasions throughout the text, the author mentions that since research is an ongoing effort, although the explanations he provides are based on current research, some of the brain science addressed here is bound to change. Many of the insights Pillay provides are based on functional brain imaging, which examines how the brain works when it is presented with a task or challenge as a given individual lies inside an MRI scanner. As the author explains, functional magnetic resonance imaging (fMRI), which measures brain blood flow as a correlate of brain cell (neuronal) activity, is the technological focus.

In my opinion, "Your Brain and Business" is one of the most creative business texts I have read in quite some time, and there are a number of passages that I plan to revisit. However, the number and location of dog ears created while reading this text reminds me that some of my interest waned for the last two chapters. Some of the material presented in this latter section would have best been presented earlier in the text, since some of it would have been helpful as the author provided the groundwork of his presentation, and some of it unfortunately is a bit repetitive.

That said, several takeaways especially resonated with me as a consultant and an individual outside the workplace. The amygdala, which is found deep inside the brain and lights up when presented with something fearful, picks up fear signals unconsciously without the conscious brain knowing anything about it. The conscious brain requires at least 30 milliseconds to register images, for example, but the unconscious emotional processor can be actively engaged even if negative office chatter or radio talk shows are in the background and not being paid attention.

The second such aspect that especially resonated with me is the discussion on optimism that the author provides. As the author explains, "when people hear the word 'optimism', they roll their eyes. In this economy, with the difficulties of balancing home and work life and making ends meet, just the idea of optimism seems tiring to most. Many business leaders are practical, and they believe that optimism is for the birds." Current research, however, demonstrates that "optimism builds the brain's connections differently than realism and provides relief from a burning, red-hot amygdala."

The third, in chapter 5 ("The Challenge Prior to Change: How Brain Science Can Bring Managers and Leaders from Idea to Action Orientation"), is that regardless of the emphasis many business people place on removing feeling or emotion from decision making, the brain's accountant (the ventromedial prefrontal cortex) is missing vital information if these are left out. The accountant determines the level of action required for a situation by examining risk and reward value, but these are in turn assessed by short-term memory, long-term memory, as well as by emotion.

In my experience as a consultant, it is clear that if one is to use the material provided in this book in some manner within the workplace as discussed by the author, it will need to be tailored to the individual just like any other mechanism. While some may prefer biological explanations over the psychological, there are others who prefer the psychological, and some of course will not respond to either or prefer other alternate explanations when it comes to coaching.

However, if the reader does not get too distracted by the abundance of brain terminology, and they are looking for material on these topics, my expecation is that many will find something to add to their daily toolboxes, counterparts to tools such as those discussed in books like "More Secrets of Consulting: The Consultant's Tool Kit" by Gerald M. Weinberg (see my review). Well recommended to anyone looking for explanatory balance on these topics to aid them both in their careers and in their lives outside the workplace.

New Book Review: "Rules to Break & Laws to Follow"

New book review for Rules to Break & Laws to Follow: How Your Business Can Beat the Crisis of Short-Termism (Microsoft Executive Leadership Series), by Don Peppers & Martha Rogers, PhD, John Wiley & Sons, 2008, reposted here:

 

Purchase of this text by this reviewer followed on the tails of "The Strategy Paradox: Why Committing to Success Leads to Failure (and What to Do About It)" by Michael E. Raynor (see my review) and "Strategy Safari: A Guided Tour through the Wilds of Strategic Management" by Henry Mintzberg, Bruce Ahlstrand, and Joseph Lampel (see my review). While initial interest in this work by Peppers and Rogers was due to its seeming focus on the strategic versus the tactical, however, potential readers should note that the authors instead investigate and present general principles that any firm should follow.

At the outset, this text does not beat around the bush. For example, in the first chapter the authors respond to the following first three rules to break by writing "No, no, no. No to all the above. These Rules to Break are really just assumptions about how business works, at the most basic level. They probably aren't written down anywhere in your strategy document, but they have almost certainly backed up your thinking and your company's actions for as long as you remember.": (1) "the best measure of success for your business is current sales and profit, (2) "with the right sales and marketing effort, you can always get more customers", and (3) "company value is created by offering differentiated products and services".

The authors further this instruction by pointing out that all of these assumptions are wrong. "If you operate according to these false assumptions, not only will your business fail to create much value, but you'll also soon find yourself trapped in a Crisis of Short-Termism. Everything you do will be so furiously centered on making today's numbers that you will become increasingly blinded to everything else. Business swept up by this crisis find that even as they try to do the right thing for their shareholders, they end up destroying value rather than creating it. So while these Rules to Break may look no more dangerous than ordinary common sense, in truth they're deadly."

According to the authors, executives need to change their mental models of what it means to succeed. The new model that Peppers and Rogers is based on the understanding that long-term business success relies on customer success as a prerequisite, and that employee trust of their employer precedes employee drive to earn customer trust. Interestingly, even though new technologies are presented as making possible sophisticated analytics, subverting the power of hierarchies, connecting consumers electronically, and undermining the advantages of new products, the authors state that it is customer trust that will provide a guideline for action even if financial metrics are not yet at the needed level of sophistication.

In the opinion of this reviewer, the third chapter entitled "Customers Are a Scarce Resource" is one of the best in the book, and if the potential reader does not have enough time to read all the chapters, they need to read this one. In this chapter, the concept of customer lifetime value (LTV) is discussed. "New customer acquisition has always been the quintessential goal of traditional marketing and is something often trumpeted to shareholders. But raising your customers' lifetime values is just as important, because over and above whatever profit you are earning currently, increasing your customers' LTVs increases the value of your business."

The authors continue by stating that the philosophy of some businesses is "based on the belief that as long as its sales and marketing effort is effective, it can always acquire more customers from somewhere. But this is a false assumption - a Rule to Break. Instead, to make the right decisions as a business, you must always take into consideration the population of customers and prospective customers truly available to you. After considering the whole population of customers and prospects, your job is to employ that population to create the most possible value for your firm. Because customers are scarcer than other resources, using up customers is more costly than using up other resources."

The fifth chapter was also especially enjoyed by this reviewer, where in discussing how to increase the value of one's business the authors present the concepts of "customer equity" and "Return on Customer" (ROC) that follow a discussion of ROI. The examples and accompanying tables in the third and fifth chapters are very well done. The thoughts that the authors share on innovation in the tenth and eleventh chapters were also appreciated, where the production of new ideas is said to be more important than making money from every new idea, and where the need to differentiate between "wise failures" and "fiasco failures" is said to be an important distinction, reminding this reviewer of a quote by James Cameron, who was recently quoted as saying "If you set your goals ridiculously high and it's a failure, you will fail above everyone else's success".

Global Leadership Summit 2010 Day 2:Jeff Manion

From the conference notes:

Known for his dynamic teaching skills and passion for communicating scripture in a clear and relevant way, Jeff Manion has served as teaching pastor of Ada Bible Church for over 25 years.

Under Jeff's leadership, the church has grown from 50 people to over 6,000 attenders. In 2009, Ada Bible was listed by Outreach Magazine as one of America's largest and fastest growing churches.

A vibrant and growing ministry in West Michigan, Ada Bible uses video venues and two offsite campuses to create a small church feeling within a large church setting.

---

From my personal notes:

• The phrase "for now" is the language of the "the land between" - like a recent college graduate experiencing the temporary phase that exists between school life and a career where they are living at home "for now" - but this "land between" applies to more than just recent college graduates.
• Manion pointed to a map of the Holy Land where "you are here" was marked in the wilderness between Egypt and what was to become Israel - a barren place between two areas of green.
• The Israelites were promised delivery from Egypt to Canaan, but they ended up in "the land beween".
• "The land between is fertile soil" for complaint.
• It might be easier to empathize if we were amongst the Israelites.
• "The land between is fertile ground for complaint - and meltdown."
• We are naive to think that we are immune from correction.
• "The land between is fertile soil for transformational growth."
• "Time does not heal all wounds."
• "The wilderness is also the place we go to die - we have to choose."
• "Complaint arrives as an uninvited guest."
• "Complaints resist eviction."
• "Inviting another guest in the house - trust - evicts complaint."

Global Leadership Summit 2010 Day 1:Andy Stanley

From the conference notes:

Under the leadership of Andy Stanley, North Point Community Church in Alpharetta, Georgia, has become one of the largest and most influential churches in the United States.

Founded in 1995, the church has grown to three campuses and a weekly attendance of more than 28,000 people. North Point has also helped to plant more than 20 strategic partner churches across North America.

Stanley is a sought-after speaker and leadership mentor with a special passion for raising up the next generation of leaders. He has authored a number of best-selling books including The Principle of the Path, Visioneering, Next Generation Leader, Communicating for a Change, and the soon to be released, The Grace of God.

---

From my personal notes:

• It's a myth that great leaders will solve all their problems, and that reoccurring problems means that they lack leadership.
• Problems and tensions in your organization help as a growth engine.
• Every organization has problems that shouldn't be solved.
• We need to start thinking about the differences between solving problems and resolving tensions, and managing tensions.
• Resolving tensions will bring other tensions
• Resolving tensions create barriers to progress.
• "Problems" that reoccur are actually tensions to manage.
• Our role as leaders is to leverage these tensions.
• We need to (1) identify tensions, and (2) create the terminology around this dynamic.
• Key players should understand this twofold need.
• Value needs to be granted to both sides.
• Don't weigh-in to heavily based on personal biases.
• Don't allow strong personalities to win the day.
• Don't think in terms of balance - think in terms of rhythm.
• Don't think in terms of "balance" or "fairness", which technically do not exist.
• Understand the upside of the opposite side.
• Understand the downside of your side.
• Being able to argue both sides is important.
• You need 2 types of people as a leader: (1) passionate people, and (2) mature people.
• Remember that different things are needed over time during the life cycle of the organization.