The Value Flywheel Effect: Power the Future and Accelerate Your Organization to the Modern Cloud

by David Anderson

It's no secret that technology is moving faster than ever, but current business/IT strategies are not working. To survive the next wave of transformation, the relationship between businesses and technology must evolve. In The Value Flywheel Effect, David Anderson enables leaders to create an adaptive organization built upon embracing strategic thinking, team focus, and reduced time to value to drive business results. The Value Flywheel Effect is a technique already being used by next-generation leaders and companies to succeed in the modern competitive landscape. Combining the power derived from the Value Flywheel and the situational clarity provided by Wardley Mapping, organizations are able to sense and respond to change, easily navigating the rough waves ahead, including migrating to the cloud and serverless. Every company that uses technology must act differently from the companies of yesterday. In The Value Flywheel Effect, David Anderson shows organizations how to understand and utilize the socio-technical intersection between business, technology, and people, giving your organization the edge, it needs to navigate future challenges and build maximum situational awareness.

Genres: Business, Leadership, Technology, Management

320 pages, Paperback

Published November 29, 2022

About the author

Librarian Note: There are more than one author in the Goodreads database with this name.

Others:
David 2^ Anderson : Mystery, Humor, Comedy
David 3^ Anderson : GR Author, Childrens (see D.F. Anderson)
David 4^ Anderson : GR Author, Horror, Science Fiction, Paranormal
David 5^ Anderson : Pet, Dog
David 6^ Anderson : History, African Studies
David 7^ Anderson : GR Author, Thriller, Suspense, Young Adult

Reviews

[Sebastian Gebski · Rating 3 out of 5]

3, 2, 1, ... the strong candidate for the title of the most hyped IT book of the next 12 months has already landed. Is it any good? Ehhh, I've got mixed feelings.

"Mixed" is a good keyword here - there's very little genuinely unique or inventive content here. The author mainly refers to ideas taken from other books (e.g., "Accelerate", "Team Topologies", "Architect Elevator"), public speakers (e.g., Pat Kua, Nick Tune), or methods (DDD, Well-Architected Framework) - mixes them and turns them into a digestible message. A strong one (TBH), with quite solid foundations (generally) and not much controversy.

Sometimes there's just too much mixing, though ... Architecture concepts are blended with criticizing the "tech bros" (rather shallow), sustainability (!), Wardley maps, serverless, CDK, and whatnot... Now we're getting to the most irritating elements of "The Value Flywheel Effect" ... Some elements are being repeated over and over again, not always with a reason.

I do understand paying so much attention to Wardley mapping - it's not an easy concept, but can be used in many different contexts - the author does quite well when it comes to that. But honestly, he just can't stop bubbling about "serverless" - sadly, in an extremely shallow and annoying way. I work for a cloud provider, we offer and preach serverless services, but we do understand they are not a panacea - some scenarios are fit for them, and some are not. The author finally (late in the book) admits that partially, very briefly, but the majority of the book is the same mantra ("serverless first", "serverless was what made the difference", etc.). Sounds like a bad-quality cable TV ad, not a serious book about real tech.

Another irritating aspect is the never-ending litany of praise for Liberty Mutual. I'm not saying I've expected something 100% objective, but ... he nearly calls themselves Master of the Universe while the only arguments brought in for are: being featured on Werner Vogel's re:Invent keynote and, of course ... yes, you've guessed correctly - becoming "serverless first". What were the real results? Real achievements? One is easy to guess for everyone who knows the insurance industry - they indeed had a massively under-utilized infrastructure and tons of applications that were barely used (but ofc had to be deployed) - so I agree, switching to serverless may have been a huge cost drop for them, but ... does it really make sense to assume everyone else has exactly the same top problem?

What else? Proposing sustainability-related metrics (like carbon footprint) as a way to measure technical debt has really made my day ...

It doesn't mean it's an utterly bad book. For folks unfamiliar with books, authors, or techniques referred to - it may be a good starting point. Not a very technical one, so it will work for product folks as well. But I start feeling physical pain when I think that someone will read this book and say: "we really need to embrace serverless; this is the main difference between the modern, successful top performers and the legacy-fed laggards ...".

