If You Want to Transform IT, Start with Finance

tl;dr – ‘Money Flows Rule Everything Around Me’

When talking about IT transformation, we often talk about ‘culture’ being the problem in making change, but why stop there? If we take a ‘5 whys‘ approach, then we should go deeper. So, where can we go from ‘culture’?

Here I suggest we should consider a deeper structural cause of cultural problems in change management: how money flows through the organisation.If you want to change an organisation, you need to look at how money works within it.

I talked a little about this in a recent podcast.

Picking up two old threads

In this post I want to pick up on two threads that have cropped up in previous posts and bring them together.

An aside I made in this somewhat controversial previous post:

Command and control financial governance structures just aren’t changing overnight to suit an agile provisioning model. (As an aside, if you want to transform IT in an enterprise, start with finance. If you can crack that, you’ve a chance to succeed with sec and controls functions. If you don’t know why it’s important to start with finance, you’ll definitely fail).

was picked up on by many people. They wanted to know more about why I was so vehement on that. Unfortunately, it was a throwaway line, there was too much to unpack, and it wasn’t clearly formed in my mind. But like many throwaway lines, it revealed a thread that might be good to pull on.

2. ‘Culture – be specific!’

Previously I was inspired by Charity Majors (@mipsytipsy) to write about my frustration at IT’s apparent inability to probe deeper than ‘culture’ when trying to diagnose problems in technical businesses.

Since then, I’ve spent more time in the course of my work trying to figure out what’s blocking companies from attempting to change, and increasingly have worked back from people and process to sales and funding.

The argument

The argument breaks down like this:

• To achieve anything significant you need funding
• To get funding you need to persuade the people with the money to part with it
• To persuade the people with the money, you need to understand what they value
• To understand what they value, you need to understand how their cash flows work
• To understand how their cash flow works, you need to understand:
  • your customers/clients and how and why they part with their money
  • the legal and regulatory constraints on your business and how it operates

Or, put more engagingly:

Any significant decision or change therefore gets made in the context and constraints of how and why money is distributed to, and within, the business.

There is also a more visceral personal level on which money flows can change or affect behaviour. Compensation, threats of firing, and bonuses can all drive good or bad behaviours. Or, as it’s been put pithily before:

When you’ve got them by their wallets, their hearts and minds will follow.
Fern Naito

This is not to say that all culture is 100% determined by money flows. Individuals can make a difference, and go against the tide. But in the end, the tide is hard to fight.

There is a precedent for this argument in philosophy. Karl Marx argued that societal culture (the ‘superstructure’) was ultimately determined by material relations of production (the ‘base’). From Wikipedia:

The base comprises the forces and relations of production (e.g. employer–employee work conditions, the technical division of labour, and property relations) into which people enter to produce the necessities and amenities of life. The base determines society’s other relationships and ideas to comprise its superstructure, including its culture, institutions, political power structures, roles, rituals, and state. The relation of the two parts is not strictly unidirectional, Marx and Engels warned against such economic determinism as the superstructure can affect the base. However the influence of the base is predominant.

Wikipedia, Base and Superstructure

You have nothing to lose but your blockchains.

What does this mean for IT?

The theory is all very interesting, but what does this mean in practice?

There is a very common pattern in software companies’ histories (especially if they were founded before the Software-as-a-Service age), and understanding their flows in terms of their histories can explain a lot about how and why they struggle to change. I have seen it multiple times in the course of my work, both as a consultant and as an employee.

The four stages

Stage I – hero hacking

When a software company starts up, it often builds a product for a few big customers that sustain their cash flow in the early days. These times are a natural fit for ‘hero hackers’ who build features and fix bugs on live systems all night to help get that contract signed and keep their customers happy.

Your customers are few, so all are important. They demand features peculiar to them, so you keep delivery times low by having customer-specific code, or even forking the entire product codebase to keep up.

Stage I – customer asks, customer gets

Stage II – pseudo product

Now that you have some customers who are happy with the product, its features, and your staff’s dedication to keeping them happy, more customers come along. So you sign contracts with them, and before you know it you have numerous customers.

