Erik on Software

Community Comment: Part 20

The comments I provided in reaction to a community discussion thread:
https://www.linkedin.com/feed/update/urn:li:activity:6943599797895348225?commentUrn=urn%3Ali%3Acomment%3A%28activity%3A6943599797895348225%2C6943916394010869760%29

Senior Principal Engineer at Food Delivery Firm:

Too many companies delusionally looking for that 10x engineer instead of 10x-ing interactions inside the teams.

Gfesser: Be careful to handle this philosophy with care. Increased interaction within a team isn't inherently beneficial. I've been on many teams, and some have the need for excessive interaction due to poorly planned team organization that doesn't reflect how a given product has been built out. As a longtime consultant who has typically built new products for clients, I have only seen this issue on legacy teams about to be restructured or replaced by modernization or transformation efforts by my teams and I. "Yes" to beneficial interaction only.

Community Comment: Part 19

The comments I provided in reaction to a community discussion thread:
https://www.linkedin.com/feed/update/urn:li:activity:6926625786309316608?commentUrn=urn%3Ali%3Acomment%3A%28activity%3A6926625786309316608%2C6926689203154018305%29

CEO at ELT platform firm:

Do you think your data team is special?
It’s not.
You take one of two approaches.

Strategy 1. Invest in people in service of open source software.
Strategy 2. Invest in SaaS software in service of people.
Your approach directly determines who you hire, how you spend money, and which technologies you use.

Let me outline the two approaches in more detail.

Approach 1.
Teams that invest in people in service of open source software.
This is common in a handful of situations:
- When data teams are born out of engineering teams.
- Data teams within particular industry verticals - like healthcare and financial services.
- Very large enterprises (i.e. the Fortune 500).
- Non-US companies (where SaaS software for data management is less accessible).
These teams invest heavily in headcount.
The biggest line item for the data team will be engineering talent on staff.

Approach 2.
Teams that invest in SaaS software in service of people.
This is common in a handful of scenarios:
- When data teams are built out under a business function.
- Data teams within high-growth industries, with lighter weight procurement processes (eCommerce, marketing, etc.).
- Mid-market companies with lean teams.
- US-based companies.
These teams invest heavily in SaaS software.
As a result, budgets are more evenly split between headcount (typically very lean teams) and SaaS software.

How can you tell which type of team you’re building?
There are two easy tests:
1. When you see a problem and need a solution, do you first try to build in-house? Or do you first try to find a SaaS solution?
2. Is your team primarily budgeting for headcount or software?

I only came to this realization after I started selling to data teams.
Why?
As a vendor in the data world, you start by thinking all data teams are the same.
At [ELT platform firm], we’re a SaaS solution.
We’ve realized we’re not a good fit for teams that invest in people in service of open source software.
The idea of leveraging a SaaS solution goes against the culture, the procurement methodology, and the architecture of those companies.
Have other vendors arrived at the same realization?

For those people in analytics.
Which type of data team are you building?

Gfesser: Interesting thoughts. In the context of your argument, I would typically call strategy #1 "invest in people in service of custom development" because the opposite of buying software is building software, and making use of open source tech is one of the options for construction. Tech savvy firms will obviously make heavy use of open source tech. But there is something else to consider that I often see missing in discussions such as this: buying commercialized open source. In other words, commercial software which has been built on open source. AWS and GCP, for example, provide quite a few examples of such offerings. But I don't think the quantities of talent for these two strategies are at opposite ends of a spectrum.

Media Query Source: Part 31

The responses I provided to an "anonymous" media outlet series of queries on December 16, 2020:

Media: We are looking for the top reasons for why your MVP may fail or succeed.

 

Gfesser: The top reason for MVP (minimum viable product) success or failure revolves around its very definition. Has consensus been reached amongst stakeholders? Does this consensus include approaching what is to be built like a product? Is the product to be built both viable and minimal? If the answers to these three questions can accurately be communicated as "yes" for a given MVP, it is likely headed in the right direction. If not, the question needs to be raised as to why stakeholders are referring to what is to be built as an "MVP". 

An itemized product backlog first needs to be built. A product backlog essentially defines the product, as it is a list of what is needed to improve the product over time. Products have lifespans, and a product backlog lists the priority order in which each improvement is to be built. When an MVP is defined, it is defined with a subset of these improvements, focusing on what will be minimally needed to get it in front of end customers to start eliciting feedback.

 

However, stakeholders need to understand that while getting feedback is a goal en route to building, deploying, and releasing an MVP, end customers typically do not have visibility to the supporting infrastructure and software beyond the user interface. As such, stakeholders need to understand considerations for longer term viability, making tradeoffs with the builders along the way.

 

Yes, what is built for an MVP can technically be replaced following release, but doing so needs to be carefully considered, especially in cases where the supporting infrastructure, software, and data behind the user interface can be seen as the primary product, as the initial user interface only implements a small number of use cases and the flexibility of the platform is paramount. Certainly, such is the case when application or data platforms are built, as these are intended to subsequently support additional use cases.

 

Lastly, it is beneficial for the team building an MVP to be dedicated to the product and free of dependencies on other groups or individuals, to be cross-functional, and to work in an agile manner. Teams exhibiting these qualities will be self-sufficient and flexible as the buildout takes place. In addition to stakeholder lack of consensus and not approaching the MVP as a product, these are among the common reasons I have seen either failure or extreme challenge.

 

---

See all of my responses to media queries here.

Media Query Source: Part 29

---

My responses ended up being included in an article at CMSWire (May 11, 2018) entitled "Change Management for Digital Transformation". Above image from cited article.

---

(No transcript available for the verbal responses I provided to an "anonymous" media outlet series of queries on May 2, 2018.)

---

See all of my responses to media queries here.

New Book Review: Disruptive Analytics

New book review for Disruptive Analytics: Charting Your Strategy for Next-Generation Business Analytics, by Thomas W. Dinsmore, Apress, 2016:

The author mentions at the outset that analytics industry leaders have been struggling, for reasons apparently not associated with product quality, but with disruption. Powerful forces are rearranging the industry: rapidly declining storage costs, an exploding number of data sources, decentralized data ownership, the open source software business model, the elastic business model made possible by cloud computing, widely available and inexpensive computing power, and displacement of conventional data warehousing and commercial analytic software by the Hadoop ecosystem, Python and R.

This book discusses two types of disruption: disruptive innovation within the analytics value chain, and industry disruption by innovations in analytics. From the perspective of startups and analytics practitioners, success is enabled by disrupting their industries, because using analytics to differentiate a product is a way to create a disruptive business model or to create new markets. From the perspective of investing in analytics technology for their organizations, taking a wait-and-see approach might make sense because technologies at risk of disruption are risky investments due to abbreviated useful lifespans.

After an initial walk-through of disruptive analytics innovation, and the analytics value chain, Dinsmore takes a step back to present a short history of the last 50 years of innovation in analytics, followed by discussions on the open source business model, the Hadoop ecosystem, the rapidly declining cost of computer memory and the corresponding rise of large-scale in-memory computing, a survey of streaming analytics, cloud computing and the elastic business model, recent innovations in machine learning (ML), self-service analytics, and a self-described "manager's handbook for disruptive analytics".

Chapters 2 and 3 on the history of analytics and open source analytics are especially well done, and key for anyone not familiar with these areas. As a consultant in this space who began their programming career with SPSS, I recall a diagram that someone posted this past year, a bit of a spin on the theoretical evolutionary chain of humans, albeit beginning with SPSS, with subsequent stages of SAS, R, and Python. In a similar manner, the author walks through the themes characterizing analytics in the years prior to the introduction of the first data warehouse in 1984, the data warehouse era, and key trends today.

As explained in the summary to chapter 2, much is to be learned from a review of the history of modern analytics. "Statistics, machine learning, and data mining technologies developed separately from data warehousing and business intelligence technology. While data warehousing theorists argued that data mining 'belonged' in the data warehouse, and leading database vendors delivered 'in-database' data mining, actual users disagreed with the theorists. On the whole, they preferred separate tools based on servers or desktops, which had much richer functionality than the 'in-database' data mining tools."