[Evita · Rating 4 out of 5]

Some of my favourite quotes:

If everyone owns everything, you’ve got a problem. Likewise if there’s no ownership.

You cannot tell smart people what to do without providing Why. If engineers don’t have a clarity of purpose they will likely build a wrong thing.

Slow down the desire to build something quickly and apply: North star framework, Impact mapping,
Opportunity solution tree (Continuous discovery habits) and the “double diamond” design methodology.

Without safe environment where people can speak up, we miss out on valuable feedback. Anything other than re-enforcing comment is seen as an attack, as are alternative ideas.

If a technical lead makes you feel stupid or can’t explain in human language then he needs a training.

Don’t let tech team run wild. Technology is the business. Architect’s main task is problem prevention.

Code is a liability, the system is the asset!!!

Focus on creating long term value over short term gains! Well architected system and culture of problem prevention rather than incident management.


The book encourages to use Wardley mapping to identify what to build or buy.

[Tõnu Vahtra · Rating 3 out of 5]

ITSM meets Agile (Theatre) meets Collins meets Amazon with Wardley maps, diversity and carbon footprint reduction to glorify Cloud and serverless - I think Collins deserves better. This book seems to be a bit all over the place with keywords which do not work to strengthen the case for the overall narrative (value flywheel). It feels a bit like a series of blog posts or a draft that has not yet been logically integrated together. It makes general references towards Amazon, but the companies mentioned as examples are mostly small or not widely known for the general public which tends to be a general weakness of such books, I gues big unicorns want to be the stars in their own book and not an example of many, also their practices are not so generally applicable. I also felt that the role-plays were trying mimic The Unicorn Project style but felt extremely artificial.

Some "interesting" keywords and phrases that I wrote down for myself:
*Time to value over TTM
*Sociotechnical systems view (it's a real thing and today's system architects should focus on this and problem prevention and ensuring quality standards are met VS design of the actual technical solution)
*Problem prevention culture: rewarding those who prevent problems VS who solve problems; celebrate testing with chaos.
*Technology Theater VS Agile Theater VS (fill in the blank) Theater as a term.
*Engineer is someone who solves problems and brings value to the business.
*Strategy offsites in majority cases are not more than alignment exercises, not really fit for strategy creation.

"we in IT are sometimes so fixated on saving costs that we forget about making money"

[John · Rating 3 out of 5]

This book has a lot to say about running a modern technology organization, and I got a lot out of it. The book is attempting to help the reader increase momentum towards a goal or "north star." To understand the book, you have grasp three core topics. I'm going to spell these out a bit, because the book is pretty bewildering if you are trying to understand the underlying approach. What the book is trying to do is provide a means to obtain situational awareness so that you can make a decision about what to do next (chapters 9-12). Unfortunately the book is so poorly organized that you pretty much have to excavate what I'm about to say from the book: The book is not going to just hand over the goods.

I feel like I can't even begin to discuss the liabilities of this book unless I play out some of structure.

Anyway, here are the three key topics that support so much else:

(1) Value chains. A value chain describes the relationship between top-level needs and what supports those needs. Each component that supports a top-level need is a "dependency" (p. 35); and each dependency can have its own dependencies. The idea here is to articulate the dependencies between components. At the top of the value chain is the "anchor" (p. 34). The anchor might be a customer (p. 35), a user (p. 41), a stakeholder (p. 43), an engineering leader (p. 140), or even the CEO (pp. 26-28) / the business owner (pp. 53-60).

In this book, components closer to the anchor are more visible. "The higher the component, the more the user can see it. A web page might be at the top, while a database or server might be near the bottom" (p. 33). Components are the bottom are invisible to the anchor.

(2) Meanwhile, we want to understand the evolution of each component. Components go through four stages. Genesis, which is "poorly understood, and uncertain" (p. 33). During Genesis, the component is unprecedented and a thing of wonder. Then, as the component evolves, it becomes something that is Custom Built, then something we can call a Product (that we can rent to others), and eventually it becomes a Commodity or Utility: A component so well known that we would buy it off the shelf (and not build it).

(3) Then there is a methodology for situating components according to these two dimensions. More on that in a bit.