Of course, you’re selling your services as a product, but the reality is that it’s a mess. Each installation is more or less unique, and requires individual teams to maintain or develop it.

This is where things start to get more complicated.

• Features grow and diverge for different customers
• Features get built in parallel by different teams for different customers, sometimes similar, but not the same
• Database schemas diverge
• Porting features sounds trivial (it’s a product, right?) but gets messy as code is passed around different codebases
• Attempts are made to centralise or share core functionality, but this can slow down delivery or just get too complicated to maintain

Grumbles from customers and between development teams start to increase in volume.

Stages IIIa and IIIb

The last two stages are closely related. Either or both can happen in the same company. Stage IIIb doesn’t necessarily follow from Stage IIIa: it’s really just the same problem in another form for the SaaS age.

Stage IIIa – we want to be a product company

As you get more and more customers it makes less and less sense to keep working like this. Customers start to complain that their system is expensive to build on and maintain, as feature x requires ‘integration’ or some kind of bespoke delivery cost for their deployment. At this point someone says: ‘Wouldn’t it make more sense for us to maintain one product, and maintain that centrally for multiple customers? That way, we can sell the same thing over and over again, increase the license cost, reduce delivery cost and make more profit.’

Stage III is where the cracks really start to show, and we go into how and why this happens below.

Stage IIIb – we need an internal platform

As the (pseudo or real) product offering grows, or as you increasingly offer your software as a service on the cloud rather than a package delivered in a data centre, you invest heavily in a ‘platform’ that is designed to enable deliveries to be faster, cheaper, and better.

You might even set up some kind of platform team to build these cross-product features. It’s a similar justification to the product one: ‘Wouldn’t it make more sense for us to maintain one platform, and use it to deliver products for multiple customers? That way we could reduce cost to customers, and increase quality at the same time.’

Where does it all go wrong?

So how do things go wrong?

From Stage I to Stage II, things are relatively smooth. Everyone understands their role, and the difficulties you face are tough, but tractable and clear. As you go to Stage IIIa/b, that balance tips. Everyone seems to agree what the goal is, but in reality:

• Customers still want their new features fast (and faster than their competition), and don’t want their requests to be ‘put on the backlog’
• The merging of the codebases seems never to happen
• Attempts to write new, unifying products are difficult to build and sell

All of these difficulties and failures can often be tracked to money flows.

Similarly, with platform teams:

• The business wants to build a platform, but balks at the cost and struggles to see the value
• The business has built the platform, but doesn’t accept that it needs a team to sustain it
• The business has built a platform for reliability, but ‘heroes’ still want to fix things by hand, either for the glory or by force of habit, rather than quietly tinker with a CI/CD workflow

Again, often all of these difficulties and failures can be tracked to money flows.

How this happens – money flow patterns

These difficulties come down to challenges moving from project to product, which in turn come from how money moves into and through the business.

Stage I money flows – hero hacking

In Stage I, the money flows are simple:

• Team builds software in cheap offices, often on low salaries with the promise of growth to come or fun, adventure and really wild things
• The first customers are won because the product does something cheaper or better than the competition
• The money from the first customers pays for nicer offices and more teams
• More money comes in as customers demand modifications or maintenance on the delivery

The reality is that at Stage I there is no real ‘product’. There are projects that deliver what the customer needs, and the business is happy to provide these as each individual project is profitable (either on a ‘time and materials’ or a ‘fixed cost’ basis), resulting in a healthy profit at the end of the year.

But as each customer’s codebase and configuration diverges, those features and maintenance patterns cost progressively more. But no matter, the business has a simple model for cash flow: keep the customer happy and the money flows in, and each customer gets the development and maintenance attention they pay for.

Stage II money flows – pseudo product

In Stage II, the money flows are much the same, but the cracks are starting to show:

• Customers are still happy with the attention they get, but:
  • Projects seem to take longer and cost more
  • Features that are apparently part of the product can’t be just ‘switched on’, but require ‘integration time’
  • The quality of the software feels low, as fixes are required because of the extra work required to integrate changes

At this point, customer executives start to say they yearn for a product that has a more predictable quality to it, and a roadmap, and is cheaper and feels less bespoke. Can’t we all just pay a lower annual fee and get a steadily improving product?

