The Seven Processes

It can be convenient to think of a budget process as being isolated into a period of painful, deep work around the third or fourth quarters of every year; one that we can box up and shove aside in the back of our brains like our winter clothes. Unfortunately, this mindset assumes that the mere act of setting a spending expectation will cause that expectation to be met.

This couldn’t be further from the truth when it comes to an AWS budget. Infrastructure decisions are democratized by design in AWS. What we mean by this is, that without the implementation of strict governance policies, most engineers can decide to make a corporate purchase through a process that looks and feels like just a technical decision.

Unless you make important process changes to your organization, setting a new budget will have zero effect on team members’ mindsets or decision-making approaches when it comes to infrastructure selection.

Out of all of the techniques of spend control available for the engineering leader, we recommend adopting the following seven processes. We’ll describe each and give examples of their impact.

Let’s get started.

#1: Create a Bridge from the Financial Plan to Technical Goals with Spend Groups

The great thing about the approved budget is that it’s final. After months of endless reviews and adjustments, that budget is ready to be spent, and not a moment too soon! Unfortunately, there is some bad news. You’re not done yet.

You have your approved budget, and it’s organized by your financial team into specific accounts and category designations, like product line, corporate entity, department, or others. Great! What’s the problem? Well, first of all, the financial categories that divide up the budget mean nothing to your team.

A set of funds allocated to ‘Cost of Goods Sold’ for January fails to let an engineer know which initiatives are approved, or when we expect to scale up our costs by adding additional resources.

In order for your team to make good on your budget promises, you need to be able to communicate the goals that were established using the technical infrastructure configurations that your engineers are familiar with.

There are a variety of technical solutions for accomplishing this, including account structure, cost allocation tagging, and cost categories, but the underlying concept for you to focus on is that you need to create a conceptual grouping mechanism that most closely matches a subset of the financial allocations in your budget. In order to encompass these methodologies, here at Aimably we refer to this as establishing Spend Groups.

Let’s say your original budget included a series of project estimates for a new product launch. You’ll want to use Spend Groups to organize all infrastructure costs related to that product launch within your AWS environment. Once you perform this organization, you can implement your preferred technical solution (for instance, cost categories) in AWS according to the Spend Groups you’ve established. As a result, you’ll have a technical monitoring methodology that directly relates to a financial accounting decision.

Spend Groups will allow you to take advantage of both native and third-party AWS cost management tools for ongoing budget management. You’ll have the peace of mind that your internal technical tracking is in full alignment with your accounting team’s reporting.

#2: Reverse-Engineer Budget to Spend Groups by Month

Now that you have your infrastructure divided by Spend Group, and have chosen a methodology to track spending by Spend Group, it can be a challenge to know what kind of spending is on track over the course of the month. In other words, you must understand how much budget has been approved for each Spend Group each month in order to know if you’re performing according to budget.

When it comes to implementing the approved budget, your issues are not solely limited to the translation of the financial to the technical. In fact, another major hurdle in your way is that the final budget is almost always in summary form. Sure, it’s great to know that your total AWS expected spend will be a certain amount, but you need to know exactly which funds have been approved for which projects and product lines.

Your job becomes akin to a forensic accountant, at this stage. You’ll need to move backward, taking your full AWS budget, dividing it out by projects and product lines, and developing very specific monthly spend targets for each of the spend groups that you created in the previous step.

This is where your original planning materials come in handy. Your original budget draft featured painstaking analysis that produced a final summary number. Compare those to the final approved numbers. If they match, you’ve got all the breakdowns developed, but let’s just go ahead and assume that didn’t happen.

At this point, it’s important to remind you that once the final summary budget is approved, you’re the one in charge of your department. It’s now your job to deconstruct that final number and allocate internal project budgets back to a workable solution for all your teams.

We recommend that you follow a two-step process. First, you start by allocating specific budget targets to Spend Groups that match your originally submitted draft budget, as you have the details available to you easily. Second, you identify the monthly variances between the totals in your submitted draft and the final summary, then divide these properly across Spend Groups that can handle a shift from your draft. Once you’ve found a home for each month’s budget variance, you have a budget for each of your Spend Groups.

#3: Assign Single Person Accountability for Each Spend Group

Whether or not you ascribe to all leadership mantras, there’s the old adage of needing ‘one throat to choke’ which is truly applicable when it comes to budget accountability. You need a single person assigned full budget accountability for the performance of one or more Spend Groups under their direction.

Without a designated accountable person, budget management succumbs to the bystander effect. Engineers typically have little financial education, which contributes to a generalized abdication of responsibility for financial changes. The team could be educated about their financial targets, but without assigning individual accountability to specific subsets of these targets, it is unlikely for the team to take action individually.

Choosing the individual accountable is an important decision. At AWS itself, this responsibility sits with the product manager, yet this is not necessarily the right fit for other companies as AWS product managers are renowned for their technical expertise. No matter what, this person needs the authority to direct immediate changes to manage the spending, as well as the education to understand the implication of any financial or technical changes as they occur.