"The vision of the enterprise data warehouse as the single source of truth was never realized, even at the peak of the hype cycle. No large organization ever successfully integrated all of its data into a single centralized repository. If the vision of a unified enterprise data warehouse was unattainable in the 1990s, it is certainly unattainable today. There is simply too much data, the data is too diverse, and it moves too fast. The enterprise data warehouse idea may be dead, but the data warehouses themselves will survive, like cathedrals in modern cities."

"Organizations that built them will not decommission them, and some may build anew. Every organization needs to measure its performance, and data warehouses are very good at providing broad access to consistent transactional metrics. But performance measurement isn't disruptive, and it isn't strategic. It is simply a cost of doing business, like pencils and office space. Consequently, the executives who manage data warehouses will be under constant pressure to deliver metrics at the lowest possible cost." And "meanwhile, the most interesting, strategic, and disruptive analytics will be built outside the scope of the data warehouse."

While this book itself could be considered disruptive from the perspective of the field of available texts on this subject matter, as very few exist, it is also important to consider the fact that this book was published in 2016, and the field continues to evolve quickly, demanding a desperately needed update when it comes to specific technologies covered in chapters 3 through 9, keeping in mind there are only 10 chapters. Experienced consultants in this space will not have a hard time finding numerous examples of where this is the case, but as this book arguably targets managers it is important that this aspect be pointed out.

In addition to refreshing this text from the perspective of cited technologies, I would also like to see the author spin off an entirely separate book from the last chapter, labeled "handbook for managers: how to profit from disruption". As someone who just built a data analytics platform with his team this past year, I know how challenging it can be to hire data professionals, so I would especially like to see Dinsmore expand on his "hire the right people" section of this chapter. And as a longtime agile practitioner and open source advocate, I would like to see expansions of the "develop a lean data strategy" and "build an open source stack" sections.

New Book Review: Rethinking Strategy

New book review for Rethinking Strategy, by Steve Tighe, Wiley, 2019:

Copy provided by author Steve Tighe.

The author mentions in his introduction that he feels this is the book he needed to read on his first day as foresight manager at Foster's. "As I sat at my desk on the first day in my new role I still clearly remember the feeling of being overwhelmed by the complexity of the task. Indeed, the one clear thought I had at the time was where do I start? The future appeared to me a vast, uncertain and unknowable black hole, seemingly awash with infinite possibilities. What was important? What was insignificant? And how would I know the difference? These were the questions running through my mind as I sat paralyzed at my desk surrounded by colleagues purposefully going about their roles.

"The difference, of course, was that my workmates fulfilled roles where the patterns of expectation and performance were well established. I, on the other hand, had seemingly stepped into the unknown. Such a role had not previously existed at Foster's, and corporate foresight managers were hardly prominent, so useful reference points were somewhat limited. What I needed at the time, and what every organisation needs today, is a framework for anticipating and preparing for future change. Something to help make sense of the patterns in the chaos." This book "aims to restore the loss of organizational agency by providing an innovative process for strategy development that is purpose-built for today's volatility and uncertainty."

"Central to this process is the art of developing scenarios and an appreciation for the anticipatory and transformational capacity that scenarios enable. Scenarios empower managers to generate original strategic perspectives, to reperceive the future environments in which they might have to compete, and to reconceive the organisation's role and functions within these futures. In doing so, internally generated scenarios help deliver that rarest of business assets, a unique strategic outlook that is fit for the future. Such an outlook is the source of organisational distinctiveness."

A couple months ago, I came across a social media post of an article by Dorie Clark published in Harvard Business Review entitled "If Strategy is So Important, Why Don't We Make Time for It?" Unfortunately, I found this article to be problematic, because for one, it doesn't even try to define "strategy". So I responded with the following comment: "if strategy is so important, why don't we define it?". Tighe, on the other hand, defines "strategy" at the outset: "a plan for action to achieve your goals in perceived future environments." While I tend to agree with Eisenhower that "plans are worthless, but planning is everything", in the sense that strategy should be an ongoing process, the author makes it abundantly clear throughout the rest of this book that this "plan for action" doesn't end. So in other words, strategy is actually planning for action to achieve one's goals in perceived future environments, even though the author later states that "strategy is not planning", mainly because, traditionally, the output of strategy is a plan. If you are at all confused by these last few statements, you have a taste of why Clark likely didn't even try to provide a definition. 

The material of this book is broken down into thirteen chapters across three parts: (1) searching, (2) learning, and (3) doing. After discussing the trouble with trends, the author details the theories and methods, acquired and developed over the past 15 years, that underpin his approach to designing strategy, followed by a transition from this theory of strategic design to its actual application, describing an end-to-end process for scenario-based strategy development and using successful case studies to illustrate business practicality. Fortunately for readers, Tighe spends fully 60% in the latter part on doing, as theory tends to be where many strategy authors tend to spend the bulk of their time, never venturing into practical execution.

About ten years ago, I began my foray into strategy by reading extensively on the subject, quickly moving to scenarios due to the practicality these offer, and have in years since been contacted by authors such as Rita McGrath, strategy professor at Columbia Business School, to review their books. After reading through "Scenarios: The Art of Strategic Conversation" by Kees van der Heijden, I was shocked that a senior executive with whom I was working at the time on a client engagement was not familiar with the concept of scenarios. I still remember the response that he gave when I brought this topic up in the context of a software development effort I was leading: "What do you mean, scenarios?" After providing an initial explanation, he closed this subject matter quickly: "We don't care about that."

Tighe comments on this very topic. "In the eyes of my (half-serious?) colleagues I was now the resident fortune teller, palm reader, crystal ball gazer (insert cliché of choice here). The truth behind their jibes points to one of the reasons for the lack of scenario usage in business: serious attempts to understand the future are confused with efforts to predict, and since prediction isn't possible, scenarios are either dismissed as an exercise in futility or else just not taken seriously. 'Can't predict, so why bother?' seems to be the attitude, as those who carry the futurist title are regarded with a skepticism usually reserved for snake oil salesmen." As the author continues later, "leaders prefer the illusion of certainty. It allows them to act quickly and decisively, to convey perceptions of control."

As someone who has read extensively on the subject of strategy, my favorite chapters are chapter 8 ("How do I know what I think until I see what I say?"), chapter 10 ("'What's next?' - Anticipating the future") which comprises over 20% of the book, and chapter 13 ("Making sense of the patterns in the chaos"). Specifically, I appreciated the author's coverage in chapter 8 of the four stages of competence (unconscious incompetence, conscious incompetence, conscious competence, and unconscious competence), the last of which leads to complacency. In chapter 10, I appreciated Tighe's matrices that plot relative degree of uncertainty versus relative degree of impact, and in which cases scenario development should actually be used for influencing factors. Lastly, in chapter 13 the author introduced me to the concept of memories that are not confined to the past, memories of the future, to an extent that I am interested in reading the related academic paper. Well recommended text for those new to scenario planning, and those searching for practicality in a sea of theory.

Media Query Source: Part 21

The responses I provided to an "anonymous" media outlet series of queries on December 4, 2019:

Media: Technical debt is the added cost that's incurred when software is developed quickly with little or no regard to quality and must be reworked to reach its intended objectives. Looking for experts who can answer some or all of the following questions:

1. Why is technical debt bad? 

2. What is an effective method for reducing technical debt without killing operations? 

3. What's the best way to plan a software project that ensures technical debt is either minimized or eliminated? 

4. Is there ever a time when technical debt is actually useful? 

 

Gfesser: Absolutely. As such, the definition of technical debt provided for this media query ("the added cost that's incurred when software is developed quickly with little or no regard to quality and must be reworked to reach its intended objectives") can be a bit of a misnomer, depending on the audience.

 

I've often used the incurring of technical debt as a strategy in order to develop code that fulfills application needs from a functional perspective, knowing that it will need to be revisited for refactoring for a variety of reasons. For example, code may not be fully configurable with respect to environment differences or user needs, or fully enabling DevOps processes. But the lack of these code attributes doesn't mean the code is functionally incorrect. 

 

When developers use this strategy, it does not mean that they have low regard to quality. In fact, code should ideally be written in a way which permits the addition of these missing attributes at a later point, meaning that even though technical debt is being incurred, it doesn't mean that code quality is bad. This just means that some attributes of the code will be worked in at a later point.

 

