Thread by @swardley

X : What do you mean by capital flow with maps.
Me : Hmmm, best to show you with a map.

We can add metrics to this i.e. $0.05 for a cup (1) and by looking at flow (2) we can create an income statement (3) but don't forget that stocks not only need replenishing but they can depreciate with use and over time (4)

We can then challenge the map i.e. ask why are we custom building kettles (1), I'll assume it's a debt to some past practice. We can add a more industrialised kettle (2) and examine the impact (3) of this.

Now before we just simply go and change things we need to recognise we are likely to face inertia to change (1) but we can develop a plan (2) that considers this, the benefit of change (3) and any investment needed in standard kettles (4)

By sharing the map then others can add other forms of capital we weren't aware of i.e. maybe the custom built kettle adds magic (1) with gives immortality to the drinker, an unquantified value (2). This provides a brand exclusivity (3) which supports the "high" tea price (4).

i.e. if we invest in the plan, along with the cost of buying standard kettles and dealing with inertia (1) then the net effect is we lose exclusivity and our price has to drop (2) leaving no net benefit at all (3). We've just wasted money for no good reason.

X : I was thinking more capital flow with serverless, not tea.
Me : It's the same. With billing per function (1), we can measure capital flow, create income statements (2) and determine what to refactor (3) and question the inertia (4) and whether this is a good idea or not?

... there is whole new set of co-evolved practices that will emerge with serverless and those practices are likely to combine finance and development. It's why you should be bringing your CFO to a serverless conference. It's going to change how you monitor, operate and invest.

In the serverless world, refactoring your code has directly measurable financial value. You can measure the financial cost of paths through applications. You can manage operations by examining capital flow. It's a very different world from that of infrastructure and containers.

X : Can you use maps to measure the value of the system or business?
Me : That's very tricky. First, we have to define what we mean by value and then we have to accept there are multiple components to it ...

i.e. you have the capital flow which represents the generating value (1), you have the nodes themselves i.e. stocks of capital (2) which also represent value (for exchange) and you have future potential (3) i.e. something that could become a product sold to others.

The problem with future potential is the degree of uncertainty i.e. from the above map, take [A] ... on the evolution curve it is highly uncertain. As it evolves [B] it becomes less uncertain but it has less future potential (it is more ubiquitous to its applicable market).

... there is alas a correlation between uncertainty and future potential which is why we have to gamble. As it evolves however, it has a larger market and potential is replaced by generating value, though often companies fail to capitalise on this (more competitors etc).

The problem with valuing by stocks is that what was once an asset [A] can become a liability simply through external market movement [B]. This is beyond simple depreciation. The market effects the value of your assets and can turn into liabilities or debt (1).

The problem with valuing by capital flow is, it's not isolated but relative to the market. In other words, if your capital flow is ineffective then you're a target for attack by others.

For all these reasons when you're trying to examine value from capital flow, stocks and future potential then you need to take into consideration context (how evolved components are). It's why I find P&Ls, Cashflows and Balance Sheets as fairly hopeless for valuing a company.

In fact, personally, having spent far too long writing global chart of accounts and dealing with finance, I find most of the financial industry lacks context and is generally busted. For more on value and maps, I'd suggest following @kda (aka @wardleymaps).

X : You think finance is busted?
Me : I think most things are busted. Finance lacks context, so can't effectively measure capital flow, stocks and potential future. Everything built on that is a house of cards but ...

... I also find project management to be busted. This tendency to one size fits all methods, again because of a lack of context, results in continuous failure and endless arguments, but ...

... I also find HR to be busted. This belief in a single size fits all culture, the inability to recognise not only aptitude (skill) but attitude (cultural style), to plan a path forward on how things change, but ...

... I also find strategy to be busted, the inability to distinguish between climatic patterns and context specific play, the inability to see the obvious changes, the memes, the endless memes, but ...

... I also find the business to be busted, the inability to communicate across multiple groups, to bring these components into a cohesive whole, to understand the context, but ...