If these seems interesting to you, I would advise going straight to pp. 40-41. Using these two aspects of any component, you can put each on a grid with visibility top-to-bottom, and evolution from left-to-right. This can form the basis for a discussion as you ask yourself the question: Of our critical components, which ones are most visible, and how close are they to commodities? In this section, the authors say: for "the new machine learning component" "the user is aware of it, and it's Custom Built." Another example: There old contractor-written (custom) software that the user can't see. What conclusion do we draw from this: "We need to move this. The time it takes to maintain it is blocking other things" (p. 40).

I like this. This scheme helps us understand what is mature in the organization and, depending on its visibility, whether the User really cares about it. In that bit about the Java component, the authors note the time element. This is good. You can see something on the grid and get a feel for what needs to evolve -- and whether you can or not (because the user can or can't see it).

Having said all that, we don't get a lot of language around making "build" vs "buy" decisions, but in a lot of ways that's what's being talked about.

So here's the key point (not pithily articulated so far as I can tell): If your User can't see a component and you can evolve it so that it is no longer customer software and can possibly buy it as a commodity, you can save yourself a lot of headaches: The commodity should be cheaper (especially if you think of the savings of not building custom software), and another company will be responsible for keeping it maintained. This ultimately simplifies your company, and makes your own tech easier to maintain and secure. This will reduce time to value (Chapter 6).

I think what I've said so far is really the core of the book.

Having said all of that, the book is considerably more sophisticated than this simple grid. The major innovation here is that this grid is no mere SWOT analysis. Reason: It is trying to take into account time. A SWOT analysis just gives you clarification for a moment; but this scheme with "evolution" on the x-axis means that you can think about all of your components moving and evolving. To understand the authors' distinction between SWOT and their grid, look at pp. 17, 50, and 222.

Here's how it gets more subtle and nuanced. That grid is pretty simplistic. The disposition of components into that grid is just the starting point. A more elaborate version of the grid is called a Wardley Map. It's the same idea, but the Map provides some means to see how everything fits together. First off, you you can draw lines between the dependencies, and see that one component depends on two things, one that is evolved more than another. This can provide the basis for a discussion about whether we can tolerate writing custom software that supports a component (p. 35). You can also group selections of components that are related, and see, for instance, that there are too many dependencies are things that are "custom" (i.e., costly) (pp. 36-37). There are also "pipelines": This is when you identify a critical component and want it to evolve (see pp. 38-39). You can also note on the x-axis (evolution) when a component gets blocked and can't evolve (pp. 57-59).

So far, so good, though the concepts above are not communicated very coherently. Let me return to some themes in the book:

The Value Flywheel Effect keeps coming back to serverless computing. The book argues that the purest form of the highly evolved component is functionality where your cloud vendor provides the entire ecosystem for the tiniest bit of business logic. This may be true, but the book is really confused by its attempt to articulate all of this mapping stuff -- but also this argument about cloud computing. The main reason that this is so confusing is that the authors know that serverless is just an illustration of getting to a highly componetized state. They even say "serverless is not the point!" but that only comes on p. 158. Wish you had told me earlier.

Another worrisome aspect of this book is the answer to the "why" question: Why do I want I want such highly commoditized invisible components? Well, here is the reason. If you have older custom-built software, you are going to discover that it can no longer evolve in the face of regulatory and security concerns (see p. 224). This strikes me as a massive and correct point. But why is it buried? I have no idea.

I think in a lot of ways what I've said above is the whole game. One way to read this book is to take account of the simplification I've presented above, then read all of Chapters 1-4. Then I would recommend jumping to the account of the BBC (chapter 20). The chapter on the BBC provides the operational justification for serverless, but interestingly barely if ever mentions Wardley Mapping.

What is the rest of the book about? Mostly it's about how to run the meetings for the Wardley Mapping and how not to get too caught up in the technique. For one thing, it's a group activity and a means to an end. You want to be loose and use the strategy as much as seems appropriate for your own desire for situational awareness. Along the way there are sections are other topics that are, basically, a total distraction from the core of the book. For example, sense making (pp. 85-86; this comes from organizational theory), the double diamond (pp. 72-73), Cynefin (p. 134), complex adaptive systems (CASs, p. 134), etc. Anyone who has been paying attention in recent years has read about some of these things, and they don't really add to the argument. It kind of seems like they're just thrown in ("oh, we should say something about Cynefin!").

I don't know why this book ended up this way. Besides the organization, another thing that makes this reading experience really tough is that the Figures -- the Wardley Maps themselves -- are just too damn small! For whatever reason, they are inset and don't get to use the full width of the page. Maybe it's better on Kindle -- but the printed version, which I am reviewing here despite the fact that GoodReads doesn't have the print version in its system yet, blocks the reader from understand the pith of the figures. I think the publisher, IT Revolution, could do readers a favor by publishing all of the figures on their web site. Now let's see what the other reviewers say: I bet there will be a lot of 3's for this one.

[Chris Austin · Rating 3 out of 5]

I was excited to read this since it aligns with where my interests have been shifting, especially around driving sustainable business value and using Wardley Maps to build consensus through conversation around the current state, discussing options for evolving the system, and identifying inertia/blockers. The introduction was also encouraging since I related strongly to it.

The Pioneer/Settler/Town-Planner model is useful, as is the general idea of a value flywheel. The Wardley Mapping sections could have used some more discussion around the design principles used in each, and the diagrams would have been much better examples if the text around them used the same labels (e.g. labeling something S1 in the diagram but having completely unrelated names in the text). I was also a bit disheartened to see that some areas were inconsistent - in many early examples the move to serverless is shown as that capability shifting to the right, towards commodity, but then in later examples it was presented as a pipeline moving from right to left, from legacy cloud to modern cloud. There wasn't enough narrative to explain why moving to serverless was a shift to the right in some, but to the left in others. I have to assume that it's because the team did not have serverless experience yet, so their practice would be in the genesis area initially.

Overall this was a 3.5 for me. There was a bit too much focus on serverless (I was looking for a business value and mapping book, not serverless advocacy), and it was a bit dismissive of OKRs (yes, bad ones exist, but that's a universal truth). Chapter 10 didn't add anything to the book for me - I'd recommend reading "Sooner, Safer, Happier" for that piece instead, along with "Team Topologies" and "Agile Conversations".

[Hans De Leenheer · Rating 3 out of 5]

There are two excellent things about this book;
1) a practical guide into how a team has learned to use Wardley Mapping. It's not just theory and not entirely specific, so many people would benefit from the steps this team has taken in learning how to practice Wardley Mapping.
2) the sheer amount of books where the author gets their ideas really is the pinnacle of what you should be reading today as a Product Strategist.