The danger of using this strategy, however, is that not all stakeholders will understand how it works, or the implications of making use of it. For example, business stakeholders with minimal technology backgrounds may not understand that just because an application is functionally correct that it may not necessarily be an ideal foundation on which to add additional code down the road.

 

One key implication in using this strategy is that technical debt needs to be periodically addressed, and cannot be forgotten about or consistently deprioritized by stakeholders over a lengthy period of time, since the more time which passes before it is addressed can often lead to greater challenges as the code base can increase in complexity in the meantime.

 

It's a good idea to schedule either the periodic tackling of technical debt, say every X number of Sprints, or schedule around a particular release schedule. I've often, for example, knowingly incurred technical debt prior to the release of an MVP (minimum viable product), only to schedule the tackling of technical debt in an incremental manner that coincides with either the MVP or a release shortly following up to it.

 

Another example is the postponement of addressing application performance. I've followed the philosophy of Donald Knuth that "Premature optimization is the root of all evil", because spending too much time on performance improvement before an application is actually used (or before application usage is known) deviates valuable time that could otherwise be spent on functional correctness.

 

With respect to some application aspects such as performance, it's important to understand that while the architecture of a given application or system can evolve, in order to minimize disruption it is imperative to choose an architecture which can evolve well.  So with respect to performance, for example, while the development team may not know how much data might be processed down the road, the architecture should be able to scale well in order to prevent ripple effects in the code, or worst case, a completely new architecture within a relatively short period of time.

5. Is there anything else you would like to add?

---

See all of my responses to media queries here.

Media Query Source: Part 14

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

Media: Customer-centricity, customer journeys, data as an asset. In a lot of cases, it's just lip service. The real reason companies aren't keeping their promises traces back to the data they have and don't have, as well as how they use or don't use it. This piece will explain what's going wrong, why, and what companies need to do to fix it. 

Gfesser: From my experience, I've seen many businesses place considerably higher value on their applications than their data. And in many cases, it's not difficult to see why: applications are often customer facing, and customers need to be served.

IT departments in many of these businesses also value their applications more highly, but the reasons behind this philosophy are a bit different. From my experience, I've seen the reasons fall into one or more of the following categories: (1) the data is seen to be already (or magically) available, (2) the data is "the easy part", (3) the data is not understood, or (4) a desire to work on the data does not exist.

What's wrong here? The reality is that as much as some executives might be focused on the appearance and functionality of user interfaces, the purpose behind these user interfaces is to provide some type of services, and services are all about data.

I've worked in a wide number of roles for modernization and transformation efforts. Businesses looking to pursue such efforts need to understand that when it comes down to it, data is a longer term asset than any applications that might be built to make use of it. Applications are often replaced due to new requirements or new technologies, but the data cannot simply be replaced.

Based on my experience, any firm looking to pursue a modernization or transformation effort should first make sure that its data is in good shape, or at the very least, address its data in parallel with the reworking of its applications. This is especially the case for businesses which have grown quickly and need to reign in product sprawl across the enterprise.

The tooling for applications and data, while traditionally separate, are increasingly converging to the point where IT departments will need to take both of these areas into account simultaneously, especially in an era of microservices and distributed applications, where data awareness needs to be heightened due to the pervasive role that it plays.

---

See all of my responses to media queries here.

 

Media Query Source: Part 12

---

My responses ended up being included in an article at Connected Futures, Cisco's executive insights magazine (September 5, 2018). Extent of verbatim quote highlighted in orange, paraphrased quote highlighted in gray. Above image from cited article.

---

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

Media: Looking for experts on digital transformation to comment on the top classic blunders companies make while trying to digitally transform. What are the classic blunders and why do they happen? Please also share tips/steps to avoid making these blunders and/or on correcting course.

Gfesser: The first grouping of classic blunders includes (1) not communicating what "digital transformation" means, (2) limiting scope of transformation to technology, and (3) taking on too much at once.

 

A few years ago, I sat in a "digital transformation" discussion presented by a consultancy. The key visual that the presenter had to share was a high-level architecture diagram that they said represented digital transformation. The main topic of discussion prompted by the audience can be summarized as follows: "How does this diagram represent digital transformation? I'm not seeing anything different here than what we're already offering to clients."

 

In a nutshell, the presenter responded that business development needs to start using the term "digital transformation" because this is what industry research firms such as Gartner are using in their reports, and because client execs read these reports, there needs to be alignment with everyone speaking the same language.

 

As the discussion evolved, the audience began to ask whether this was just marketing, and while this presenter did not explicitly state as such, many presentation attendees came to this conclusion: quite simply, they didn't see anything materially different.

 

Unfortunately, this presenter provided a wanting definition of "digital transformation". While it is quite alright to use this term, the reality is that because it has become an industry buzzword with varied, often vague definitions, it needs to be defined for all stakeholders involved in any way with such efforts.

 

Regardless of definition, most typically agree that the scope of digital transformation goes beyond technology, beyond modernizing technology. Application functionality, for example, can be rewritten with modern technology stacks. Efforts such as this are often very needed, but rewriting doesn't explicitly address how work is being done, and doesn't necessarily address the business or how users might want to operate. Additionally, modernization itself doesn't in itself focus on how the problem space might be reimagined for additional monetization or a shifting of marketplace strategy.

 

Don't get me wrong: technology is an important component of digital transformation, oftentimes encompassing a large component of such efforts, because technology can have an immensely transformative effect. The likely questions that need to be answered by companies can probably be summarized as follows: "What is the end goal of our digital transformation?" and "How do we reach this goal?" If the result doesn't holistically address the company, the means to this end likely doesn't involve digital transformation.

 

Lastly, taking on too much at once is a very real risk. For a long time many have had the sense of what a "big bang" effort entails: essentially an attempt to do everything in one go, and oftentimes trying to perform all planning up front. While much progress has been made with iterative planning, defined scope can simply end up being too large a goal. While scope can be broken down into iterations as well, the risk here is to only view success in light of the original vision.

 

While I tend to agree that one needs to think big with respect to digital transformation, it also makes sense to take steps. Agile practitioners often talk about the "minimum viable product" (MVP), but sometimes forget that this approach is intended to deliver a minimally functioning product in order that feedback can be used from users as input to evolve the product as it is built.

 

En route to the MVP, I typically build one or more proofs of concept and/or proofs of technology, which feed into the building of prototypes on which the MVP is later constructed. So in my view developers are also users because applications need to be proved out. But these are all incremental steps. I've seen clients take on too much and fail because their concept of "minimum" was a bit too aggressive.

 

Keeping in mind that failure can be a good thing that feeds subsequent efforts, there is also failure that takes too long to be realized because an incremental approach was not adopted.

 

The second grouping of classic blunders includes (4) not fostering relationships between departments, and (5) not fostering an open company culture.

 

Because digital transformation involves more than the technology that is being used within a firm, relationship building between departments needs to be fostered. In addition, firms with fragmented or matrixed teams can benefit from restructuring so that teams are cross-functional and in many cases organized around output viewed as products rather than projects.

 

Cross-functional teams are more agile, which means that changes are more easily made to enable what is needed, especially in reaction to input from customers. And the distinction between products and projects is important because products are long-term company assets that typically have extended lifecycles.

 

While the concept of "project" will likely never go away, a project focused culture often leads to short-term thinking due to fixed end dates, with these dates prioritized above the actual work product. A product focused culture enables continued reassessment of priorities for the work product. Dates are still involved with such a culture, but timelines are typically much shorter in order to react to user feedback, and to enable continuous delivery.

 

I mentioned to a recent client that open company cultures help foster digital transformation: this goes for access to source code, documentation, and all other forms of communication. While changes to culture can come more easily to some firms, some period of time should be expected for most, especially for long-lived organizations.

 

Clear visibility is a key reason for the rapid and widespread adoption of open source software, which routinely offers code and product roadmaps, as well as the participation that it welcomes from the developer community in terms of general feedback, bug reporting, and the ability to submit changes. And these principles can be holistically applied to firms.

 

---

See all of my responses to media queries here.

New Book Review: "Future Legends"

New book review for Future Legends: Business in Hyper-Dynamic Markets, by Janka Krings-Klebe, Joachim Heinz, and Jörg Schreiner, 2017, reposted here:

