Money: budgets, headcount and vendors
Mangrove spends about $16 million a year on technology, and as CTO you own all of it. This lesson shows you how to read and run that budget, plan hiring so the money buys the capacity you expect, manage cloud cost by unit, keep a healthy vendor portfolio, and bring real trade-offs to the finance director.
By the end you can
- Split a technology budget into run and change, and operating and capital spending, and know what to agree with finance
- Calculate the fully loaded cost of an engineer and the real cost and capacity of a hiring plan
- Set up cloud cost management with team ownership and unit costs such as cloud cost per order
- Keep a vendor register with renewals, exit plans and concentration risk
- Present budget options to the finance director as trade-offs, with costs, benefits and risks
The everyday picture
A restaurant owner is opening a second branch. Her costs come in different shapes. Rent, electricity and staff wages arrive every month whether the tables are full or not. The new ovens are a large one-off purchase that will last eight years, so her accountant spreads their cost over those years in the accounts, even though the cash leaves the bank on the day she buys them. The new cook is paid from his first day, but for the first month he is still learning the menu and the kitchen, so he cooks maybe half as much as the head cook.
She also has supplier contracts. The fish supplier's contract renews by itself every year unless she cancels three months before. Last year she missed that date and paid a price she would never have agreed to. Running a technology department's money is the same job at a larger size: know which costs are monthly and which are one-off, know when new people really start producing, and know every contract's dates before they surprise you.
Owning the budget: run, change, operating and capital
Start by reading the budget the way the finance director does. Mangrove's technology budget is about $16 million a year (these figures are illustrative for the course):
Line per year run or change opex or capex
Engineers (90 x about $5,000 a month) $5.4M about 40% run opex (some may
about 60% change be capitalised)
Store IT, data and security staff $1.8M mostly run opex
Cloud $2.4M run opex
Software licences and SaaS $2.0M run opex
Lagoon Digital (Partner app agency) $1.0M mostly change opex (some may
be capitalised)
Store hardware refresh $2.4M run capex
Network and telecoms $1.0M run opex
Total $16.0M about $10M run, about $6M changeTwo splits matter. The first is run and change. Run keeps today's business working: support, on-call, licences, cloud, replacing worn-out tills. Change builds what the strategy asks for (Technology strategy). At Mangrove about $10 million is run and about $6 million is change. If the company grows and run grows with it line by line, change gets squeezed out. One of your jobs is to keep run growing slower than the business, so growth pays for itself.
The second split is operating and capital spending. A cloud bill is opex: it is a cost in the month you pay it. A new till is capex: the cash goes out now, but the accounts spread the cost over its useful life (often a few years, set by finance policy). Some software development can also be capitalised, which means engineers' time on a qualifying project becomes an asset that is spread over later years. Whether that is allowed depends on the accounting standard the company follows (under IFRS the rules for development costs are in IAS 38; US GAAP has separate rules for internal-use software) and on the company's own policy. These rules are detailed and have changed over time, so agree the policy with the finance director before you plan around it.
Capitalising is not free money. The cash still leaves the bank. It needs time records that show which engineers worked on which qualifying project, and it creates amortisation costs in later years. If the project is abandoned, the asset may have to be written off at once, which shows up as a sudden loss. Ask finance three questions: Which kinds of work do we capitalise? What records do you need from us? What happens to the plan if a capitalised project stops?
Owning the budget means four habits:
- Every line has an owner in your leadership team: cloud with Oskar, store hardware with Victor, Lagoon with Ken, data tools with Ruth.
- A forecast every month: the expected spend to the end of the year, line by line, updated with what you know now.
- Variances explained before finance asks. If cloud is 8% over plan in September, you already know why and what you are doing about it.
- No surprises. A risk to the budget goes to the finance director the week you learn of it, with its size and your options.
Quick check
Ken suggests capitalising all engineering time on the new Partner app ordering core "so this year's budget looks smaller". What should you do first?
Whether development work can be capitalised depends on the accounting standard and the company's policy, so finance decides with you. Capitalising does not reduce the cash spent; it moves the cost into later years and needs time records. Saying it is never allowed is wrong too, since the rules do allow it in some cases. Doing it without finance breaks the "no surprises" rule.