At the same time, the owners of the business are asking themselves whether they couldn’t make more money the same way: instead of 15 customers, wouldn’t it be great to have 150, all taking the same product and paying (say) half the cost they are now? That kind of margin looks very tempting…

The result is that changes in external demand produce a desire to change the development model.

Stage IIIa – we want to be a product company

In Stage IIIa (and Stage IIIb), if the money flows stay the same as in Stages I and II, becoming a product company will feel extremely difficult. This is felt in a number of ways, but here is one common story:

• The company sets up a product team that is responsible for productising the various disparate codebases and hacks that made up each customer’s bespoke setup.
• This product team tries to corral the project teams into sacrificing short-term customer delight for long-term product strength and consistency.
• The product team spends a lot of money doing everything required to make a product, but customers are proving less willing than they said to believe and buy into the product. They find it difficult to compromise on delivery times and support responsiveness in exchange for a cheaper product.

Productisation debt

Time and again, development and product teams tell management that they have to make a call: sacrifice customer satisfaction for the product, or build up ‘productisation debt’.

• Do you tell your biggest customer they have to wait another month for a feature because the product has a release cadence, and you are not willing to do a hack job for the sake of expediency?
  • However much money they’re willing to throw at it?
• Are you willing to watch the relationship with that customer deteriorate over several very difficult meetings as you explain to them that they no longer call the shots?
• Are you willing to risk losing them completely?
• Do you tell them they suffered an outage because of a change made for another customer last release?
  • Will it be any comfort to them to know that this feature is now available to them (fully fixed in the next release)?

The result is it takes much time and money than expected to get a successful product model going, while the older money flows continue to push the organisation towards its old habits and culture. Why trade the feel-good factor of giving the customer what they want now for the slow burn of deferred rising profits in the future?

On the face of it, the arguments look simple: your profit margin will go up if you productise. The reality is that finance (and therefore the executives, shareholders, salespeople, HR, reward systems etc) have got used to the project-based money flows and cadences and find them incredibly hard to give up for some uncertain but better distant future.

What you end up with is a more complicated version of Stage II (simplified here with only two customers for ‘clarity’).

The product reality – customers and finance want to keep the relationship the same

Rather than your customer teams fighting with the customer to give them what they want, you now have more forces acting in opposition within your organisation, including:

• The product team fights with the customer teams for resources
• The customer team fights with the product team over productisation calls
• Finance fights with the product development team for resources

The result is likely to end in failure for your product strategy.

Stage IIIb – we need a platform

The ‘platform’ stage is really a variation on the product phase (Stage IIIa), except that this time the customers have no visibility of the productisation or automation of what they’re sold. This is effectively a product built for an internal customer, the finance team, who hope for money to be saved per project over time after an initial investment.

Platform team money flows

This can be easier or harder to achieve than Stage IIIa depending on the attitude of the internal customer vs the external customer.

Again, it can be affected by the details of the money flows: if the work to build a platform is on the books as capital expenditure (as opposed to operational expenditure – see below), executives may well ask ‘is the platform built yet?’ This question can baffle the team, as they’re well aware that such a platform is never ‘finished’, as there are always efficiency-generating improvements to make.

In both Stage IIIs, if the benefits of the platform are not quantified in financial terms from the start, then getting the funding required becomes difficult. This means that you should:

• Measure the cost of delivery per project pre-platform, so you can compare to post platform
• Ensure that the cost of the platform is ‘baked in’ to the sales cycle, so that there is a concept of platform profit and loss that can also be measured
• Set expectations that ‘profit’ may be a long time coming, as is the case with most capital investments. Would you expect to build a house and start turning a profit in 1/20th of its lifetime?

Money flow patterns

The above patterns are common to small-medium sized software B2B software businesses, but they are not the only patterns that drive cultures and behaviour contrary to their stated aims.

Here we list some significant patterns and their effects on culture, delivery and operations.

Opex vs capex

Opex (operational expenditure) and capex (capital expenditure) are two different ways that business spending can be categorised. Briefly, opex is regular expenditure, and capex is significant, long-term expenditure.

