Money is information. I like to joke: “money is the best form of feedback.” Unlike comments in a retrospective, kudos cards, and SurveyMonkey results I can trade your information for something else and in so doing, give someone else feedback.
When someone buys your product they are saying “Your product is worth giving up …” – money in the bank, a nice meal out, a new car. You give them the product and they give you information. Money is a feedback, perhaps the ultimate feedback loop.
Within companies money also provides information. Money signals what the company values and who has power.
I worked as an agile coach with a Belgian company applying “the Spotify model” a little while ago. The leader of the tribe repeatedly told squads “you are masters of your own destiny.” He was keen, at least when speaking, on self-organisation, on squads taking control and aiming high.
One of the squads I coached decided the best way of improving performance was to improve quality: reduce bugs, reduce outages, make customers happier, improve code quality, etc. Then they asked for money for technical training and coaching. End of story.
The squad had no budget of its own. The tribe had budget but it was earmarked for something else. Asking for more budget was off the table. The squad only had power while they didn’t spend any money.
Team finances
Teams, development teams specifically, rarely get to see or talk about their own budget. In fact they rarely get to talk about money at all. It is funny, most of us live and work in capitalist in free markets societies. Success is judged by profit (or at least revenue), and the aim of the company is to make money for investors.
But day-to-day how much does anyone on your team know about the finances of your team? How much does your team cost per month?
What about your product: What does it sell for? What is the profit margin on the product? How much will that new feature you are adding earn?
While managers will often talk about cost-benefit “bang for your buck” and ask “how long will feature X take?” or “is it a quick win?” it is seldom quantified. If it is then it is probably only in days or weeks not pounds, shillings and pence.
Inside the company it is almost as if we live in a cashless communist enclave where money can’t be spoken of. People even say “Its all about money” as an insult – still they expect to be paid in money and (usually) want the company to keep doing so.
Informed authority
But what is devolved authority, self-determination, self-organization if it isn’t backed-up with the power to spend money?
How are we to make informed decisions if we don’t know how those decisions will effect cashflow? – while we might know costs how can we begin to talk about revenue without information. And how can we evaluate the impact of our decisions if we don’t see the bottom line?
I give my children a few pounds a week pocket money. They can choose to save it or spend it, I do my best to respect their choices even when I disagree. When it comes to bigger things, holidays and even clothes, Mum and Dad make the decisions.
If companies don’t open up finances to teams then they don’t trust those teams. They are placing severe limits on what the teams are allowed to self-organize. But in almost every company I’ve ever worked for, or with, development teams are treated like children and kept away form money. Even asking about money is frowned on.
Is it any wonder engineering decisions happen without reference to financial impacts? Why should we expect engineers to suddenly become aware of the cost of their decisions when actual costs are hidden? And there is no feedback loop?
Hourly efficiency
I can’t recall ever seeing a team with their own budget. Even a small budget would be an improvement (of course ultimately we want Beyond Budgeting but I’ll settle for imperfect budgets right now.)
I’ve long advocated Kazuo Inamori’s Amoeba management model. Inamori points out that in most companies teams get no feedback on their financial performance. In amoeba management, hourly efficiency reports are used to control costs and allow teams to make their own trade-offs on expenditure – not unlike beyond budgeting in fact. (In Kyocera hourly efficiency is calculated as: (revenue – (costs – wages))/hours.)
Unless teams have financial information they can’t make decisions. Back in Belgium I couldn’t quantify the cost of bugs because there was no data on salaries, contract rates, product contracts, support desk costs. I couldn’t put a value on removing bugs. But I was forced to put a cost eliminate those bugs. Consequently I couldn’t do the cost benefit equation and it was down to one man making a decision which seemed to favour some teams over others.
Talking of value without financial feedback loops is pointless.
Enjoyed this post? Subscribe for updates and download Continuous Digital for free
