When you become a dev manager, new responsibilities may arise that you are utterly unprepared to handle. I’m talking about recruiting, firing and layoffs, vendor management, and budgeting. You get very limited exposure to these duties prior to becoming a manager, and as a techie you took roughly zero classes about them in school.
Most dev managers are apathetic or just plain pathetic when handling unfamiliar, nontechnical responsibilities—after all, they’ve got important technical tasks waiting. As a result, filling open positions takes months, firing takes years, vendors are an afterthought, and budgeting is a recurring travesty.
There’s no excuse for disregarding nontechnical duties. They are critical to your team’s and our company’s success, doing them right can reduce time or costs three to 10 fold, and how to perform them well is well-documented. Bottom line: If you’re shoddy at recruiting, firing, managing vendors, and budgeting, then you’re incompetent, lazy, or both. I’ve covered recruiting, firing, and vendor management in previous columns. It’s time to tackle budgeting.
Permissible poaching, Hire's remorse, and “Out of the loop” (chapter 9) cover recruiting. “The toughest job—Poor performers” (chapter 9) covers firing. Hired helpers covers vendor management.
Many engineering managers don’t deal with budgets, aside from morale events, travel, and training. (If that’s you, feel free to stop reading now.) The rest often treat budgets like they treat test suites and staffing: keep everything from last year and add a few more items. Doing so is worse than brainless. It’s irresponsible, quells innovation, and damages our stock price. To understand why, you need to understand how budgets are actually used.
You probably know that each VP is given a budget each year. The size of that budget depends on expected performance and strategic priorities. Each VP has two responsibilities regarding his or her budget: divvy up the money amongst the org in a way that maximizes return, and accurately forecast how much money will be spent each quarter.
When engineering managers spend money on superfluous items (or don’t spend it at all), there’s no return on the money—same as burying it under a soccer field. That’s irresponsible. What’s worse is that the money could have gone to innovate another group’s products and services. Instead of a positive return, we get a loss of innovation. That’s tragic.
If reckless spending or “saving” isn’t enough, we get slammed by investors when our forecasts are either too high or too low. Why? Because we tell investors a story each quarter about how well we’re going to do. If we underspend, then we’re wasting investor money (no return). If we overspend, then we’re unreliable or reckless. However, if our forecasts are within 10 percent of our actual spend, then we’re predictable and dependable. Mix good results with dependable spending, and you’ve got happy investors.
How do you know how much money your team needs in order to provide great returns? How do you accurately forecast your spending each quarter? Certainly not by copy/pasting your out-of-date and likely haphazard budget from last year. You need a model.
A budget model is similar to other plans you work with all the time. It’s even in Excel. However, instead of listing all the stuff you plan to do, you list all the ways you plan to spend money.
Luckily for most engineering managers, there are only four ways to spend money:
Some folks try to be overly conservative to ensure they don’t overspend or run out of money. That is a big mistake. Remember, underspending is just as bad as (or worse than) overspending. You want to aim for what you really think you’ll spend, and then try to get within 10 percent of that forecast. (Some orgs may have even tighter limits; your finance people will know.)
Spending models for variable costs are linear in an annual budget. (Over multiple years, variable costs may be nonlinear, but for one year, you can use a line.) That line is made up of some amount of overhead (zero for most things an engineering manager buys), plus a marginal cost per item times the number of items. Really, it’s that simple.
The marginal cost per item typically is either an hourly rate (like for manual testing) or a per-unit charge for goods (like a per-word cost of translation or a per-server cost of lab equipment). Knowing the marginal cost per item (easy to obtain) reduces your budget planning to simply knowing how much of something you need.
Now it’s time to ask questions. How many words are you going to translate this year? How many servers do you need to buy? How many hours of manual testing do you need? Involve your team members (they may create budgets someday), and get the best answers you can. In a pinch, you can make reasonable guesses based on current plans and past utilization. Include the rates and item counts in your budget model, and you’re done.
The best part of including a simple spending model for variable costs in your annual budget is that when your plans change, you can simply change the number of words, servers, or testing hours you need and instantly get your updated forecast. Finance folks expect changes—they can handle it. They don’t expect imbeciles who can’t adjust their budget forecasts. (Actually, they do, but you don’t need to be one.)
Sometimes you assume a variable cost is a per-unit charge for goods when it’s actually hourly, or vice versa. Don’t assume—ask. If you have trouble figuring it out, look at old data and plot costs versus items (words, tests, whatever). If the graph looks like a tight line, it’s a per-unit charge (and the slope is the marginal cost). If it looks like a mess, it’s probably hourly and you need to manage it better.
That’s all there is to creating an annual budget.
The biggest mistake managers make is mixing up maintenance with special projects or variable costs. They assume project, localization, and/or testing costs will be some bulk amount split evenly across the year. Yeah, that’ll work. Wrong. Not only will your forecast be inaccurate, but the finance people will assume you’re an idiot and take away your budget. Plus, when your project plans inevitably change, you’ll have a heck of a time correcting your budget and explaining those corrections.
Having a simple, clear, understandable budget also helps tremendously with approving invoices. Now you’ll know what charges to expect and can easily spot mistakes.
Experienced engineering managers are now moaning, “What about those incomprehensible spreadsheets we get from finance each quarter? How do you fill those out?” Easy, you don’t.
I’ll let you in on a secret: Finance people think you don’t have a clue how to figure out finance spreadsheets. They barely do themselves. They certainly don’t think you can fill out the spreadsheets properly.
Instead, finance folks would much rather you talk to them about your spreadsheet. The one you understand, believe is reasonably accurate, and can easily update. They’ll ask you some questions, maybe correct a few formulas, and add some helpful information. Then they’ll gladly update the satanic spreadsheet from corporate finance themselves. Working with you on your spreadsheet is faster, easier, and more accurate than nagging you, getting your data late, and then correcting it all themselves anyway.
The key is to engage your finance folks a few weeks before the deadline. Just meet with them for an hour. Show them your spreadsheet, or work one out together. Come to an agreement, and move forward with confidence. You’ll find finance people surprisingly human.
Finance agreeing to fill out the finance spreadsheets for you presumes that you have a simple and clear spreadsheet of your own that breaks down expenses into rows for maintenance, special projects, and variable costs, and spreads out those costs into columns for each month. Finance folks won’t do all the work, but if you give them a straightforward spreadsheet, they’ll handle the finance-fu.
Once your annual budget is submitted, you need to update your forecast once a quarter (sometimes even monthly). This is no big deal if you use your simple spreadsheet.
Keep your original spreadsheets so you can show the finance folks the changes. Don’t be concerned or ashamed of going over or under. Finance would much rather get the numbers right today than deal with missing money tomorrow. Your finance friends can even help you move budget from one line to another, if that flexibility gives you a better return on your expenditures.
Remember, the game is to get the most from our money and forecast its use as accurately as we can. Being a little over or under is no big deal. Even being a lot over or under isn’t a big deal when there’s a good business reason. Being clueless? That’s a whole other issue.
If you want to fund a big project (> $500K) you can’t simply add the line item to your budget. You’ve got to draft a clear plan and go to your VP for approval. I cover such proposals in Controlling your boss for fun and profit and The VP-geebees.
None of us can accurately predict the future, but that’s no excuse for being a random-number generator or assuming nothing ever changes. Ordinary engineers can be on budget if they list their expenses in a simple table.
Don’t overthink the problem. Break down your expenses into ones you predictably have every month (equipment and service maintenance), special projects (procurement and your vendor can help you work out the payment plan), and costs that vary by consumption (like words, servers, and hours). Split out those costs by month, and work with the finance folks to update the data regularly.
A responsible budget isn’t hard to do and reaps enormous benefits for Microsoft and our stockholders. Removing the veil of mystery and being on top of your expenses will make you a better and more relaxed manager who has friends in finance and a bright outlook on the future.