On budget

 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.

Eric Aside

Permissible poaching, Hire’s remorse, and Out of the interview loop cover recruiting. The toughest job—Poor performers covers firing. Hired helpers covers vendor management.

Budget boot camp

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.

A scale model

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:

• Staff overhead (morale, training, travel, PCs, and aspects of salary). These items are already budgeted for you by Microsoft.
• Equipment and service maintenance (lab equipment depreciation and service fees). These costs are simple to calculate and remain the same each month. For most lab equipment, you take the total cost of the current equipment and divide by 36—that’s the cost per month (assuming a typical three-year depreciation). For services with fees or sustaining vendors, you divide their annual cost by 12. Sure, it can get more complicated for special cases, but your finance folks will help you with those.
• Special projects (product development and short-term contingent staff projects). The budgets for special projects need to be worked out in advance with your vendors. Call them up and work together—it doesn’t take long. Microsoft procurement folks can be a BIG help—and they don’t have cooties. They’ll tell you which vendors do a great job and what rates to expect. They’ll even tell you about the facilities and IT costs you’ll need to factor in if the vendors are on site. If you’re in a huge rush, submit a past project budget, and then engage with vendors and procurement on a correction (or your forecast will be off).
• Variable costs (localization, manual testing, new lab equipment, and the like). These require a spending model—that’s right, math. But don’t worry, the math is first-semester algebra from junior high. Excel can handle it. Let’s cover that next.

Eric Aside

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.)

Form a line

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.)

Eric Aside

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.

Everything’s all mixed up

That’s all there is to creating an annual budget.

• Open a spreadsheet.
• List your equipment and service maintenance, special projects, and variable costs (typically in rows).
• Split the costs across twelve months—evenly for maintenance and by your best estimate of the applicable dates for projects and variable costs (typically across twelve columns).
• Sum up the rows.
• Save the spreadsheet.
• Done.

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.

Eric Aside

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.

You’re dealing with an expert

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.

Eric Aside

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.

Roll with the changes

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.

• Service maintenance or vendor fees went up? Adjust that line.
• Canceled, added, or moved the timing of a project? Adjust that line.
• Got extra languages, words, more or fewer servers, or testing changes? Adjust your item counts and/or the months they apply.

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.

Eric Aside

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.

Being predictable

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.