Cloud Infrastructure Spending

  

We recently hosted our latest roundtable on “Cloud Infrastructure Spending – The Role of the CFO & How to Internally Align,” alongside AWS and Brightcove, describing the challenges facing modern finance teams and the role of the CFO when it comes to cloud infrastructure spending. Speakers from the AWS team as well as BrightCove discussed best practices on achieving internal alignment across teams, and some thoughts on how to get educated on spend.

That synergy between product, finance, and tech needs to be there for companies to successfully scale. What conditions need to exist to create that positive working relationship and move things to the next level?

• The foundation is earning trust – It changes the dynamic and perspective from “go build a relationship with someone” (which is kind of ambiguous) – and it makes it more specific: “My job is to earn your trust.” Foundationally that is the building block, and everything else just kind of rolls downhill. You have to make a commitment to be vulnerable with each other – it’s okay to say “I don’t know,” ask for help, or ask questions.
• The way that that expresses itself is aligning on goals – You can get to a point where you’re super comfortable and can say “X – what do you actually want here?” – “I don’t have the ability to do xyz things at the same time, let’s prioritize so I can align to that better” or “What’s the real deadline?”
• Be knowledgeable enough – CFO partners don’t need to be a tech whiz, but it’s helpful if they generally know what the CPO is talking about – engineering concepts, cloud concepts, etc. AWS has a cloud practitioner class (the lowest rung of certification that gives you general knowledge).
• Take on some of the CTO/CPO’s work with vendor management – Negotiate these things together (good cop/bad cop, or just sharing labor and having a partner who knows the financial bits and how contracts and billing works). This doesn’t tend to be a natural motion for a product manager or engineer.
• Get your finance team embedded within the different organizations – Finance needs a really deep understanding of the levers. It’s not a one way street where they’re asking, asking, asking – the team needs to get their hands dirty and take on work that finance can be doing that lets the business operate as a business.
• Understand the mentality of developers – Many developers can be overly optimistic with estimates so you’ll need to make adjustments for planning purposes. Understanding the nature of developers will help you smooth the edges in translating an engineering plan to a financial plan.

In order for the CFO to reach full effectiveness for the business, they transition from being the bean counter to doing a whole lot more – how do you tackle that transition? How do you get yourself seen that way and get embedded?

It starts with leaning in – CFOs who are bean counters tend to accept the role of bean counter (e.g. we count the money, we do the accruals etc.). First you have to lean in and understand the role that finance can have across the org. The CFO actually owns that. One of the unique pieces of finance is that finance knows the truth about every single aspect of the business – it’s one of the few points of the business that everything funnels back to – so you can really drive alignment with the knowledge that you have. If there isn’t alignment across all these aspects of the business – finance will actually be the first part of the org to see it, so the onus is on them to open the eyes of the business.

How can you avoid people getting defensive when finance approaches their business?

This relates to earning trust, but beyond just that trust piece, you need to have hard conversations like “Hey look, this is where my team is aligned – I have these skills and we’re working on these services/products – I have to get this new product out the door that is tied to our annual conference, and that’s the team that I committed to you would be working on this cost savings thing. But, that’s all I have, those 20-25 people.” You need to be able to have these conversations so you can make the right tradeoffs that best benefit the business. Another example could be a situation where you have a legacy colocation center that costs under a million dollars – is it worth it to move it to the cloud? Is it worth taking engineers from revenue generating projects and diverting them to cost savings-type of activities? Those are the tension points in a more mature business – you’re sort of beyond the early days of getting stuff out the door.

Can a lean CFO/finance organization have the bandwidth to do all of that and do all of the other actual day to day operations that they have to do? When do you go about doing this? When do you start leaning in and get a bigger team?

Two components are crucial here: When is the right time to build out the scale for the systems? Then, how do you think about the people side?

From a systems standpoint you have to be prepared for scale early or you will pay for it later. You have to be thinking: How am I going to scale this? We all want to grow. You have to plan for growth and flexibility. On the people side, you can stay lean, and you can do it in a business partnering format. It’s about shifting some of the resources and thinking about what your accounting folks are doing and what your FP&A teams are doing. FP&A is doing all the accruals for the majority of the AWS spend, CDN partners, marketing, etc. They spend about a week doing accruals, then they can spend 3 weeks really understanding the business. One example that came up was a company with only three FP&A people at 200M. You don’t need a lot of people – it’s more about complexity. However, if you’re a manufacturer and you have a bunch of diff groups you may need more people. When you start to lose sight of what’s happening, you have to invest more in finance.

Would love to hear some rule of thumb stats around when the AWS expense is at a level that warrants investing in the cost savings? At what point do you divert resources from the revenue side and other strategic initiatives? When do you divert R&D to combat longer term AWS costs?

