Patterns / 4. Reframing the Conversation
Pattern 4.7
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.
In This Context
Not every target is what it appears to be. A number announced to engineers may really be a position in a negotiation with a supplier, or may measure something narrower than it seems. A target that looks irrational from engineering may be perfectly rational from where the budget holder sits, especially if the benefit lands inside their budget cycle and the cost lands outside it. Careful technical analysis of such a target is beside the point.
You can see this pattern is needed when a target makes no technical sense, or when a case that saves the organization money still fails the test it is judged by.
- Targets can be aimed at someone other than the people told to meet them.
- An instruction to question every line that grew measures year-on-year growth line by line, not total cost.
- Moving cost from one line to another isn’t a saving.
Therefore
Ask what the number is for, and build your case to pass the real test.
- Work out whose budget a target serves, and over what period.
- Check what a measure actually counts (for example, growth in each line rather than total spend).
- Make sure your case shows lines falling, and no line growing as a result, so that it passes both the organization’s test and the budget holder’s.
Consequently
- You stop wasting effort arguing against numbers that were never about engineering.
- Your case passes the test it will actually be judged by.
- A case that is good for the organization as a whole can still fail a line-by-line test, and you may have to reshape it to suit.
Seen In
Chapter 16, “Read the Numbers Behind the Numbers”; the AWS and Azure targets in Chapter 14, sidebar “War Story: Engineering Targets as Negotiating Tools”; Richard’s test in Chapter 16, “Make the Numbers Survive Being Checked”.