Just recently, I read a post submitted to a professional forum that someone had written on the subject of agility and why agility is not really what organizations need to succeed. This particular post attracted over a dozen comments from readers, and somewhere across the thread of discussion an individual remarked that an assertion another reader had made was correct with the given that agility was synonymous with speed. In turn, I responded by commenting that these two terms are actually not synonymous, and that agility is typically needed but cannot be considered in isolation.

This discussion recalled to mind that I have found myself needing to repeatedly define quite a few seemingly common terms for others in the workplace, as many terms summoned by those around me in conversation come prepackaged with assumptions, with conversation participants often not seeing eye to eye so-to-speak. The authors do touch on a number of terms with which readers may already be familiar, but their presentation was thoughtfully put together in a way that makes the risk of losing reader attention low. At the outset, the authors comment that their focus was to provide a collection of their insights and answers around five key questions in the hope that it will provide inspiration and hands-on guidance to business leaders and policy makers.

These five questions are the following, slightly reworded for clarity: (1) "What exactly makes digitalization such a powerful force in the marketplace?" (2) "What are the principles that make companies highly adaptive and innovative in the digital age?" (3) "How can the innovativeness of start-ups be combined with the scale of large organizations?" (4) "How do the practices of management need to change for a connected business?" and (5) "What could connected businesses contribute to solve income and opportunity disparities?"

After the authors discourse about the world being in a permanent state of change at a scale never previously experienced, they explain why businesses need to adapt to the connected age enabled by digital technology in order to remain relevant. The discussion then segues into why this connected age requires businesses to become engines for innovation, and is furthered by discussions on why hyper-dynamic markets challenge businesses, why management is no longer about optimizing the known, and why societal contracts from the industrial age cease to work in the connected age.

While I found the introductory claim by the authors to be correct that they deliberately stay clear of technical jargon (because they have found technical terms to be often burdened with theory and distracting in nature from key concepts), this is not to say that they do not take the time to provide explanations along the way. Quite the contrary, the authors lead readers in a manner that assumes a bulk of the material they have to present is being taken in for the first time. And as such, they likely leave very little room for misinterpretation by those in the business world.

One of the few areas in this book where I divert from this view is with regard to the brief mention of Scrum midway through the chapter 2, as successful reader interpretation is assumed. While I agree with the authors that such methodologies are often adopted in isolation within firms rather than adopted wholesale, and that the latter is preferable, what is not explained is that starting small can lead to success within a specific domain or context, albeit even if this strategy does not end up providing success for the business as a whole, as I have witnessed this with the practice of bimodal IT.

That said, the authors explain in chapter 4 that one popular approach in the transformation of a business is to set up separate business units that are then tasked to develop new business opportunities, and they have found the following from their research and experience: (1) business incubators more or less always act within the limitations of the corporation in which they belong, and (2) the options to scale the business that has been developed in an incubator also depends on the framework of the corporation, and unconventional business operations will not survive in a framework optimized for a completely different goal.

As a consultant, I especially appreciated the discussions on the opposing cultures of exploration and exploitation which permeate throughout the text. As the authors explain, any business needs to perform these two fundamentally different tasks. Exploration means the continuous search for unmet market needs and how to address them, or in other words, exploring the known. Exploitation means delivering solutions to the market at scale, or in other words, scaling the known. And businesses cannot typically perform both of these tasks very well, and so tend to favor one over the other.

Additionally, I enjoyed the last several sequential sections in chapter 3 (about 30 pages in length) that present how a connected business acts, the new logic of a connected business, and how a connected business deals with the dynamic. In contrast with many business texts which heavily comprise historical business cases and do not spend enough time abstracting what should be gained from these cases (or for that matter, explaining to readers that copying the strategies of competitors is not going to help them differentiate), for this particular subject matter I appreciated that the authors did not do so here, especially with regard to what they have to say in the section entitled "how to start a business in the future".

Toward the conclusion of this text, the authors comment that a connected business with its open system does not try to limit variety and dynamic, and on the contrary, these conditions fuel its business. They need exactly the opposite conditions of those that closed business systems offer. In asking Haier's CEO Zhang Ruimin how he managed to balance the chaotic entrepreneurial energy and the need to control, he answered: "We don't need to balance! An unsteady and dynamic environment is the best way to keep everyone flexible!" Of course, the authors backpedal a bit on his response and comment that this is not necessarily a statement that can be made more broadly, but I like it!

New Book Review: "Pricing Done Right"

New book review for Pricing Done Right: The Pricing Framework Proven Successful by the World's Most Profitable Companies, by Tim J. Smith, Wiley (Bloomberg Press), 2016, reposted here:

As the author (founder and CEO of Wiglaf Pricing) mentions at the outset, every offering of a given firm and every transaction a given firm has with its customers has a price. Somehow, all of these offerings and transactions have prices. Either these prices are the result of lengthy deliberations consisting of market research, competitive dynamics, highly researched algorithms, intense customer negotiations, and torrid management discussions, or just numbers that popped out of someone's head. In one way or another, pricing decisions get made. But how should prices be determined? What should inform pricing decisions? And who should be engaged in those pricing decisions? While the managerial challenges of of pricing are well known, what isn't so well known is how these challenges should be addressed. The author argues that executives need a framework that will help them shape their organizations, routines, staff, information management, and analytical tools that will guide the organization toward making better pricing decisions. This book presents the Value-Based Pricing Framework as a template for executives to use in managing pricing decisions throughout the organization. This framework codifies best practices for managing prices in profit-seeking competitive businesses, and was developed through direct interviews with practicing executives, reviews of the academic literature, and implementations of this framework in numerous firms.

The five key decision areas identified in the Value-Based Pricing Framework are (1) business strategy, (2) pricing strategy, (3) market pricing, (4) price variance policy, and (5) price execution. An organizational function called pricing analysis supports these key decision areas by informing, guiding, and stewarding pricing decisions across the organization. Specific repeatable processes to inform pricing decision areas or provide informational feedback loops to improve pricing decisions are built into the framework. Business strategy consists of the choices a firm makes to differentiate itself in a manner which serves customer needs more profitably than competitors. Pricing strategy refers to the manner in which a firm will manage prices through its price positioning plan, price segmentation plan, competitive price reaction strategy, and pricing capability strategy. Market pricing is the setting of starting prices for all offerings and transactions of a firm. Price variance policy determines the rules for granting discounts and promotions. And price execution applies the appropriate prices according to the rules developed by strategic and managerial decisions, and subsequently collects these prices from customers in a timely manner with minimal error. The author walks the reader through each of these areas in the remainder of his presentation, and additionally provides appendices on the economic origins of competitive advantage, as well as one-on-one interviews with Jesse Finch Gnehm of GE Oil & Gas and Robert Smith of Eastman Chemical Company on how their respective firms get pricing done.

The author provides a very succinct, well edited presentation that could have easily stretched to twice the length and gotten sidetracked on lengthy tangents like other business texts. While the diagrams are extremely well done and immediately reminded me of the line drawings throughout a book in another subject area called "Waltzing with Bears", I would be inclined to recommend being a bit more liberal with the visual presentation (the count is just over a dozen diagrams). While I mentioned earlier that the author walks readers through the Value-Based Pricing Framework, I think it is worth mentioning that the presentation really does start from square one. Oftentimes, material presented in this manner elsewhere is labeled "introductory", but readers can get sidetracked into thinking that this label is intended to mean that content remains at an introductory level, or subsequent texts need to be reviewed to access more advanced material. But this label is really typically intended to mean that a given author seeks to make sure readers have an initial foundation, rather than running the risk of drowning the unaware in a sea of information. In much the same manner, the small amount of math that is presented is limited to chapter 2 ("Value-Based Pricing"), chapter 4 ("Pricing Strategy"), and appendix A ("Economic Origins of Competitive Advantage"), and consists of just a few variables such as product price, variable costs, fixed costs, quantity sold, and maximum customer benefits.

