From the book Follow the Money
Follow the Money Patterns
61 patterns and 9 anti-patterns for working with the money flows that shape software architecture and transformation: who funds what, when the budgets are set, and what people are measured on.
- 1 Context: Money Smells 15
- 2 Diagnosis 9
- 3 Working Within the System 13
- 4 Reframing the Conversation 8
- 5 Changing the Flows 11
- 6 Fight, Fold, or Leave 5
- 7 Anti-Patterns 9
Context: Money Smells
These patterns describe situations rather than actions. Each one is a mismatch between how the money flows and how the work is organized, and each explains a problem that engineers usually experience as something else: a turf war, a platform that can’t keep up, a reorganization that didn’t stick, or a cost line that won’t stop growing.
About these patterns →
Funded by One, Serving Another
A team is paid for from one budget but delivers its value to teams under other budgets, so the people who see its cost and the people who see its benefit are never the same.
Revenue Gravity
When a few large customers pay for the work, the organization forms around them, and shared code ends up with nobody paying for it.
Budget Silos
Each business unit buys or builds the same function from its own budget, because nobody is rewarded for using someone else’s.
Platform as a Cost Center
A platform funded as overhead serves teams that sit in profit centers, so it is judged on its cost while its value is counted elsewhere.
Done in the Accounts, Alive in Engineering
Once software is capitalized and “complete,” the accounts treat it as a depreciating asset, while engineering still has to maintain and extend it.
The Consumers Aren’t the Payers
When the people consuming a resource don’t see its bill, consumption grows unchecked.
Two Budget Masters
A team reports to one person and is paid for by another, and the team follows the money.
Structure Changed, Money Didn’t
A reorganization that leaves the old budget lines in place fails to change behavior.
Wooden Dollars
A central service is expected to “sell” to internal customers who can ignore it, and neither side can really walk away.
The Invisible Benefit
The value of the work lands on nobody’s P&L, so as far as the budget holders are concerned it doesn’t exist.
The Annual Budget Lock-In
Decisions about money are made once a year, and anything that arrives after the round has to wait for the next one.
The Unaligned Bonus
The budget holder’s targets don’t include what the team delivers, so the work is ignored or quietly dropped.
The Overmighty Patron
One person controls the money, or the route to it, and the organization’s strategy moves whenever their attention does.
The Imagined Regulator
A control function blocks or reshapes change in the name of a requirement that no actual patron has made.
The Shareholder Transformation
A change program whose only real patron is the investor, so it can succeed for shareholders while delivering little to anyone else.
Diagnosis
These patterns describe ways of finding out how the money really flows through an organization, as opposed to how the org chart says it flows. They come from the analysis described in Part III: preparing the mapping (Chapter 10, “Preparing the Analysis”), mapping the patrons (Chapter 11, “Mapping Your Patrons”), mapping the organization and the money (Chapter 12, “Mapping the Organization”), following the work (Chapter 13, “Following the Work”), and reading the architecture (Chapter 14, “Architecture and Diagnosis”).
About these patterns →
Secure the Sponsor
Before starting a diagnosis of how money shapes the organization, find someone with the authority to give it time and attention, and confirm that they want a diagnosis rather than a validation.
Agree the Goal and the Boundary
Before mapping anything, agree with the sponsors on what the analysis is for and which part of the organization it covers, and separate the goals they state from the ones they don’t.
Map the Patrons
Have the group agree on who the organization (or team) really serves, rank those patrons by influence, and link each one to what they expect to get back.
Find the Gatekeeper
Map the people and functions who can block, delay, or reshape the work without funding it, and keep them in a separate column from the patrons.
Overlay the Money
Draw the organization as people experience it, then draw where each team’s money comes from and who really directs its work on top of it, and look for where those layers disagree.
Follow the Work
Take one real piece of work and trace every step from the decision to do it to its delivery, and find where it waited and who owned each gate.
Predict Before You Draw
Before the architecture workshop, write down what the money flows say the architecture should look like, keep it private, and compare it with what the group draws.
Draw It, Don’t Present It
Have the people who build and run the system draw it from memory, rather than presenting the official architecture diagrams.
One-on-Ones Before Synthesis
Before drawing conclusions, meet privately with the people the workshops couldn’t hear from, or couldn’t hear freely.
Working Within the System
These patterns are the cheapest levers: ways of making room for change while the money flows stay exactly as they are. They come from Chapter 15, “Working Within the System”, where Jan finds out who really decides on her platform’s funding, what that person is measured on, when the budget window opens, and who might back her.
About these patterns →
Find the Real Decider
For the specific decision your change depends on, find out who really decides, rather than pitching to the person who controls your budget.
Learn What They’re Measured On
Find out what the people you need are actually rewarded and punished for, and show how your proposal moves a number they are already accountable for.
Pitch in the Budget Window
Ask for money when the money is being decided, not when you happen to be ready.
Coalition With Money
Bring together several people who want your change for different reasons, held together by one story that each of them can retell, and include at least one early adopter who has money of their own.
Staged Build
Instead of one big pitch, build in stages, choosing each stage to serve the goal that one of your patrons has at the time.
Make Each Stage Pay for the Next
If the first stage of your change retires a license, a contract, or a server estate, offer that saving to fund the second.
Fit Under the Threshold
Size the first stage of your change to fit inside someone’s delegated spending authority, so that it needs no business case and no committee.
Attach to Mandatory Money
When discretionary budgets are closed, attach your change to a program that has to be funded anyway, such as regulatory or security remediation.
Which Budget, Not Whether
When one pot of money is frozen, ask whether your work can be paid for, or treated, as the other kind: capital instead of operating spend, or the reverse.
Let a Customer Pay
When the central budget won’t fund your work, find an internal customer with a pressing need who is willing to pay for it from their own budget.
Second Sponsor
Have more than one sponsor, and get their commitments written into plans that will outlive any one of them.
Below the Radar, Then Visible
Keep small, cheap work out of sight with a senior protector until it has proved itself, then make it visible on purpose once it needs funding or adoption beyond the team.
Use the Formal Process
Submit your proposal through the organization’s own architecture boards, investment committees, and business case templates, in the format they expect, even when the process is slow.
Reframing the Conversation
These patterns leave the money flows where they are but change how the work appears in them. They come from Chapter 16, “Reframing the Tech Conversation”, where Jan, with the help of the financial controller, turns a technical case into a financial one.
About these patterns →
The Deletable Cost Line
A saving is only a saving if a budget holder can delete a line, so build your case on cost lines that can be removed.
Speed Needs a Revenue Owner
Only argue that your work makes things faster where somebody owns the revenue that arrives sooner, and cares when it arrives.
Translate the Question
Restate each engineering complaint as a cost, a risk, or a liability that lands on a specific budget holder’s P&L.
Book the Unbooked Liability
Present technical debt and vendor lock-in as liabilities with a cost, in terms finance already uses, such as deferred maintenance.
Co-author the Numbers With Finance
Build your numbers with someone in finance, so that they become finance’s numbers rather than engineering’s advocacy.
Baseline Before You Claim
Before you claim a saving, agree with finance which cost line it will appear on, what the baseline is, and when it will show up.
Read the Numbers Behind the Numbers
Before arguing with a target on technical grounds, work out whose budget it serves and over what period, and what it really measures.
Bridge the Metrics
Draw the lines from what your work improves to what the budget holders are measured on, and build your case along those lines.
Changing the Flows
These patterns change where the money goes. They come from Chapter 17, “Shaping Teams Through Finance”, and they cover the funding models for shared work (central budgets, taxes, chargeback, showback, and hybrids of them), funding products rather than projects, allocation keys, incentives, and, at the far end of the chain in Chapter 9, figure “Patronage ultimately constrains system architecture”, changing the patrons themselves.
About these patterns →
Showback Before Chargeback
Measure each unit’s use of a shared service and show it to them, and to finance, before (or instead of) billing them for it.
Charge the Unit, Not the Team
If you charge for shared services, bill the business unit rather than each team, so that the financial boundaries are ones that already exist.
Allocate by Tag, Not by Topology
Split a shared bill by tagging resources and agreeing percentages for the rest, so that nobody has to change the architecture to get an accurate bill.
Choose the Key Carefully
When a shared cost is split between units by a key, the key decides who wins. Choose it for the behavior it produces, and decide explicitly who gets to choose it.
Fund the Commons Separately
Pay for a shared platform from a pot that using it doesn’t increase: pass consumption through to the units that incur it, and fund the platform team by a levy every unit pays.
Fund Products, Not Projects
Fund long-lived teams with ongoing budgets judged on outcomes, rather than funding projects that end.
Rolling Budgets
Move money and people on the same cycle as the plans, rather than fixing them once a year.
Share the Saving
Tie part of each unit leader’s reward to group-level savings, so that shared work becomes something they want rather than something they tolerate.
Write In the Review Date
Agree a funding model with the people it affects during the budget cycle, and write a date for reviewing it into the plan.
Move the Money, Then the Org
Before reorganizing teams to get the architecture you want, change how the new teams will be funded and what they will be measured on. Otherwise the old architecture comes back.
Change the Patrons
When the patrons themselves are what hold a system in place, the lasting change is to change whom the organization (or the team) serves, or who funds it.
Fight, Fold, or Leave
These patterns are for when none of the levers will move. They come from Chapter 18, “”, and deal with recognizing a system you can’t change, letting go of the time and money already spent, and choosing between the exits open to you, from the cheapest (changing your goal) to the most expensive (changing your employer).
About these patterns →
Recognize the Unwinnable System
Learn the signs that the money flows around a change will not move, so that you can decide what to do about it rather than keep pulling levers that don’t respond.
Ignore the Sunk Cost
Judge whether to keep going on what the next round of money or effort will return, not on what has already been spent.
Change Your Patron Before Your Employer
When the system won’t move, try the cheaper ways out before leaving: change your goal, then your role, then your patron, and only then your employer.
Set Yourself a Deadline
Decide in advance how long you will give a change, and what would make you change your goal, role, patron, or employer.
Read the Money Before You Join
If you leave, take the diagnosis with you: read a prospective employer’s money flows before you accept the job.
Anti-Patterns
These are moves that solve one problem and create another. Most of them are tempting because they work, at least at first: Connector’s chargeback cut costs and the share price recovered, and a reorganization is quicker and more visible than changing who pays for what.
About these anti-patterns →
The Technical-Merit Pitch
Engineers argue for their work on its technical merits, to people who hold budgets.
Chargeback in a Crisis
A cost-allocation scheme imposed in a hurry, which the architecture then reorganizes itself around.
Restructuring Around the Bill
Teams change the system’s architecture so that their costs can be measured separately.
Moving the Cost and Calling It a Saving
A change that moves cost from one budget line to another is presented as a saving.
Savings Nobody Can Evidence
Funding is approved on the promise of savings that nobody agreed how to measure.
The Gate Set Too Low
A central spending control spends most of its effort on the decisions that matter least.
The Free Platform
A shared platform is free to use, has a capacity fixed once a year, and faces unlimited demand.
Reorg Without Re-funding
A reorganization changes the org chart and leaves the budget lines where they were.
The Imposed Target
A savings target is set in a hurry, enforced hard, and gets exactly what it measures.