... there are some bright spots. There's some people who really get it and most (not all) of those can be found in Government. I'm really impressed by some of the work in Gov e.g. the FDA, go follow @JuliePierce77

However, most of what I see in the commercial world is ... well, I like to think that business is still in its infancy and still learning. I cannot emphasise enough how important context is. Understand your landscape, improve your situational awareness.

X : You often talk about spend control. Why does that matter?
Me : Ok, let's start with that map examining capital flow for our hail car service ...

... from the example, it's far better to use a service that provides the car.getProfiles() function than to use our own custom built version. We have technical debt to the past and inertia to change (1) ...

... obviously this is where we want to be. However, how do we get there?
X : Just make the plan and move?
Me : There are some complications, especially in cell based structures. Let me explain ...

... let us strip away the financial figures and capital flow and look at the system. Now everything has a past, it evolved from somewhere (1). So let us focus on hailCar() and location.verify(). Let us go back in time to when the hailCar service was just a twinkle in your eye.

... so you're working for a company that provides a location.verify() product and you've got this idea for a future business of a hailCar service (1) that is built upon the company product and other components ...

... now let us suppose that the company has seen a gap in the market, realised that evolution occurs and has decided to provide location.verify() as a utility service (1) to the wider public which we will call others (2)

... this is great because when the company decides to build the hailCar service then we can use the new utility service [B]. We're certainly not going to custom build our own [A].

... so a team is built (this company uses small cells e.g. two pizza teams) and the utility service is launched. At some point in the future, someone re-reads your plan for hailCar service and decides to go for it. You're off being busy somewhere else on something exciting ...

So a new team 1 is created to build the hailCar service. It's an autonomous team but alas team 1 either doesn't know about team 2 (it's a large company) or thinks it can do better and so it custom builds its own location.verify() component.

The location service of team 2 uses a "big data" product which is built on utility compute and storage. All seems sensible. It probably doesn't know about team 1 and may not even care ...

... unfortunately team 1 will also need a "big data" system. Since it likes custom building it has done so but fortunately they weren't daft enough to build their own utility compute and storage but used the public services ...

Now each team can justify to some extent what it has. Team 1 looks at its map and reckons it is sensible (well, to the members of team 1)

... team 2 can do the same thing. Its map looks fine from its perspective ...

... of course when you look at both maps ... horror of horrors ... custom building what is a commodity (1), duplication galore (2) ... multiply this by 500 teams and you can have a real mess on your hands.

... this is where spend control comes in. Each team before building their project submit their maps to spend control. At the beginning the purpose of spend control is to remove that bias and duplication. To challenge people custom building the same thing over and over.

... you can rely on people discovering through conversations over the water cooler or architect meetings or other such devices but in general I find them woeful. I've seen many examples of duplication get to 200x in large corporations. You really need spend control and maps.

ideally, in this case spend control would be challenging team 1 on building the location.verify() component rather than consuming the component from team 2. The goal is to avoid the waste. But there's more ... there's always more ...

I talked about the "old days" and how I use to organise, and how I developed and used the Pioneer - Settler - Town Planner model of organisation -

https://twitter.com/swardley/status/1087511545091899392

... well ...

... you could use the map to simply say, we need a group of pioneers in team 1 and a group of town planners in team 2 but ... the other point of Spend Control is learning especially climatic patterns and hence anticipating change ...

well, we really should have a team of settlers replace team 1 as the component is becoming a product(1), the original pioneers go create something new (2) and we really want to think about a new team of town planners to build a utility service for big data (3)

I know everyone runs around shouting "two pizza" teams etc but if you don't have a mechanism of reducing duplication & bias (e.g. Spend Control) and industrialising components (e.g. PST) then you're going to end up with a tower of babel and an utter mess over time.

In the absolutely worst cases, you can have many layers of custom built on top of duplicated custom built which can create all sorts of stability issues or even have teams leave creating orphaned components (1). How you manage this is up to you, but you will need to.

X : Does spend control have to be a group of people?
Me : It can be distributed. You just need a shared store for maps and many eyes with some reward mechanism. You could even automate aspects. You're going to have to do this at scale or find some other way.