As a consultant, I especially found chapter 7 ("Pricing Continuous Improvement and Analytics"), chapter 8 ("Organizational Design of the Pricing Specialist Function"), appendix B ("Getting Pricing Done with Jesse Finch Gnehm of GE Oil & Gas"), and appendix C ("Getting Pricing Done with Robert Smith of Eastman Chemical Company") of interest. For example, in Appendix B the interviewee (a global pricing leader) mentions that he is not using any of "the traditional, mainstream, pricing software vendors right now", but is instead "developing some tools for pricing analytics within enterprise-level business intelligence tools". Additionally, this interviewee says that "visualization tools tend to be the place where we are seeing the most value right now", and that "statistics are great when you've got enough data to push through it...but you run into a lot of N problems...if your N is a small order of magnitude, stats aren't going to do a lot for you...so the visualization is a big and important place for us...it makes the analysis tangible for people...they can consume it in a way that makes sense to them". In chapter 8, in laying out some key areas where software is supporting pricing efforts, the author rightly points out that such software should be used to supplement efforts of the pricing talent, not instead of the pricing talent, and warns that firms too often purchase pricing software without the talent to utilize it and understand its output, leading to poor results. The author recommends that firms develop the required talent first, and then identify the software needed to accelerate the output or reduce the costs of generating the output of their pricing talent.

New Book Review: "Future Value Generation"

New book review for Future Value Generation: Do You Need to Create New Business Logics?, by Daniel Egger, CreateSpace, 2016, reposted here:

Copy provided by author Daniel Egger.

According to Egger, most companies today strive to react with quick solutions when challenged by change, and at the same time, strive to design new opportunities for the future. Unfortunately, however, companies get disappointing results because (1) innovation merely attempts to solve past problems, (2) strategy locks in a static worldview, and (3) foresight too often explores what is possible, but not practical. In order to create new value (which the author refers to as "logic"), the author argues that companies instead need to integrate these three approaches.

In his introductory pages, Egger explains that organizations will lag if they do not add new competencies and new methods to prepare for change. "If they try to meet new challenges using the reasoning, arguments, and hypothesis of the past, they might solve the problem, but it will take increasingly more time. Without new organizational capabilities, they have less and less time to adapt these new challenges, which will increase in quantity and complexity. Urgent action is critical."

"If the organization is inactive, cultural distress builds up, leading to managing daily crises and fast, super-simplified decision making, a tactical response that cannibalizes mid- and long-term value generation. This way of responding to change drives the organization into constant waves of disorder, causing it to forget about creating purpose and exploring new opportunities that emerge. Interesting is that a focus on crisis management might save the day but will only postpone critical business decisions."

"The strategic relevancy for exploring the necessary changes to business logics and understanding the ongoing shifts only increases with time. A proactive attitude to the future is necessary. It leads to a higher level of agility and adaptation of the business logic to external change. Understanding the future means preparing strategic alternatives and counter-attacks before they are needed. By setting such a course, organizations identify risk and transform complexity into opportunity. We have to unlearn the old, and be open to and prepare for the new, not as a leadership development dogma, but as a strategic necessity, even if this demands hard decisions."

This book is broken down into 3 chapters. The first chapter lays the groundwork for value generation, and along the way explores the connections between change, opportunity, and design, as well as the importance that each brings to creating new business logics. The second chapter is dedicated to case studies, and the third chapter explores the integration of innovation, foresight, and strategy in order to make the organization more agile, facilitate decision making, and create new future value.

As an individual who has read extensively about innovation and strategy, the 6 pages that conclude the first chapter personally provided the most value to me. The bulk of these pages discuss the types of futures that exist: (1) possible futures, (2) plausible futures, (3) probable futures, and (4) preferred futures. While the author provides a well constructed table that describes each of these types of futures, the names of each are fairly self-descriptive.

As a consultant architect, it has always been interesting to see most clients focus on preferred futures: What do we want to happen? What makes sense for the clients and us? What advantage do we expect? At the opposite end of the spectrum, however, are the possible futures: What can we imagine will happen? What is the most revolutionary change? What could happen, but sounds strange? While the vast majority of firms cannot afford to spend resources to explore possible futures, most firms should invest in the exploration of plausible and probable futures.

While I personally do not typically benefit from reading more than a few case studies in a particular subject area, a majority of the dog ears that I created while reading this book were concentrated in the third chapter, so I know that the author has presented content here that I will plan to revisit in the future. One section of this chapter was especially interesting to me, because it addresses a type of future not included in the original four: the official future. Egger describes the official future as the set of underlying past assumptions, the "entrained thinking" of executives and influencers. In revisiting my earlier comment that preferred futures have typically been the focus of my clients, it is not a stretch to say that there is probably often overlap with the official futures in their respective firms.

Egger also walks the reader through the concept of "time ecology". Earlier in my career, I focused on the current state and future state for any given software application or enterprise architecture. As I matured, I came to realize that while there is only one true current state (even though I recognize that such a true current state often does not mesh with the official current state), there are likely many possible future states, some having higher probability than others.

As the author explains, time ecology increases awareness of what change is when in transformation. "Plotting out the shifts and researching their change in direction over time provide organizations with the ability to make better and more risk-aware decisions. A timeline and expansion of the time frame reduces the fallacy of the time perception. The longer view guides us to explore more implications for our business to create a sense of the changes over time." Especially interesting in this discussion is idea of the "backcasting exercise".

While many of the concepts in this book will not be new to many readers, Egger has made a good attempt at integration. That said, many reading this review are likely not to have encountered a number of these concepts in the past. This book is recommended to those falling in this latter group, or those trying to make some sense of how many of the innovation and strategy concepts they have encountered in their respective industries might form a cohesive framework from which to draw for tackling future projects. Even the closing field notes that the author provides on corporate innovation labs (which have often devolved into entities more akin to "innovation theater") provide insight: "Any self-respecting CEO now has a corporate innovation lab!"

New Book Review: "A Culture of Purpose"

New book review for A Culture of Purpose: How to Choose the Right People and Make the Right People Choose You, by Christoph Lueneburger, Jossey-Bass, 2014, reposted here:

The content presented in this work, while centering on building cultures of purpose in organizations, also focuses on sustainability because Lueneburger has determined from experience and research that sustainability provides the most reliable blueprint for assembling the building blocks upon which cultures of purpose are built over time. In this sense, sustainability is seen as a means to an end. As explained by the author, "purpose" introduces a shared intent with impact beyond the organization itself, a pledge to do what is thought to be right, going beyond profitable growth, shareholder value, or any other measure of whether things are being done right.

The author interviewed board chairpersons, CEOs, and chief sustainability officers during the course of writing this book, who have come to the conclusion that sustainability is a primary focus of new recruits who are looking not just for jobs but for meaning. As explained by the author in the introduction, mission-led companies vastly outperform the market, and so the time has never been so critical for leaders to focus on building cultures of purpose. The war for talent is real, and the talent economy is gravitating toward cultures of purpose where meaning is seen to be pervasive rather reflected in window-dressing policies about composting and charitable giving.

This book is organized into thirteen chapters across four parts that discuss placing leaders with a purpose at the core (about 40% of the content), hiring talent with a purpose at the frontier, building a culture of purpose, and taking action (one chapter at less than 10% of the content). Author discussion starts by identifying the competencies or acquired skills at the core of a culture of purpose, followed by detailing the key innate traits of people who make up a culture of purpose, addressing the broader attributes a culture of purpose needs to thrive, and developing an actionable plan to structure the building blocks of a culture of purpose.

As a reader, I probably found the most interest in the first part of this book, although I most valued the sidebars concluding almost every chapter, which list probing questions intended as follow-ups to author presentation, as well as red flags for which to look over the course of asking these questions. For example, the author provides the following as red flags after his chapter on openness: "The greatest challenge to openness is a tribal culture, which exacerbates low openness with a lack of balance. Balance, as a cultural attribute, describes the degree to which organizations not only include a diversity of perspectives, skills, and styles but also express, recognize, and leverage the resulting differences. And the less a culture is balanced, the more openness will suffer. If companies could get moldy, this would be how."

In contrast to a related book by Aaron Hurst that I recently reviewed, "The Purpose Economy: How Your Desire for Impact, Personal Growth and Community is Changing the World", Lueneburger provides a much narrower focus on sustainability as a means to an end, and concentrates heavily on organization level case studies rather than the larger economy, or for that matter, the individual. But in surveying all of the purpose-related texts in the marketplace, each has its purpose. This book is recommended to leaders of organizations looking at sustainability as a means to an end, and how to best draw and retain related talent, but if this is your focus, you will be well served by reading what Aaron Hurst has to offer as well.

