Dana Berg [00:01:04] Well, hello everybody and welcome to another podcast for Cloud N Clear. I have the great privilege to once again host a wonderful topic, one that is very, very hot in the ecosystem right now. And we’re going to be talking about today everything related to best practices with respect to cloud financial management. And I’m always intrigued by, given the fact that cloud is growing so fast and we are seeing it proliferate through all of the enterprises that we work with. And, of course, how to operate, govern the financial ramifications of these investments is huge. And with me today as my special guest is a fairly new SADA individual, Rich Hoyer, who is our director of a new formed business unit called our FinOps team. And when we were out looking for the best person on the planet to run our FinOps practice, we found that person in you, Rich. And I want to formally welcome you to the organization. And thank you for choosing SADA.
Rich Hoyer [00:02:24] Thank you very much. Thank you very much. I’m very flattered.
Dana Berg [00:02:28] You’re going to find out, for all of our listeners today, the wealth of knowledge that Rich has in this space. I know that since you’ve joined, you’ve been teaching me all about what it means to have an appropriate control mechanism in place and a cultural adoption of the practices that make financial management of cloud even easier. So we’re going to dive into all of that today. But first, Rich, for our listeners, please provide a background into your story, your journey. How did you end up in this FinOps discipline?
Rich Hoyer [00:03:06] Yeah, no, it’s actually kind of a funny story. I think in some ways I sort of tripped and fell in a pot of career gold. I was, I studied economics as an undergraduate and between business school and undergrad, I was actually working in finance. I was doing valuations for mergers and acquisitions. So Company A wants to buy Company B, I would represent Company A and we would essentially build a financial model of what B was worth and figure out what you should pay. When I went to business school, actually as a hobby, I got really interested in technology. I’d done a little bit of independent consulting before business school and that meant that I was my own I.T. person. Back in the days of Windows 98, there wasn’t anybody I could call that was a – those of you that remember those dark days, that was not a very good release. And Windows 98, I wound up having to wipe my machines and things like that on my own. So I developed a personal interest in it. And in grad school, I also kind of caught the entrepreneurial bug. And so rather than staying in sort of a finance consulting role, when I got out I just hung out my shingle and started a little I.T. support company for small business. So sort of a self-taught person. I learned tech there, and did that for a number of years, found it really hard to recruit talent for that business, was able to grow it on the revenue side, but really hard to recruit people who wanted to do that work, who wanted to drive around to small businesses. So I joined a company called Xenos, which did – which does availability and performance monitoring. And that’s where I learned cloud because I inherited a lot of infrastructure that was in a data center and it was end of life. And I wound up writing a business case at the request of my leadership about whether I recommended that Xenos either adopt a, build new infrastructure in EC2, or use a managed service provider, or buy new equipment. And so the business case showed, I was actually more leaning toward the managed service provider. As it happened I would turn out to be wrong on that, because we did go with EC2 and it was much better in the long run, but that basically meant I had to learn cloud. And so now I had all the pieces in place to have tripped and fallen into this pot of gold career-wise because I had finance, I had tech, and now I had cloud. And some years later, a friend of mine that I worked at Xenos kind of look me up. And he was joining Cloud Ability, which is a cost management dashboard platform, he was joining that business to build out their professional services. And he remembered me. He remembered that I had a finance background. Of course, he was my mentor at Xenos to build out the cloud infrastructure. And he also remembered that I’d done this business case. So I had all the different elements to do this work well. And it’s just funny because at that point in my career, I had a little bit of, maybe it’s an exaggeration, but a little bit of an inferiority complex because my resume was half finance and then it was half tech and a little bit of cloud. And it’s kind of like somebody’s reaching into a toolbox, they don’t look for something that’s half screwdriver and half wrench. And that’s kind of how I felt career-wise at the time. And here comes along my friend David, and he’s like, this is exactly the person I need. And that was kind of how I got into it. And now, as you know, it’s become a really very important discipline for a lot of enterprises. And what we’re finding today is some of us were lucky enough to have had this somewhat odd career background and be a great fit for this work. And what we’re finding today is that enterprises are actually building these people. They’re taking folks with either background or the other, and they’re teaching them the other half. And to me, that’s just a really interesting moment in history, because if you think of sort of business, traditionally a lot of the roles of business, I think it’s fair to say I’ve been fairly stable for quite a while. You’ve had marketing for a long time, you’ve had sales, and so on. And here is one of the, you know, this experience now where this moment in history where we’re having to combine up in the same humans these formerly very disparate disciplines. And just to me, that’s just a very interesting thing. It’ll be interesting to see where it goes.
Dana Berg [00:07:11] Yeah, totally. Well, let’s start to peel the layers of the onion back in terms of, we’ve all heard in this business, particularly in the technology sector terms like DevOps. And that’s been something that’s been a very hot topic over the last 10, 15 years, which is redefining processes and controls around how to do release management and get software into production and how to streamline that. With this new term that we now are seeing more and more of, which is your area, FinOps, which I want you to try to, very simply, try to define what that means for our listeners and maybe in the process, you know, describe some of the challenges that companies have been starting to face as they grow in their cloud footprint. And how does FinOps play a role to address those?
Rich Hoyer [00:08:12] Sure. No, absolutely. And this is exactly where the services part grew up, is that Cloudability recognized that a lot of their clients could adopt a tool but still struggle, even though the tool is fantastic. So essentially, here’s fundamentally what we’re talking about and why this has become a discipline. If you wind back to the period before public cloud was a thing, to the old procurement model, which still exists for many on-prem environments, the way it used to work as far as internal controls and budgeting was that some team in an organization would feel that they needed some equipment. Kind of like when I was at Xenos, I felt like I needed to end of life equipment. In the procurement model in those years, what would happen is, is what happened. I would be asked to write a business case. Why do you need it? How much do you need? And essentially you would come up with a budget for how many physical servers you wanted to rack in the data center. What was going to be – are we renting more racks? What’s the power consumption? And so on. And you had that procurement process where by virtue of having thought about this ahead of time, you sought the correct approvals as a matter of governance in the organization. Everybody knew what was going to get spent and then you write your check to Dell or IBM or whomever, and the equipment goes in. And so there’s a process to vet what you’re going to spend, your planning, your justifying, and then the expenditure goes out. What we saw early on in the early days of cloud was, of course, all of those governance models going out the window with cloud, because what you’re doing is de facto, you’re doing procurement as a consumer of the service. And what that means is there aren’t any checks and balances, unfortunately, until after the check gets written or after the bill arrives. And we see that today. We saw that early on. We still have clients, Dana – and I know you can relate to this. We still have clients where they have surprises, where something happens and a big bill comes that nobody intended. There was no ability to get out in front of that and say, are we going to spend this money or not? Right? Because some code gets run. So essentially what you’re doing de facto is you totally decentralized, you being industry when they went public cloud, you’ve decentralized the procurement process and you federated it. And consumers are de facto doing their own approvals real-time. And that puts you in a world of catch up. That means that now you have to have reactive reconciliation of budgets. You have to have reactive measures that are in place to prevent a spend from getting out of control. And so early on, what we were seeing was, it was disorienting to a lot of organizations. We had a lot of complaints from folks that were consuming public cloud of what they described as a sawtooth shape. If you were to graph the costs it looked like a sawtooth. Costs would go up and up, somebody would get angry, they’d delete a lot of stuff, become more efficient, costs would go down. And you rinse and repeat. Right? And so if you look at that, the idea was how do we flatten that? So that’s the problem I’m describing, the sort of problem area. And essentially the discipline that grew up to address that really had three buckets of activities that grew up around that. And the first was just what we call visibility. And visibility means, do we know what’s being spent? And it can’t be at the end of the month, because then you could have all kinds of things going on during the month or the end of the quarter or something like that. So we need visibility real-time into what’s being spent. And visibility doesn’t just mean, hey we incurred this many dollars yesterday or last week. What it means is, why did we incur that? Who are the consumers using it? Is it justified? And so on. And so there’s a whole art science around that bit. Around that bit of, how do we gain visibility? Not just as management, a lot of different consumers need this data. If you think again, back in the on-prem model, we had somebody like me that was looking to procure some equipment, kind of the consumer if you will, of that equipment or service. And then you had procurement that was responsible and some management that were setting budgets. But after that, there didn’t need to be a lot of folks involved, right? The servers were in the racks, they’re running, I’m logging on.
Dana Berg [00:12:30] Yeah, sure. They’re static costs, right?
Rich Hoyer [00:12:32] It is, it is. It’s a fixed cost. And you have to have a lot of consumers of that information after the procurement. That’s not true anymore. So today you’re going to have folks that are going to be on the management side who are going to be watching the profit and loss and thinking about what they’re spending in context of budgets, thinking about their spending in a context of hopefully things like customer costing, product or service costing. You’re going to have the technical teams who are going to be making sure that they’re consuming the way that they need to. And then now you’re going to have the FinOps folks that have grown up into this space that are really helping translate some sort of new languages that appear in these bills then appeared before. So that’s the first bucket. That’s the first part of FinOps is, do we know what’s happening? And do we know –
Dana Berg [00:13:15] Insights.
Rich Hoyer [00:13:17] Yeah. Do we know why it’s happening? Exactly right. That’s right. The second one is optimization because again, there are so many more opportunities for inadvertant spend, or another way of putting it is for inadvertent waste, that folks who are – we always assume and we’ve always found that people want to do the right thing. And so if you get the visibility right where the consumers of cloud know what they’re spending went, we found that mere act can cause the bills to come down 10 or 15 percent, just simply holding a mirror, if you will, up to what they’re spending. And so, you know right away that if you don’t have good visibility, you’re going to have a less than optimized environment. Not because people are lazy or don’t care, but because if they don’t, it’s like driving without headlights. They just don’t know what they don’t know. But even then, there are a whole set of disciplines around recognizing in public cloud where people inadvertently spend more than they need to without intending to. Whole set of disciplines around the optimization part of it. And then the third major bucket is governance, right? Is how do we really eliminate that sawtooth pattern I mentioned by virtue of having some guardrails, right? Sometimes those guardrails are things like policy driven, that folks can’t just spin up a lot of expense of resources in an exotic geography of the planet. And sometimes their governance around things that reinforce the other two, right? Governance can mean we have a policy of how often we’re iterating looks at efficiency and examinations for efficiencies. But they can also be governance that supports visibility, and that could be governance around how accounts are structured, around how things like folders get structure, or naming conventions of projects, or tagging and labeling. So those are all fall into that bucket of governance of how do we have some kind of control? And that’s really what grew up. And now what you need are folks that understand all of this. And then there’s the last bit also, which certainly is very relevant, which is budgeting and forecasting. That we look at what’s happening in the organization and have some means of saying what will happen in the future. And that’s a discipline also that falls very much within FinOps because the same practitioners are going to need to interpret other information to figure out what the implications are for spend and future periods. So that’s in a nutshell, what grew up. And as I speak, you can hear in all of that why folks like me need to have these really diverse professional backgrounds, because you have to put all this stuff into context, right? Somebody who’s in finance or accounting needs to have some basic idea of what the technologies do, how they’re applied, when things are appropriate.
Dana Berg [00:15:57] Yeah, I was going to ask you, so I mean, there is this term now called a FinOps practitioner. What does that mean? Like, so where do you find FinOps practitioners? What are their superpowers? What are they bringing to the table and the skill sets required in that role?
Rich Hoyer [00:16:18] Yeah, that’s great. And I like the fact that you use the word find, because we don’t. We build them. We’re seeing the enterprises building them, right? So let’s take an example of where an organization doesn’t have a FinOps practice at all, and they’re operating in public cloud. And usually when that occurs, when somebody like us in the SADA world becomes engaged is usually quite honestly when there’s pain in some context. Where they know they need to build that organization and they don’t quite understand how to do it, how to begin the process. And usually that pain is around things like they don’t have good visibility, they know that it’s the Wild West, or people can do whatever they want, or they have a pretty good sense that things that overprovisioned. So usually it begin a process of building these teams begins with pain. And what we find organizations are doing is right now, they’re taking timeshares, if you will, of other folks that are in the organization who are willing and able to do this work. So what that means is as you form the team, you’re going to find some folks that have started looking maybe on the finance or accounting side at the reporting. And so they have some familiarity with the way that you need to report against public cloud. And you rope them in. You draft them, if you will, and say, would you be willing to put in X hours per week on this FinOps team? Right? Where you’re going to work on that. And then it’s really important also on a technical side to have folks that are willing more on the engineering side to join the team as well and work with these finance people to put their heads together and think through how they’re reporting, how to get the visibility. Because think about the feedback loop there. On the accounting or finance side you may have a team saying, we need to report against X. X could be, what is the cost per customer? X could be, what is the cost per service? Or it could be geographical, a department. All kinds of different ways organizations need to report. And when they find they’re not able to do that in a way they need to, they need input from technical people to figure out, how do we solve that? Right? So sometimes it might be something like labeling or changing account structures. What we’re finding, particularly as more and more of the workloads become more cloud native, what that does is it puts you into shared resources, often. Picture something like containerize loads, where you have one host and the cloud provider sends you a bill for how many hours that host ran. But uh oh, on that host are a bunch of containers. Containers are different customers may be being serviced, or different products that are running. Now what? How do we split it? We need technical people involved – report what we need to. You wind up having those brought together and then honestly, what I’m seeing more of, is people that are full-time being pulled into this work. So you might have, let’s say a team of four or five, and one of them may be an actual full-time FinOps practitioner. And what they’re doing, they’re doing all the things I’m talking about. They’re looking constantly at efficiencies and figuring out where there might be some cost. They’re helping with periodic reporting, they’re helping enable consumers of a cloud management platform, something like Cloudability or Ternary, and they’re saying, hey let’s get you set up on that. Let’s make sure you have the right views, right? So they dabble in a whole bunch of things all day. But it all falls into these broad buckets – roped into the budgeting and forecasting, of course, as well. So that’s the short answer to your question. More and more, right now we’re borrowing them and we’re building them. And I think what you’re going to see is more and more LinkedIn profiles of people have done this work now are FinOps practitioners. They may have something else they want to do as well during the day job, but they’re also FinOps practitioners. And then you’ll have folks like me that wind up in services or folks that are full-time at literally this is what they do for a living. So.
Dana Berg [00:20:54] So really interesting stuff. You know Rich, this is still though an emerging discipline that in many respects, I think the blueprints best practices are being developed real-time. And I think in a lot of ways we’re pioneering the tactics and approaches that can best be used in that governance of spend. And one thing you’ve always told me when I was first learning about FinOps was, I always thought FinOps was only a cost containment exercise. You know it’s, FinOps equals cost savings. But it’s actually, that’s part of it, right? But I think that’s where everyone naturally gravitates to. But there’s actually a bit more to it than that. Right? There’s also, you know, a description and a guarantee or confidence level that value is in fact being transferred and delivered upon. So speak to that cost savings versus value dilemma and how FinOps –
Rich Hoyer [00:22:05] No that’s absolutely right. There’s often a misconception that it’s about cost takeout. And it’s something that we really try to de-emphasize in the discipline. What we want to talk about is eliminating waste, always. So I’ll give you an example, I had a couple of clients early in my years practitioning this over in the UK, one was in I think Sweden and one was in the UK – Large retailer, and their margins were very, very, very, very narrow. And so there was always an emphasis at that client on cost optimization and eliminating waste. Another client, the one that was in Sweden, was an emerging technology client, and they were very much in a growth phase. And they when we were engaged, talk about FinOps, they said don’t get near our spend. You cannot restrain our growth. And I said, that’s not really the trade-off. Because FinOps is about eliminating waste. It’s never about restraining growth. So that’s the first context I would love to share is that it’s just a false trade-off. It’s a false narrative that if we get more efficient, we restrain growth. Not really a thing if you’re doing the work well. The second thing you mentioned is this idea of value, which I think is a fantastic thing to highlight. I mentioned this idea that a lot of the time we are, what gets pulled into this discipline is things like budgeting and forecasting. One of the really important areas there is essentially, do we have a good way to measure where the ROI is? And the most concrete context of that is actually in new workloads that may be getting migrated in the future that are on another platform or on-prem. This is mainly where I’m seeing that work being done. And the idea is that although we discourage it, a lot of times organizations really just want to see that the total cost of ownership comparison between where the workload is now and what it would be costing when it’s in the cloud. And we’ve always discouraged that because it’s really a limited view of looking at whether the migration is good for the enterprise as a whole. For example, supposing you have workload A that has a certain scope in the estate, and you ask me to do that analysis and I say, well yeah, Dana, it’s going to cost you more. Is that good? You got to put it in context, right?
Dana Berg [00:24:26] Right.
Rich Hoyer [00:24:26] If it’s going to cost more than what you’re looking at is not that different than saying, I’m thinking about building a factory. I’m thinking about buying some new machines. Yeah, I know it’s going to cost more. Should I do it? The context there is what’s the return on investment of that and how is it going to change the business? In cloud that’s actually a really interesting challenge because many of the benefits of cloud aren’t really going to show up as just TCO savings necessarily. They may, but usually the different dynamics of how one operates in the cloud means that the actual impact on the organization is going to show up in things like speed to innovation. Oh wow, I can get products to market faster. How do you value that? How do you value that? That’s really interesting, right? Because now you’re talking about, for example, accelerating revenues. Or you’re talking about beating a competitor to a bunch of market share because they couldn’t get there when you could, right? How do you model that?
Dana Berg [00:25:20] True. That’s right.
Rich Hoyer [00:25:20] So we’re seeing more and more emphasis on that part of the modeling when it relates to migrations. What I think we are going to start seeing more of, and we’re candidly not seeing as much as maybe we ought to be seeing, is on an ongoing operating basis for FinOps practitioners to begin doing that thinking about workloads that are already underway now and looking at what is the value of that as a look back. And we’re not seeing a ton of that work yet, but I think that we will. And I think that very candidly, another evolution that may come to pass, so sort of my prediction, we’ll see if I’m right. Maybe we watch this in ten years and see if I was right or wrong. I believe that more and more the FinOps activities will actually wind up being absorbed by the technical teams themselves. And the reason is that right now there’s still an external feedback loop, right? Where spend gets incurred by technical teams and you have FinOps practitioners that are external to those teams. Sometimes there’s some shared folks, but as an entity the FinOps team is external and they’re the ones who are reactively taking action about whether there’s an efficiency or whether the reporting isn’t right, or so on. And that model is, I think down the road it’ll be a little bit more reactive than we want. Wouldn’t it be better to have that work happening real time in the technical teams as it happens?
Dana Berg [00:26:39] Yeah.
Rich Hoyer [00:26:39] And that’s probably around the time we’re going to start seeing better analytics internally about what the value of your public cloud is versus the alternative, versus a different cloud, or versus the on-prem, because guess what? Those folks might be measured on it. They might have to report against it as part of their role. And so I think they’re going to wind up being more integrated down the road. But we’ll see. We’ll watch this again in a few years and see if I was right.
Dana Berg [00:27:02] Well we’re recording it so we can always go back to the tapes here.
Rich Hoyer [00:27:04] That’s right.
Dana Berg [00:27:07] You know it is interesting, when you joined, we’ve had several conversations around, OK at SADA what do we want to do in the ecosystem as it relates to advancing the cause of increased financial discipline within the usage of cloud? We, as you’ve seen no doubt, have lots of well-versed, skilled consultants that are helping our customers every single day with their cloud environments, our technical account managers, our customer success staff, they’re there helping identify workloads, optimize, modernize, etc. And we discussed, what is it that we want to do here at SADA to start to bring more of all of these great best practices of FinOps into these technical teams like you just described inside of SADA? And how do we provide that across the board to our customer base? Like what are some of your thinkings in terms of how you want to begin to evangelize this within the practice of SADA?
Rich Hoyer [00:28:19] Sure. No, that’s right. And I remember, Dana, when we had that conversation early on when we first met and I think that it was, I think you and I were very much aligned on this from the beginning. Is that the overriding objective of a FinOps practice, whether it’s SADA’s or whether it’s a client’s, is for them to be successful on their public cloud. That’s what we’re trying to do in every way. And so building the organization means that we’re going to look for every opportunity we can for any SADA customer, frankly in any context, to make sure that we’re able to provide them with whatever support is going to further that objective, right? So if they’re already a client and they just need some fine-tuning, great. Let’s make sure all of our teams are able to do that work. If they’re already a client and they’re thinking about standing up a FinOps org and they don’t quite know how to approach it and they need just to have a half hour consultation. Let’s do that. Or if they’re a client that just doesn’t know where to start and they really need to stand up FinOps from scratch, I’ve done this for multiple clients in my prior experience. We can engage them at that level too. So it’s really we’re looking for any context we can to help those clients. Again, whether that’s a brief consultation, whether that’s making sure that we’re standardizing really good practices across all of the SADA teams so that they’re conversant in this, so that they know how to cover the basics. And they also know when to engage the actual SADA FinOps team, the dedicated team. And then, of course, we’re working with the FinOps Foundation, right? So why are we doing that? Well –
Dana Berg [00:29:51] Yeah I was going to ask you, for the listeners, you know we just recently announced our alliance and membership into the FinOps Foundation. So please, what is that? And describe what its charter is and how SADA, and I believe Google now too, the role that we’re playing there.
Rich Hoyer [00:30:14] Yeah. So the FinOps Foundation is really a terrific, terrific story. As you said earlier, this is an emergent field, right? It’s a nascent discipline in the industry. And what happened was a couple of years ago, the FinOps Foundation was founded and actually it spawned out of some folks that came out of Cloudability as it happens. But it was founded to allow practitioners from across the globe to come together and share best practices. So it’s a nonprofit. What a great idea. What a great idea. So we’ve got a bunch of folks that are trying different things in this new discipline. And at some point there comes to be a realization that, hey if we get these folks together, we can cross-pollinate. Everybody benefits, everybody can contribute to this nonprofit foundation. And that’s exactly what they’ve built. So it has become really the global center of learning and training and best practice – it’s become the repository for best practices in FinOps. That’s a great story, you know, starting this foundation. I just love it. Ever since that foundation was established, I just thought it was the best idea. And so SADA’s decided to commit a tremendous amount to this because what did we say earlier? What are we trying to do? Trying to get people successful on the cloud, and the foundation is absolutely the right way to do that. Right? So we can go in there and contribute what our learnings are. Obviously, we can benefit from the learnings of these other great, fine people that are contributing to that. And so, yeah, we’re contributing today in many different contexts. So we are contributing to a lot of the training materials, for example. I’m going to be working on a piece right now that I originally actually gave to the engineering team when I was at Cloudability. But the leadership at Cloudability asked me to teach a class that was finance for engineers. And the reason was that as software engineers –
Dana Berg [00:32:03] That’s great.
Rich Hoyer [00:32:03] It was so interesting, Dana, because they were writing code and they didn’t have the context of what they were writing. So there were basic fundamental concepts in finance that they’re like, I don’t know what amortization is, but I need to have this function software. And they said, Rich could you just give an hour class on the basics? And so we’re going to write that as a curriculum in the foundation so anybody can go and benefit from that knowledge. You know, maybe you were brought into an engineering team, they’re asking you to get involved in this FinOps – maybe you’re one of the folks they’re going to make a timeshare out of and you kind of like, I don’t know what I don’t know. Well, here’s this great resource where they can go and say, oh I’m going to take finance for engineers and now I’m going to have the context of what I’m going to be working on in there. So that’s a little bit about what the foundation is. And we’re just really happy to be involved with it and really share our best learnings with that foundation, gain from other folks’ learnings. And candidly, it’s a lot of fun. It’s a lot of fun to be working on it.
Dana Berg [00:32:58] It is. You know, I participated in their last monthly call, and I know you were giving a presentation there. And it was great to see the customer involvement and people presenting. And they have even titles like FinOps practitioner inside of these massive organizations and they’re sharing what’s working and what’s not working. And the amount of collective intelligence that’s being shared in that form is great.
Rich Hoyer [00:33:29] It gives folks a chance to be really creative, right?
Dana Berg [00:33:31] Yeah.
Rich Hoyer [00:33:31] Imagine taking part of your workday and saying, well I did this really cool thing and it worked really well and now I’m going to get to go tell other people about it. It’s just, it’s cool. Everybody’s enjoying it, everybody’s having a lot of fun doing it. It’s terrific.
Dana Berg [00:33:41] Yeah, that’s awesome. So a couple last things. So I imagine, and across our thousands of customers that we have, you know, there’s different degrees of where they are in their evolution and their maturity. I don’t think any of anybody feels like they’ve got this completely nailed and some are further along than others. But so many are just getting started where, you know, they’ve been in a race to just get to the cloud and continue to expand their footprint and innovate and provide new capabilities to whatever business model that they happen to be in. And I think a lot of them now are at that phase where, hey I got to get started. I’ve got to create this muscle memory on how to regularly control, govern, and feel like I’m controlling this and it’s not controlling me. You know, what’s your advice to a customer? Obviously, you mentioned that, you know, you can engage SADA, you know, to kind of help get you going and get the blueprint started and put the roadmap together. And obviously, those are great things that we’d love to do. But like preview what those kinds of things are that you would say are some of your initial best practices or thoughts on how they get started.
Rich Hoyer [00:35:04] Absolutely. And I’ve seen a lot of that where it’s kind of like, what is the first thing you do?
Dana Berg [00:35:08] Yeah.
Rich Hoyer [00:35:10] So here’s what it would look like. The first thing is try to identify who might be on the team. Right? So who are we going to poach some hours from? And volunteer them. And it’s usually folks that have, again, some kind of tangential involvement to this activity already. So you’re going to have folks that are like – or what we call FP&A (Financial Planning and Analytics.) A lot of times folks like that already are touching this data. And so you’re going to try to identify who they are. So step one is assemble the group. Step number two is enable them. And that means – the best thing I would recommend is going to the FinOps Foundation and taking the training there. They have a great certification program and that will give them a really good basic overview of what the discipline is and what the best practices are. So, and again, make it cross-functional, right? So finance/accounting, technical teams, and maybe other folks that are involved with this. And again, if the spend is growing rapidly enough and the stakes are large enough, by all means they can find that perfect LinkedIn profile that says, FinOps practitioner by all needs, feel free to hire. So that’s the first one is the talent, right? Is what talent are we assembling to do – tooling – and I don’t think folks should overemphasize tooling enough and the solution for that enterprise is really going to depend on kind of where they are. We’ve seen a lot of organizations that try to build their own in-house tools. In general, I’m not really personally a huge fan of that approach, only because the off-the-shelf tools like Cloudability or Ternary are so strong that why would you take these really fine minds and have them rebuild something that’s already out there? Chances are we can take those really fine minds and apply them to interpreting that data in a way that’s a lot more insightful as opposed to data science it’s already been written. So in general, I’m a fan of the commercially available solutions for this if their cloud console isn’t getting them the reporting that they need, right? And it really depends on each organization. Some are fine in the console that they have. That’s great for them. If they do find they’re having people writing a tool I would really encourage them to think about adopting one of the commercial tools. So that’s really what it is. It’s going to start with people. Then you’re going to have the right tooling that’s in place so that they’re getting what they need out of it. And then the third obviously is kind of the governance part, right? Is once you have all that assembled, then you’re going to start operating and starting to decide where is there a need for governance that causes us to be less reactive and triage less. We don’t want to do FinOps by crisis. That’s not what you want to be doing. And if you’re doing FinOps by crisis, that’s your first indication that the issue has to do with governance. And governance, and again, a variety of topics that can be policies about what people are or are not allowed to do when. But it can also be organizational governance against labeling or tagging. Can we trace every dollar to responsible parties? That’s a big one I’m a fan of, is that every dollar be traceable to somebody who’s accountable for that dollar. That kind of governance. So that’s really how it gets started. Who are the folks? How do we get them trained? Do we have the right tooling? And then take your temperature and say, are we episodic about this? Are we having FinOps activities because of crises? And if so, what governance is going to sort that? And again, crisis could be a ballooning bill. It could be a big anomaly in your spend day to day. But another example of crisis is, holy cow we’re spending X per year. And at the end of the year, I literally can’t charge back 20 percent of it. How’d that happen? That’s a crisis. We’ve got to be able to charge it back. And I’ve seen that happen. So that’s kind of the third part is governance and getting a sense for, are we well under control? Do we feel like we’re calm? We’re not having a bunch of emergency meetings. And that would be that, you know, hopefully you get down that road and that’s how it starts to look.
Dana Berg [00:38:57] Yeah. I know you’re working a lot with Google now. They’re taking a very big interest in this. And, you know I always, I wonder how much of being successful at this is somewhat dependent on the various clouds. I think for the most part, this discipline and these policies and practices that you’re putting into place are somewhat cloud agnostic. But there are probably nuances within the various clouds that require different control mechanisms and different governing mechanisms. Explain kind of what some of the things that we’re working on with Google at the moment.
Rich Hoyer [00:39:37] We’re really excited about this. So we’re going to be partnering with Google to get some of their customers and some of our customers into a one day workshop to talk through sort of what their FinOps experience is like today and talk through what issues they’re facing, what issues they’re struggling with, and see how we can partner with Google’s FinOps practitioners to figure out exactly what the right approach is for those clients. And so we’re really excited about that as a general thing. You know, you’re absolutely right. I think that as I’ve traversed the various public clouds over the years, something on the order of 80 or 90 percent of the disciplines float right across them. That as far as, especially around optimization or reporting or things like that. And then there’s that last 10 or 20 percent that can be very cloud specific. There are certain dynamics about certain services that go with each particular cloud provider. And I’m thinking specifically around a couple of things. And one of them is in each provider, there are certain services that I’ve seen be prone to inadvertent balloons of spending. And that’s why I’m a big fan of anomaly learning in your practice so that you don’t wait the whole weekend and go, what just happened? You know, somebody took over a bunch of stuff and did some Bitcoin mining or what have you. And I’ve seen that across each of the clouds. Right? So that’s one thing is being on alert for which of that cloud services is prone to inadvertent blooms of spending. The other is, is where are the opportunities to optimize? And for example, the way that Google charges for compute is really novel, the fact that you can kind of make really interesting, you can kind of bake your own version of a compute instance provides, that’s one example of the unique optimization opportunity that some of the other clouds don’t offer. So that’s how I would describe it. But, so there are some things that are certainly specific to Google. But yeah, we’re going be partnering with them and meeting a bunch of customers and having these day-long experience workshops and thinking through and talking more. It’s a little bit like the foundation in a way, we’re going to be hearing and listening and hearing kind of what their challenges are specifically, and I think that’s going to inform both Google and us. And then we’re going to see how, if there are clients that have ongoing challenges, how can we partner to see if we can’t address those with Google?
Dana Berg [00:41:56] Amazing. Great stuff. Rich Hoyer. You know, I had lunch with the leaders of the FinOps Foundation several weeks back, and I was so excited about you on the team. It was so much fun hearing them talk about you personally. And they said, there’s like three or four people in the world that are the grandfathers of FinOps. And Dana, you got one of them. And I am so thankful. I feel so privileged to be able to call you a friend, a colleague, a member of the team. There’s going to be a lot of great things that come out of this practice that you’re building. I know you’ve got some people now you’re adding to your team, you’re creating new kinds of services that are going to be offered, that are going to be embedded into the base level support and services that we provide to our customers. But, and all these other great services that are going to help customers get kick-started into the right direction and get better control of this. And man Rich, there is no one better in the world than you to have you lead this. So I thank you for being a part of the team. And I look forward to all the great things that we’re going to accomplish together.
Rich Hoyer [00:43:15] Thank you so much. I appreciate that. That’s terrific. Thank you.
Dana Berg [00:43:19] All right. Well, thanks, Rich.
Rich Hoyer [00:43:20] All right, thanks, man.