Software projects’ costs have traditionally been categorised under capex, but as cloud computing has arisen, more and more of their costs have been moved to opex.

The designation of spending can make a significant difference to how work is treated by the business.

• They may have different approval processes
• There might be more money in the ‘capex pot’ this year than the ‘opex pot’ (or vice versa)
• Your business may mandate that opex costs are preferred over capex costs because they see the management of assets as a burden
• Or (as seen above) if the building of a software platform is considered a capex, then it might be considered as ‘done’ rather than as something that needs to be maintained as an opex

There are tax implications to both capex and opex that can further complicate discussions.

The line between a capex and opex purchase is not always clear, and most projects will have some kind of mixture of the two that makes working out the effect on the business’ profit and loss account for that year difficult.

Project-based funding

Project-based funding is where money is allocated to a specific project and/or outcomes, as opposed to product-based work, where funding is usually allocated continuously. Project funding may be on a ‘time and materials’ or ‘fixed cost’ basis.

The cultural patterns associated with project-based funding are:

• Pride in customer service and satisfaction
• Prioritisation given to delivery over long-term stability
• Scant attention paid to maintenance costs
• Mounting technical debt and increasing complexity over time
• Lack of co-ordination / duplication of effort between project teams
• A ‘hero’ culture, as fast fixes to problems that arise gain attention over slower improvements
• Perceived higher value for customer-pleasing project work over central and internal infrastructure work

Yearly funding cycles / business unit funding

Yearly funding cycles are where money is allocated to projects or products at the same time

every year. This is normally driven by accounting cycles, which are almost always yearly.

Yearly accounting cycles make a mockery of technical teams’ attempts to be truly ‘Agile’ in response to business demand. If a released MVP product flies off the shelf in February, then you can’t get funding to scale it up until January next year.

Strict yearly funding cycles are also often associated with centralised funding within large business units that sit within larger organisations. This can make working in an agile way even harder, as there are two levels of politics to negotiate before more funding can be gained for your team: your own business unit’s internal politics, and the business unit’s relationship with the central funders.

First mover bears the cost

Individual business unit funding also makes it significantly harder for any kind of project whose benefits cut across business units to get off the ground, eg ‘Platform’ or ‘Infrastructure’ work. Costs for such projects are typically borne by a single centralised business unit that is perceived as delivering little business value, so is starved of funding.

This can also be characterised as a ‘first mover bears the cost’ problem.

No money for hard-to-measure benefits

Some organisations take a strict view of cost/benefit for any given expenditure, insisting it must show some direct, tangible return on investment.

In general, this is sensible, but can result in difficulty getting funding for projects where there is not a readily measurable return.

For example, what if your investment:

• Helps retain staff
• Enables more dynamic and faster business outcomes
• Reduces the risk of a failed audit

Is there a way to measure these, or even the language to state them as benefits at all?

Many businesses have no leeway for these qualitative benefits to factor into business cases.

What is to be done?

Whenever you want to debug a misbehaving program, you want to get to the root cause. Workarounds are unsatisfying, and ultimately result in further problems as the workaround itself shows its failings.

I feel the same way about ‘cultural problems’ in organisations. It’s not enough to put posters up around an office imploring people to ‘be more agile’, or instruct people to have a daily stand-up and a two week work cadence to drive cultural change.

No, you have to go to the root of the structures that drive behaviour in order to make lasting change, whether it’s on a personal level or organisational. And my argument here is that the root of behaviours can be traced back to money flows.

So, what can you do about it? Here are some suggestions:

• Involve the CFO/finance team in the change program from the start
• Explain to finance the reality of what you’re doing
• Learn to speak the language of finance – talk to them

Most important of all, if you’re going to change the behaviour and goals of an organisation, you are going to have to change the way money moves around it. As Einstein is [wrongly said to have] said, doing the same thing over and over and expecting different results is the definition of insanity.

If you can engage with finance in an open and enquiring way, then together you can make lasting change; if you don’t, then you will be fighting the tide. Just ask Marx.

A version of this post originally appeared on the blog zwischenzugs.