The author provides some of his best thoughts in the epilogue, which will hopefully not be missed by readers who do not get to this point. "Throughout history, two conditions have caused cultures of purpose to wane: achieving their purpose or growing beyond the scale that can consistently contain it. Each of these two conditions brings up a key question to take on your journey. Regarding the first, what has to be true about your purpose for it to be itself sustainable? There's a fine balance between being aspirational and being quixotic. On the one hand, the purpose must be more than a cakewalk destination beyond which the bonds between the people reaching it will disintegrate."

"On the other hand, it cannot be so removed from reality that it fails to bond people together with a shared desire to achieve. The good news is that you have an actionable echo of your purpose in the quality of talent that flocks to you and stays with you: the people who make up your culture. As for the second condition, is growth - for example, growth in revenues - a reasonable strategic metric for an organization? It's certainly an effective metric for a cancer, but individual cancers are not around for long if they are successful."

"To be clear: there is nothing wrong with growth per se, but it should be a by-product of doing the right things, rather than the aim of doing things right. It's a good servant, but a terrible master. The kind of growth that markets have historically liked best - say, a steady 5 percent every year - is destructive to a culture of purpose because its constancy makes it the master of the organization. But here, too, we find good news. The steady-growth mentality is gutted by what we know about long-term value creation. Adherence to purpose trumps delivery of invariant growth."

New Book Review: "The End of Competitive Advantage"

New book review for  The End of Competitive Advantage: How to Keep Your Strategy Moving as Fast as Your Business, by Rita Gunther McGrath, Harvard Business Review Press, 2013, reposted here:

While the term "competitive advantage" can be defined in more than one way, it can be argued that sustainable competitive advantage over rivals (i.e. holding on to market positioning relative to other industry players) is really a chief business goal when following such a strategy. Authors A. G. Lafley and Roger L. Martin in their recent "Playing to Win: How Strategy Really Works" (see my review) show from their experience that "no strategy lasts forever" and that "strategies need continual improvement and updating", but Rita Gunther McGrath demonstrates the need for firms to take these steps further, resulting in the likelihood of considerably more movement over time.

The author explains that there have been two foundational assumptions taken as gospel in the past: (1) "industry matters most", and (2) "once achieved, advantages are sustainable." While advantages can continue to be sustained in some industry sectors, these scenarios are becoming increasingly less frequent, and the author's research in this space demonstrates that "stability, not change, is the state that is most dangerous in highly dynamic competitive environments", and that "one of the biggest changes we need to make in our assumptions is that within-industry competition is the most significant competitive threat."

McGrath argues that firms need to increasingly compete with waves of temporary or transient competitive advantage rather than sustainable competitive advantage. In her presentation of the five phases (launch, ramp up, exploit, reconfigure, and disengage) that exist in each such wave, she stresses the fact that although exploitation of a transient advantage is advantageous for a period of time, excessive build-up of assets and people should be prevented as much as possible so that barriers to moving on to the next advantage are minimized.

In Chapter 2 ("Continuous Reconfiguration: Achieving Balance between Stability and Agility"), the author comments that "a pattern to look for in organizations that have mastered transient-advantage environments is the continual freeing up of resources from old advantages in order to fund the development of new ones", and the ten growth outliers her research team identified from nearly five thousand over the 1999 to 2009 time period demonstrate this pattern, which corresponds to equal emphasis on all phases of the wave just discussed, rather than exploitation alone.

Apart from the introductory chapter, Chapter 4 ("Using Resource Allocation to Promote Deftness") is probably the chapter I appreciated most. One segment, entitled "The Resources as Hostage Problem" is especially relevant to her presentation. The author comments that "in a traditional company, people who had lots of assets and staff reporting to them were the important people in the company", but that this "bigger-is-better mind-set is deadly in an environment in which advantages come and go. If people feel their authority, power base, and other rewards will be diminished if they move assets or people out of an existing advantage, they will fight tooth and nail to preserve the status quo."

And as a consultant, I find it interesting that the segment entitled "The Concept of Asset Debt" uses the term "technology debt" in conjunction with the need for firms to keep technology assets in a fit state in order to support competitiveness, and that continual investment and a willingness to leave older assets behind is a requirement for such a state. Usage of this term is a very relevant expansion of the much older term of which I am familiar, "technical debt", revisited at a practical level a few years ago by one of the contributors to "97 Things Every Software Architect Should Know" (see my review).

"So Why the concern over making changes properly now versus later? It's because there's a hidden cost to making these quick and dirty fixes. For financial debts the hidden cost is called 'interest', and most anyone with a credit card knows how expensive just paying the interest on a debt can be. For technical debt, interest takes the form of instability in the system, and increased maintenance costs due to the hacked-in changes and lack of proper design, documentation, and/or tests. And, like financial interest, regular payments must be made until the original debt is repaid."

While the term "technical debt" is used differently in the context of what the author shares in her discussion here, there also exist similarities in the sense that both exact penalties in the form of interest. For firms which still strive to sustain competitive advantage, such interest might prove to be so costly as to become too unwieldy for survival, missing the ability to compete with waves of transient competitive advantage in the interim. This book adds to the strategy bookshelf in a way that helps bridge some of the gaps that have existed in recent years, and makes these bridges relevant by presenting original research.

New Book Review: "Playing to Win"

New book review for  Playing to Win: How Strategy Really Works, by A. G. Lafley and Roger L. Martin, Harvard Business Review Press, 2013, reposted here:

The content of this book focuses on the transformation of Procter & Gamble (P&G) between 2000 and 2009, and discusses the approach to strategy that led to this transformation, leading to a doubling of sales, a quadrupling of profits, and an increased share price of more than 80 percent during that decade. The authors discuss that although many good strategic choices were made, the company also had its share of disappointments and failures. And most importantly, "no strategy lasts forever".

In my recent review of "Scenarios: The Art of Strategic Conversation (Second Edition)", by Kees van der Heijden, I mentioned that one of the best takeaways from what the author writes in that book is that "strategy is a highly dynamic area, full of fads and fashions that come and go", and that "copying ideas that 'work' for others is unlikely to be a winning strategy", because "success can only be based on being different from (existing or potential) competitors". The retrospective that Lafley and Martin provide in Appendix A would agree with these conclusions.

As explained by the authors, "strategies need continual improvement and updating", because as the authors have found, "competitors have copied P&G's strategies - on innovation, on branding, and the like - to an extent that renders P&G's resultant strategy less distinctive and decisive", and this is the challenge moving forward. In reflecting on its 175-year-plus history, the authors remark that "winning through distinctive choices is the always-and-forever job of every strategist", and if management continues to search for unique where-to-play and how-to-win choices that set the company apart, they should be able to further the success of the company.

Earlier in the text, the authors explain that many leaders tend to approach strategy in one of the following ineffective ways: (1) they define strategy as a vision, (2) they define strategy as a plan, (3) they deny that long-term (or even medium-term) strategy is possible, (4) they define strategy as the optimization of the status quo, or (5) they define strategy as following best practices. The authors argue that what really matters is winning, and that the play book discussed in this book, which provides five choices, a framework, and a process, is what is needed to win.

According to the authors, strategy is the answer to five interrelated questions: (1) What is your winning aspiration? (2) Where will you play? (3) How will you win? (4) What capabilities must be in place? and (5) What management systems are required? In chapters 2 through 6 of this book, the authors explain the nature of the choices to be made, provide a number of examples of each choice, and offer advice for making the choice given a context. These five choices comprise the "strategic choice cascade", the foundation of their strategy work.

In subsequent chapters, the authors present the "strategic logic flow" framework, designed to direct thinking to the key analyses that inform any strategy, and the "reverse engineering" methodology, designed to make sense of conflicting strategic options. In the former, there are four dimensions to be considered: (1) the industry, (2) customers, (3) relative position, and (4) competition. In the latter, which contrasts with traditional approaches to generating buy-in, there exist seven steps that involve exploring different ways forward and a wider variety of possible strategic choices.

As a consultant, I especially appreciated Chapter 1 ("Strategy = Choice"), which sets the stage by defining what strategy is all about, Chapter 7 ("Thinking Through Strategy"), which walks through industry analysis (segmentation and attractiveness), customer value analysis (channel and end consumers), analysis of relative position (capabilities and costs), and competitor analysis, and Chapter 8 ("Shortening Your Odds"), which explains that what is needed to find a winning strategy is to explore "what would have to be true" rather than "what is true", helping foster teams working together rather than battling one another, and surfacing differences and resolving them.