It’s less about diverting resources. For example, let’s say you have a hundred heads working on a product – it’s less about diverting heads, and more about: what do you think the savings are if you hire 5 more heads (could you create 20 heads in savings?). Every investment you make should consider ROI. When you talk about “What are we investing in?” – put some targets in place. If things aren’t working, you need to quickly identify what you’re missing. Come up with some KPIs that are early indicators of if you’re going to get there (has my Spot usage gone up?, etc.) . You have to be able to pull the plug and redirect resources and programs if they are not working. It’s quite hard for many companies to say “wow, that didn’t work.”

At the company’s early stage you want to adopt cost savings from the beginning. Split it out into three different categories: 1) Big projects (some old colo that needs to move to the cloud), 2) Financial tricks or mechanisms – how do you get smarter about the financial agreement that you have with AWS, 3) Gamify scaling – you’re building something and it shouldn’t scale linearly – how can you creatively get your cost per unit lower over time? That’s an engineering challenge not a financial challenge. More about that later.

What is a good management philosophy around earning trust and committing to vulnerability?

Consider getting together quarterly as a leadership team and make sure you’re touching base on strategy and where the business is going. Offsites can be 2-3 days to drive alignment, but at least half a day (or even a full day) should be dedicated to team-building specifically.  This focus on  team-building and trust helps facilitate the hard conversations.

Is there a methodology that helps you bring the truth to people without making you the enemy?

When you start with a foundation of partnering and you build that foundation of trust, and then you get into the room, you’re much more able to have that no nonsense conversation and call people out. When you call people out and everyone just hates you, it’s because you don’t have that level of trust. It goes two ways too – you have to accept someone calling you out as well. So, when you think about finance moving forward – all the systems and all the accounting, etc. – that’s table stakes. As the CFO role evolves, we have to own the strategic direction of the company, and that comes down to relationships. You can’t call BS without the data to back it up, and you have to have that trust, otherwise you won’t be very popular.

Organized methodologies (like The Table Group) can also help as well, but an even bigger factor can be framing, and having your peers’ backs. You want to be able to ask and offer help to your colleagues vs. brutally detailing the ways someone is going to fail. Help solve the problem and figure things out. Some of it comes down to venue as well – it’s much easier to speak openly with someone in a 1:1 engagement. Any time you’re going to a meeting of any scale or importance, you should try to do your job in advance to make sure you won’t be surprised by anything coming out of that meeting. If someone isn’t coming to you in advance of a meeting, and you know your questions, make sure you touch base with them beforehand. You want to say “Yes, I fully agree with you” – because you’ve all already aligned on everything

What do you mean by a challenge/gamification of lowering cost/unit over time?

There’s a root element to this – you want to focus on a couple different key metrics (e.g. cost / min viewed or stream stats), but once you have those metrics, and then one or two layers down (what % utilization are you using on your containers or your services) – once you start to define those things and make it known, you can start to stratify engineer behavior. Your VP of engineering can get really focused on these metrics if they know that would be measured and reported in the exec meeting every month. Is there a general trendline going in one direction or the other? That’s a high level metric you can get the whole engineering department around. How can you contribute to that? Are you helping or hurting that?

At a group or team level, visibility is key. An example of this could be an engineer developing a tool to see the percent utilization by instance across the entire estate – some of those metrics are probably very poor. But once that data gets published, there is a natural human tendency to not want to see your service with an average utilization at 12%. You don’t have to put a challenge in front of everyone, or an incentive or spiff, there are natural mechanisms that take place if you just make data available. It’s back to 6th grade running around the track, no one wants to finish last. You don’t have to tell the service with the worst utilization to improve. Define the metrics, whatever those metrics are, and then just make them known. People will start to behave in the ways that you would expect.

You mentioned you have a dedicated FP&A team that partners with the business (mostly engineering) – I’m curious about the profile of that FP&A person because that group would need to be fairly technical? Additionally, for AWS costs – do you use any kind of tool to make sense of AWS billing? Sometimes the standard billing winds up looking like a foreign language. What ideas are there around that?

CloudHealth can be a good option to track AWS spend – you can use that on cost controls, understanding, and getting to recommendations. In terms of the profile of the FP&A – you really just want to find people who are really detail oriented and motivated/want to pick this stuff up. People just need to dedicate the time to really learn about AWS, and it is complicated + takes time – it’s probably about a 6 month period to get someone fully ramped and understand what’s going on with AWS.

If you look back on your career, what do you know now that you wished you knew earlier and would have started earlier?

Relationships are the key. It can take a long time to figure out how critical relationships are to actually getting stuff done. Early in your career it’s easy to think: the excel spreadsheet says this, why doesn’t everyone just do what the spreadsheet says? When you step out of finance and spent time with operational roles – you realize that you have to build relationships first before anyone will work with you