Having read most if not all the books the author mentions, and having practiced Wardley Mapping many times already, the promise of finding a new paradigm behind "the value flywheel" was extremely thin for me in the end. There really isn't anything new in this book other than combining what already exists. Therefore, for me, I can give no more than 3 stars. Someone new into product strategy might very give a 5-star rating!

Also; if you're not really a fan of serverless computing, you'll find the 7000 mentions of this technology quite boring soon ;-)

[Jason J · Rating 4 out of 5]

Good but gotta have more Serverless

Overall, I liked the methodology and presentation of the framework. Having worked with some of the companies mentioned, I have seen first hand the impact this content has had. I do wonder if the AWS Lambda team received a royalty for every 5 mentions of serverless.

[Jeevan Dongre · Rating 4 out of 5]

This is not just a management book. One needs to be at the edge of the digital transformation to understand and even empathise with the book. It is mostly meant for technology leaders.


If your KRA or OKR is about the digital transformation, go pick up this book and read!

[Dino Jurina · Rating 3 out of 5]

Was really hyped on the beginning of the book, but it got very repetitive.

[Daniel Gradl · Rating 3 out of 5]

Interesting ideas but mostly an advertisement for serverless, as, and wardley mapping.

[Christoph Kappel · Rating 4 out of 5]

The book itself is a good mix of ideas and got me a nice introduction to the art of Wardley Maps.

I still need to figure it out for myself, but especially the included dialogs and the incremental maps are a great help.

In general the change of mind from tech to sociotech is something our industry needs to manage in the years to come. And this book might help to make the first and right steps.