In addition, I appreciated the "Dos and Don'ts" sections at the end of each chapter, which clearly summarize the material from a practical context, as well as the strategic lessons learned side bars following these sections at the end of most of the chapters. At some level, I find the frankness that the authors share in these sections akin to how David H. Maister talks about his experiences in "Strategy and the Fat Smoker: Doing What's Obvious But Not Easy" (see my review), especially with regard to what Martin has to share at the end of Chapter 8 ("Shortening Your Odds"). Well recommended.

New Book Review: "Ethics of Big Data"

New book review for   Ethics of Big Data: Balancing Risk and Innovation, by Kord Davis and Doug Patterson, O'Reilly, 2012, reposted here:

A very much needed, extremely well written essay on what the authors call the "forcing function" of Big Data - a push to consider serious ethical issues in light of the usage of Big Data - and how to improve one's organization by utilizing the results of ethical inquiry. In just 64 pages, Davis and Patterson walk the reader through what would have likely been a much more unreachable topic had it been written by another team, and the result is arguably one of the best business texts in the year-2012 marketplace.

After discussing Big Data and Big Data forcing in Chapter 1 ("Big Data, Big Impact"), the authors turn to values, ethical inquiry, and "ethical decision points" in Chapter 2 ("Values and Actions"), followed by a survey of current ethical practices by businesses in Chapter 3 ("Current Practices") and a component-by-component discussion of the the Alignment Methodology Framework introduced earlier in the book in Chapter 4 ("Aligning Values and Actions").

What makes this text so well put together is not just the writing style of the authors, but its organization and inclusion of many examples throughout the discussion that are likely to increase the practicality of the discussion. While Davis and Patterson do formally include a brief case study at the conclusion of Chapter 4, it is the small examples that carry the heavy lifting. And while the Alignment Methodology Framework at a surface level is reminiscent of the familiar Plan-Do-Check-Act cycle, the specifics that the authors provide for each step specifically target organizational values and how to align actions with those values.

Use of the buzzword "innovation" in the subtitle to this effort is actually well placed, unlike the inappropriate use of what can be seen as a buzzword in itself, "Big Data", in some other books in this year's business shelf. As the authors in Chapter 2 comment, "While big data represents both tremendous opportunity (in the form of new products and services) for broad business and social benefit, the opposite side of that coin is that it also represents serious risk. Finding and maintaining a balance between the benefits of innovation and the detriments of risks is, in part, a function of ethical inquiry."

"Developing a capability to find and maintain that balance is partially ethical because of the essential nature of the technology itself...Ethics come into play, in part, when organizations realize that information has value that can be extracted and turned into new products and services. The degree to which ethics play a role in this process is, of course, more complicated that a simple identification of which information is 'ancillary' and which is not. The ethical impact is highly context-dependent. But to ignore that there is an ethical impact is to court an imbalance between the benefits of innovation and the detriments of risk."

New Book Review: "Scenarios"

New book review for Scenarios: The Art of Strategic Conversation (Second Edition), by Kees van der Heijden, Wiley, 2005, reposted here:

This effort seemed to be among the most respected texts amongst the short list of scenario planning efforts in the current marketplace, but the opinions of other readers with regard to what Heijden has to offer vary quite a bit, so I was not sure what to expect. While this text exclaims that "the entire text has been rewritten to bring it up-to-date and make it more practical whilst retaining the underlying rigor", and reading it in its entirety points in the direction of the author looking to practicality, I do not expect much of what is offered here to be tangible enough for most readers who seek to bring scenario planning into their workplaces. That said, the underlying rigor of this text will probably lend itself well to an academic setting, because the author does go into a fairly high degree of theoretical detail that instructors and students will likely find of value. The information provided is applicable to the workplace, but it will be challenging to apply.

After discussing a number of assumptions on which thinking about strategy is based, the author discusses the theory of scenario thinking, followed by the scenario-based planning process (the bulk of what the author presents, consuming approximately 35% of the text), and the wider institutional behavior context (approximately 23% of the text). In my opinion, these first two areas of discussion are more well done than the latter two. The intial preface and contextual chapters are especially well done. The book starts with an interview of the author by Peter Schwartz, a well known scenario planner, about scenarios and the art of strategic conversation. In some ways, I think that more books should start in this manner, because this formula does introduce the material well, but from another perspective it seems awkward because much of the book is consumed by the nature of scenario planning rather than how to actually apply it, and so the author spends a lot of time refining his thoughts on topics which could consume much less space had editors been involved in the process.

For readers new to the concept of scenario planning, the author explains that "in the final analysis the organization needs a good and unique fit with its ever-changing environment if its aims are to be achieved. The purpose of strategising is to develop policies guiding personal behaviour of individuals in the organization such that the total system achieves and maintains a good and unique fit. The problem is that this has to be achieved in a situation of uncertainty and ambiguity. If everything is known and predetermined there is no place for strategy. But equally, if everything is totally uncertain and nothing is predictable strategy is impossible. The idea of strategising for the future is fundamentally based on the unpredictability of the future, of which some aspects, we assume, can be foreseen...Scenario planning distinguishes itself from other more traditional approaches to strategic planning through its explicit approach towards ambiguity and uncertainty in the strategic question. The most fundamental aspect of introducing uncertainty in the strategic equation is that it turns planning for the future from a once-off episodic design activity into an ongoing learning proposition."

"In a situation of uncertainty, planning becomes learning, which never stops. We have an in-built urge to try to pin down situations, and to try to reach a point where we have got it sorted out in our mind. If uncertainty is acknowledged it is not any longer possible to take this position of 'we have done the planning'. The idea of continuous learning may be less comfortable for some, as it does not give us the feeling of problem closure. However, strategy is about the future, and therefore involves uncertainty. The traditional approach tries to eliminate uncertainty from the strategic equation, by the assumption of the existence of knowledgeable people who have privileged knowledge about 'the most likely future', who can assess the probabilities of specific outcomes. Scenario-based planning, on the other hand, assumes that there is irreducible indeterminacy and ambiguity in any situation faced by the strategist, and that successful strategy can only be developed in an ongoing dynamic response to this."

The author argues that the very nature of strategy in itself is a bit esoteric, and his extensive exploration of the subject is what makes this book appealing, although I find writers of other texts in the strategy space to be much more relatable, such as Henry Mintzberg, Bruce Ahlstrand, and Joseph Lampel in their book "Strategy Safari: A Guided Tour Through the Wilds of Strategic Management" (see my review). In my opinion, one of the best takeaways from what Kees van der Heijden has to offer here, even if the reader does not make their way through the entire text, is as follows: "Strategy is a highly dynamic area, full of fads and fashions that come and go. Yet a few texts seem to remain valid over the years. These mostly aim at analysing underlying structures rather than proposing specific strategies. After all, copying ideas that 'work' for others is unlikely to be a winning strategy. Success can only be based on being different from (existing or potential) competitors." Well said.

New Book Review: "Strategy and the Fat Smoker"

New book review for Strategy and the Fat Smoker: Doing What's Obvious But Not Easy, by David H. Maister, The Spangle Press, 2008, reposted here:

When I first saw this title, I was inclined to think that the author had intended the phrase "fat smoker" to be an oxymoron, because at least in my experience, there are very few smokers who are overweight. But after reading what Maister has to share in his most recent effort (see my reviews for some of his other texts, such as "Managing the Professional Service Firm", "First Among Equals: How to Manage a Group of Professionals", and "The Trusted Advisor"), I came to realize that he was describing himself.

In setting the stage, Maister notes in the first chapter that "many change efforts are based on the assumption that all you have to do is explain to people that their lives could be better, convince them that the goals are worth going for, and show them how to do it. But this assumption is patently false. If it were true, there would be no drug addicts, no alcoholics, or bad marriages in the world. 'Oh, I see, this behavior's not good for me? Ah well then, I'll stop, of course!' What nonsense!"