#4: Implement Monitoring by Spend Group

Let’s be clear: your team absolutely needs to know whether you’re on the right track or headed down a dangerous path. You do this in every other aspect of running your engineering team, so it should be second nature to incorporate spend tracking and alerting into your operational flow.

In deciding how to configure your tracking and alerting, remember that timeliness is everything. The team needs to know now, not at the end of the month when the bill arrives and there’s nothing that can be done about it. The whole team needs to know so that the urgency is felt and any redirections from accountable parties are predicted. Team visibility helps the team act as a cohesive team.

How you choose to implement your tracking and alerting is a whole other conversation. There are all kinds of tools available natively in AWS or through third parties like Aimably. It’s important to consider that the tighter you can connect your tracking and alerting directly into the spend groups you’ve constructed, the more effective your team will be in self-managing budget alignment.

That last part is so important, let’s illustrate it with an example. Imagine for a moment that you are in charge of assembly line productivity for the Ford F150 across all Ford plants, but the only monitoring data available to you is related to the productivity of each step on all assembly lines. You can review the effectiveness of the engine installations or the electrical assemblies of all models, but there is no way for you to look at F150s in isolation. How are you expected to be accountable for F150 productivity?

Taking the example and bringing it back to software engineering, an accountable person for a specific project tied to a specific Spend Group budget (and their whole team), must be able to view and monitor the actual spending tied only to their Spend Group and nothing else. Otherwise, these folks cannot be held accountable.

#5: Build Engineering Team Awareness of Business KPIs

Ensuring adherence to your AWS budget is incredibly important, but it’s also important to maintain broader awareness of the company's financial health overall. Doing so, allows the team to act quickly to affect change, when necessary. That is to say, there are many key financial performance indicators that are used to evaluate the health of a company, for which AWS spend is an influencer. And when the folks dictating AWS spending are aware of the health of these indicators, they can take action to improve the situation.

Imagine a self-managing engineering organization that works to improve financial health independently of major executive action. It’s possible! Maintaining accountability for staying within your AWS budget limits is good, but your team can become an incredible asset if it can self-initiate compensatory changes to AWS spending as a result of monitoring key financial performance indicators and tracking deviations from ideal benchmarks.

It’s critical to work with your accounting team to establish the groundwork to make this possible. First, you’re going to need to select financial KPIs that matter to management and the board. These likely include gross margin percentage and percent of revenue spent on infrastructure. They could also include cost per customer calculations and product line profitability. Next, you’ll need to source accurate and up-to-date data points from outside your organization, such as total customer counts and revenues. Then, you’ll need to aggregate that data with your own AWS tracking in order to generate the most realtime presentation of financial KPIs possible.

Finally, your team needs to know what these KPIs mean. We don’t just mean the dictionary definitions, though that is incredibly important. I mean your team needs to understand why your company needs to be tracking that particular KPI and what it means for the company if your performance on that metric falters. The more real the meaning, the more invested your team is in keeping everything on track.

At the very minimum, get your engineers time with your fellow executives for financial conversations.

#6: Reinforce Your Message With Quarterly Reviews and Rewards

Ok, at this point, you have your infrastructure organized to report spending in alignment with your financial reporting, you have your budget sliced and diced to align with those Spend Groups, you have individuals personally accountable for meeting targets set out in those groups, you’ve established a tracking and alerting system to get everyone involved, and you’ve even extended your whole program to cover AWS spending-influenced financial KPIs which you team understands comprehensively. Now what?

You need to prove to the organization that this is not a fad, but rather a critical part of your engineering culture from now on. The best way to communicate this is by increasing your opportunities for education and emphasis through multiple modalities. We recommend setting up regularly scheduled meetings and regularly scheduled reward periods, which allow for the opportunity to reinforce the message through in-person and financial means.

Knowing that the meeting and reward period will happen each quarter is a strong guarantee that the team will begin adjusting their behavior as the quarters continue.

#7: Implement a Spend Approval Process

Our last process recommendation to ensure budget accountability is to institute a review and approval process before major infrastructure investments. Ultimately, this transfers AWS budget accountability from purely a reactive stance to a proactive one as well.

As we outlined in Chapter 4: Make future plans a reality with well-modeled budget additions, during the budget process you previously set a series of budget targets for any new projects on the basis of a preliminary architecture review. The same architects involved in the budget consultations should likely form an approval group for any new initiative.

The previously approved budget targets become your measuring stick for any final architecture approval process. This is not to say that no architecture solutions will ever be approved if they end up being more expensive. Rather, the team should welcome the opportunity to approve a more expensive project, if the business drivers justify it and money remains available given savings in other areas. Similarly, this review board should question any solution that seems to gobble up extra spending just because it was available and assigned to the project early on.