"And yet strategic plans and annual speeches by CEOs, managing partners, management consultants, and others continue to adopt this same useless structure: 'Look at how fabulous it would be if you were a fit, nonsmoking exerciser, David!' My usual response? 'True, but please shut up and go away.'" Later, the author follows up by drawing a parallel between the reasons for his sudden move to stop smoking, start exercising, and losing weight, and how change often finally comes about in the business world.

"We all know the main thing that works: a major crisis! If revenues drop off sharply, it's amazing how quickly businesses can act to deal with known inefficiencies and bad habits they could have tackled years ago." After discussing some of the aspects that are known about persuading people of change before the "heart attack" comes, the author brings up what will probably hit home to many business professionals, in professional services firms or elsewhere.

"Everyone in the organization has to decide if they want to try hard enough to sacrifice some of the present to achieve a better tomorrow. They may do so if they believe that the effort is serious. They definitely will not if they think those at the top are undecided or divided. Professional firms are afraid of this conclusion. They try to work around the skeptics, the nonbelievers, and the nonparticipants in their senior ranks, preferring to hold on to revenue volume rather than put together a senior team whose members are equally committed to reaching. That's fine, but you can't call it strategy."

As a consultant, one aspect that I appreciated about this book is that after an illustrious career and several popular books, Maister takes the risk that exposing some of his past and present faults will drive home the points that he attempts to make. And by and large, in my opinion he is successful doing so. In addition to the introductory chapters, I also especially enjoyed chapter 6 ("Do You Really Want Relationships?"), chapter 9 ("Tyrants, Energizers, and Cynics"), chapter 10 ("Why Most Training is Useless"), and chapter 19 ("Passion, People, and Principles").

This third chapter that I have listed, in my opinion, is one of the best chapters that Maister has ever written, and should be required reading for anyone already in the business world, or preparing to enter it, especially those interested in management. As he mentions in his introductory statements to this chapter, most companies use training as a business version of a "quick weight loss" program. "They hope that by training people in new things, they can quickly bring about behavioral changes among their employees. It almost never works." Why? Because training is an almost useless first step in a committed program for long-term change, especially when it is being used as a substitute for changes in managerial behavior.

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 Limits of Strategy"

New book review for The Limits of Strategy: Lessons in Leadership from the Computer Industry, by Ernest von Simson, iUniverse, 2010, reposted here:

In my opinion, it is amazing that so few reviews have been posted for this extremely insightful effort by Ernest von Simson, veteran consultant and co-founder of Research Board, an international think tank that investigates developments in the computing world and how corporations should adapt. Ever since an editorial on cloud computing in "The Wall Street Journal" mentioned this book in passing in March 2011, I have been working through the dense but conversational 400-pages that von Simson offers the reader, arriving at the conclusion that not only is this book one of the best business texts I have ever read, it should be considered required reading for the business- and technology-minded in school, as well as anyone involved in strategic decision making in the workplace.

Not only does von Simson present very detailed notes from many of his conversations with business leaders from 1974 through 2000 when explosive changes in the computer industry took place, he provides insightful analysis throughout, while even briefly discussing the initial failed business efforts of he and his wife, Naomi. In the words of the author, their friends prescribed that they "build a group of clients, major companies that needed to mesh their strategies with the exploding world of computing", "investigate what developments were coming, what adjustments they should make, and how to integrate information technology into their operations", and "scrutinize all the major technology companies and advise our clients on what the IT leaders were doing, how good they are, and who was ahead in which new fields."

Later, von Simson notes that "by the time we sold the Research Board to Gartner Group in 1999, we had written nearly one hundred reports. Every year, we would assess the overall condition of the industry - which companies were doing what, and how well; what big breakthroughs seemed near. We also researched how the largest enterprises used new technologies to the best advantages as well as demographics and the labor force and the relationship of IT departments to the other activities in a company. What we learned, we recorded in thousands of written pages and in our memories. The lessons learned over that entire period are distilled and related here."

While this text provided natural follow-up to recently read texts "The World's Newest Profession: Management Consulting in the Twentieth Century", by Christopher D. McKenna, and "IBM and the Holocaust", by Edwin Black (see my reviews), what sets this work apart from these related efforts are two seemingly opposed characteristics: industry-wide breadth, and intimacy that is only available through face-to-face interaction. However, as with these other sizeable books, a review limited to the space available here is difficult, so what follows are some quotations that I especially appreciated and which hopefully prompt other visitors to read through the pages of this text, even if only by skimming, if that is even possible.

In chapter 6, "First Movers: The Dawning of the Personal Computer", Sam Bernstein, VP of Marketing at Commodore Computing, is quoted as saying that "in 1970, when everyone else was selling calculators for $1,000, [Victor] had one for $195. We thought that the entire industry would sell 100,000; actually, as prices declined, fifty million were shipped (a classic case of price elasticity). Everyone asked us, 'What about service?' I said, 'Nonsense. For $195, let them send it to the factory.' They said, 'What about salesmen? How will customers learn to use their equipment properly?' I said, 'For $195, let them teach themselves.'"

In chapter 7, "Defeated in Succession", the author notes that "during the seven years of pointless internal dithering, the Doctor [An Wang] had remained determined to leave the company to his son, notwithstanding the availability of a more capable choice. But could the old man listen to his born successor as Tom Watson Sr. had listened to his? It's impossible to imagine Fred saying, as Watson Jr. had told a journalist after his father died: 'My father and I had terrible fights. He seemed like a blanket that covered everything. I wanted to best him but also to make him proud of me. I really enjoyed the 10 years with him.' Instead, it appeared, Fred received a vote of no confidence from his parents, though he was allowed to remain on the board."

In chapter 11, "Self-Accelerating Economies of Scale: Apple, Microsoft, and Dell", von Simson recounts when he and Naomi first met Steve Jobs just three days before Apple's 1983 introduction of the Macintosh, when during their meeting Jobs "leapt to a whiteboard and began sketching a visual analogy: By the 1890s, the telegraph was already fifty years old, and 25,000 people worked as trained operators. Someone may have suggested putting a telegraph key on every office desk to expand communications, Steve said, but it was impractical and time-consuming to teach everyone Morse Code."

"About the same time, though, the telephone was invented. The function was the same - communications - but now anyone could talk or even sing to anyone else, no training required. In just ten years, 200,000 telephones were installed. Steve Jobs was selling to people who could use the telephone; Digital, IBM, and the others were still targeting the telegraph operators. Price and ease of use, he concluded, carried implications for sales approach, customer training, and field maintenance similar to those experienced previously by the makers of electromechanical calculators."

In chapter 12, "Choosing the Wrong War: IBM Takes on Microsoft", in the midst of the author's recounting of his visits to Microsoft in Redmond, quotes "Big Blues: The Unmaking of IBM", by Paul Carroll, a "The Wall Street Journal" reporter, as writing "One of the biggest fights IBM and Microsoft developers had came when a Microsoft developer took a piece of IBM code that required 33,000 characters of space and rewrote it in 200 characters, 1/160th of the original space." Comments von Simson, "the episode makes the IBMers seem muddily stupid. Certainly, Microsoft had the advantage in attracting brilliant computer science graduates steeped in the latest programming techniques from the best universities."

"But IBM had years of experience tightening 'path lengths', that is, the number of instructions in the path to complete any routine." Later, "Mike Maples was correctly philosophical with us: 'We faced Hobson's choice - either delay release for a year or go to market with what we had and learn from early-user experience. We chose the latter.' Good strategy, great product, but not necessarily a model of disciplined or efficient programming." Although many practitioners today might argue otherwise, this philosophy is much in line with "The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses", by Eric Ries (see my review).

In chapter 18, "Squandered Competitive Advantage: IBM Mainframes and Minicomputers", after the author remarks that "competitive advantage can be squandered by executive indecision in a surprisingly short time", and "a delayed decision can be far worse than a mediocre decision", describes his IBM visit following the 1981 reorganization, during which time a merge or discontinuance of five midrange product families was discussed with Mitch Watson."

"Mitch offered four alternatives: "(1) create an outer skin of compatibility by making applications programming languages like COBOL work identically everywhere, (2) mask the differences with a software layer of microcode while leaving the underlying hardware and software, (3) find each mini a distinct market niche, and (4) kill a couple. 'That last would make some customers unhappy', allowed Watson. Yes, 'but the only assurance we'll regain economies in manufacturing and field support is to simplify our product line,' added the planning manager, Mike Maples."