FinOps in Action

FIA - Dann Berg
===

Dann Berg: [00:00:00] Accountability is a big piece. I mean, bringing visibility to both the tasks that people are doing as well as the work that everybody is doing and the impact that it has. Right. So I'm not just giving people a laundry list of things I would like them to do, but when they are performing these tasks, you're celebrating those, you're sharing those within the company, you're enabling the Team A to share knowledge with Team B

Alon Arvatz: Hello, everyone. Today I'm super excited. To host a dear friend and a well known figure in the FinOps industry. He's a FinOps leader and a community builder. Before FinOps, he was [00:01:00] actually a tech journalist, with his outriding featured in major publications. More recently, he has held senior positions in FinOps at major tech companies, co authored two full length plays with his wife, including The Floor Show, and today he is the Cloud FinOps Lead at Squarespace.

Dann Berg, happy to have you with us.

Dann Berg: Thank you so much. I kind of have been all over the place, it sounds like, for my intro, but it's fun to do lots of different things.

Alon Arvatz: You have a very diverse experience, and I'm sure that fusing all of it together helped you do a lot of great things today as a FinOps leader, and I would like to go straight to it. And you joined Squarespace not too long ago, so you were probably tasked with building or revamping your FinOps program, and this is why I'm really, really curious to hear more What do you think should be the FinOps Practitioner's top priority?

Dann Berg: Yeah, so I joined Squarespace. A [00:02:00] little less than a month ago, so I'm still new. They're still getting ramped up. And I think one of the things that I'm personally focusing on, and I think a lot of people should, is one, visibility and shortening the feedback loop when it comes to cost. So, Visibility starts with tagging.

So you actually know what the spend is. And then the second part of that is getting that cost data into the hands of the people that are incurring costs, which usually is all of engineering because all of engineers have the keys to turn on more infrastructure. And so, engineer, if they make a code breaking change, will know instantly.

There will be the website shut down, there will be a bug, there will be some sort of feedback that's immediate. But when it comes to cost, in most instances, that feedback loop could be a month, a month and a half long. And so, really, you know, Your goal as a FinOps practitioner is to shorten that feedback loop and just make sure [00:03:00] people have the data so that they can make informed decisions about what to work on, whether that's a cost saving thing or whether that's just continuing to focus on what they're otherwise, the features they're working on.

Alon Arvatz: So you talked about data and the importance of data, which is for sure extremely important when it comes to FinOps, but I would like to double click on that because I feel that there are a lot of different types of data. So very often when I talk to other FinOps Practitioners, they talk to me about Cloud Spend data.

Which is the obvious part, but there's also more technical data sets. There are data sets that are more financial. I wonder what types of data do you have in mind when you talk about making sure you have the data and disseminating it across the organization?

Dann Berg: Yeah, well, that is a really good point because there's multiple levels of this data visibility. Um, the first is just basic cost data. Like, do you know where all your dollars are going? Uh, and who is [00:04:00] incurring all of those costs? Uh, and that is just base level. You definitely want to get that set. Um, but one of the examples that I sort of think of is, You're eventually going to have some sort of cost anomaly.

Costs are going to spike, maybe costs are even going to go down, and you're going to have to do an investigation as to why that is. And the why has to do with the underlying metrics and data that cause that cost to spike. Because cost is kind of like the highest level of abstraction. It's the ultimate, like, what hits the wall.

It's the bill. And so you're going to want to get lower level in terms of that abstraction. And oftentimes that's going to be usage metrics. That's going to be disk IO. That's going to be network throughput. There's so many different aspects of it. And eventually, in order to shorten that feedback loop to, okay, you want somebody to know if there's a cost anomaly. You don't want to show them that cost anomaly if you just onboarded a customer, and so you have a cost increase and there's a paid customer behind [00:05:00] it, right? Like, that's good cost increase. And so having all the data available in order to bubble up the right sort of cost anomalies and be able to explain all the different changes in cost.

Alon Arvatz: I totally agree with you. And I can tell you that something that I talk about a lot is the fact that spend and cost is a derivative of infrastructure. And like you said, you have a cost anomaly. There is something that happened on the infrastructure level that caused it. So when you talk about cost anomaly or deliver cost only data, you have to understand the underlying root cause and take care of that.

Dann Berg: I would say that's one of the limitations of cost data in general, because often it's going to be one or two days late behind. Uh, and so there's a lot of methodologies or a lot of tools there that can sort of give you a forewarning about upcoming cost anomalies by using data infrastructure metrics to like catch that spike as it's happening in the infrastructure and being [00:06:00] like, Oh, this is going to show on your cloud bill in two days.

And so it gives you sort of that headstart. So again, on how advanced your practice is, your goal is going to be shortening that feedback loop when it comes to cost.

Alon Arvatz: that's fascinating. So instead of measuring cost spikes and then understand what caused it on the infrastructure level, monitor the infrastructure and predict what's going to be the cost spike,

Dann Berg: Yeah, exactly. And when it comes to finance, this is not really the most, uh, favorite methodology, right? Because finance wants to be able to tie the usage and the cost back to their invoice, right? But when it comes to engineers, engineers don't care what finance pays for the bill. They're going to care, I made an action and that action had an impact on that bill.

And so the actual dollar amount, it's okay if that's fuzzy or that's okay if it doesn't include a enterprise discount. It's okay if it doesn't include those things. What engineers need to is [00:07:00] I made an action and here is the feedback in terms of cost, uh, and really kind of like separating those two branches where, okay, I'm talking to finance, here's how I'm looking at the data, or I'm talking to engineers, here's how I'm looking at the data differently.

Alon Arvatz: nice. So you talk about specific data sets for finance, specific data sets for engineering, is there a different data set that you would use for senior leadership?

Dann Berg: It depends on what the senior leadership is drilling into. Typically what I'll do is senior leadership likes to see both sides of those. And when you're distilling things down to senior leadership, uh, the way that I think about it is you really have to know, like, 360, full circle around the data. And then what you're going to want to do is present to the Like a slide, maybe two slides, like really high level information, but with links that allow them to self serve the data if they want to dig into it themselves, or you need to know it inside and out in case they ask you questions.

So when you're [00:08:00] going up to senior leadership, it, I don't really think of it as the two different like engineering or finance. It's just that a super high level, like, hey, we spent 50 percent more and then they can drill in in whatever way that they want to look at that data.

Alon Arvatz: And obviously leadership cares a lot about a cloud spend and infrastructure spend in general. It's obviously a huge cost center. When you create these reports with the data that they actually need from you, do you also leverage it to convey the value or the importance of the FinOps function?

Dann Berg: Yeah. I mean, I think once you start having, I mean, when you approach front ops, uh, there's quick wins you can get. So buying Reservations or shutting down unused, unattached volumes, all those sort of like things that everybody knows. Um, and you can start doing that and having an impact on the bill and just seeing either the costs go down or them leveling off is enough to start [00:09:00] showing the value of the FinOps Org. Uh, aside from that, there are different methodologies that teams can track to say, okay, we made this change. We're counting that as X number of dollars that we saved per year. And putting that all together into a report is a nice way to do it. I would say not everybody is doing that. And I don't think there's a standard way to show that data.

So right now, FinOps practitioners want to show that, it's kind of like, how does my senior leadership think about this? And how can I present it in a way that works for their brains rather than a standard? But I do think that it's valuable just because the FinOps team is doing so much good work and having a positive impact.

Having some way to put numbers on that, I think is, is important just to justify the practice and to show the value that you have.

Alon Arvatz: Absolutely. And FinOps function is not only about saving money, it's about changing the culture. changing the culture of efficiency and how people care about efficiency and think [00:10:00] about the cost they incurred the business. So definitely, I think it should be highlighted as well. But like you said, adding that to the numbers is really, really helpful.

Dann Berg: Yeah. I mean, what I've seen over I don't know, six or seven years working in this space, is that a lot of individuals and a lot of companies discover FinOps because they want to save money. That's like the impetus to do the searching online, to discover the FinOps Foundation, to discover all these methodologies.

They're like, great, we can save this money. And then there's just Such rich beyond that, that they're realizing that they can do that are best practices when it comes to communication. There are standards for the way to organize and present data that kind of implementing a FinOps practice. Most people used to think of that as, okay, we're going to start saving money, and now it's this whole thing.

Like you mentioned culture, it's just communication, it's bringing different teams together, uh, and I think all of [00:11:00] that sort of is what FinOps encapsulates in a bigger picture way.

Alon Arvatz: And you mentioned in the beginning that you want to disseminate this data to create short feedback loops. And also informed decisions. I wonder if there's also an aspect of it, of actually drive action. So disseminate specific data types or data points that will actually drive action from senior leadership.

engineering or finance, and I'd be happy to hear if you have an example for something like that.

Dann Berg: Yeah, so, uh, I think that's a really good thing. Um, just because I think a lot of people, I mean, for many years, the FinOps Foundation would do an annual survey about what the biggest challenge is for FinOps practitioners. And at the top used to always be driving action for engineers. Like, how can I get engineers to take action? I think if I remember correctly, it's kind of dropped off a little bit because FinOps seems to become more empowered to just do work themselves. Um, but also [00:12:00] I think that Trying to get engineers to take action is the wrong way to think about it. I am an unbiased third party in this. I'm collecting the data.

And so if I'm putting together, for example, a queue of individual tasks that could save the company money, when I'm doing that analysis, I'm kind of trying to take a look at, okay, what is the size of this effort? And what is the impact in dollar signs, right? So I'm putting together this information. And then I'm presenting that both to engineering teams so they can say, Oh, if I do this work, which is a medium t shirt size effort, I'll save 10, 000.

Um, or maybe that doesn't matter to me. My team spends 2 million a month or whatever. Let's instead focus on these features because that just doesn't make that much of a difference. So showing that to engineers and allowing them to prioritize things and then also Bubbling that up to senior leadership, because maybe senior leadership has a [00:13:00] picture of the business that is kind of stepped back a little bit and can say, Oh no, we have tasks across all of our engineering org.

And if everybody does this medium t shirt size effort, we'll save enough money to make it worth kind of holding or slowing down whatever roadmap items were existing. Um, and so for me, I'm just trying to show people the data and help them make informed decisions about what to work on.

Alon Arvatz: So in other words, if I'm understanding correctly, you say that you are not expecting the engineers to take what you provide them and just do it.

Dann Berg: Yeah,

Alon Arvatz: expect

them to take it and embed that into their decision making process.

Dann Berg: well, they're going to have to justify to senior leadership if they don't do this task that I've given them, right? Like if I show, Hey, you can save this amount of money by doing this. If they choose not to do that, that's fine, but they're going to be the ones that are beholden to explain to leadership why they didn't.

And maybe they have a great reason. Maybe that's okay for the business, [00:14:00] or maybe their priorities should change a little bit, but that drive is going to be coming from their management, not me and some outside person. organization trying to make people do things. Cause that just doesn't work.

Alon Arvatz: Right. But in other words, maybe what you're creating within the organization is accountability.

Dann Berg: Exactly. Yeah. Accountability is a big piece. I mean, bringing visibility to both the tasks that people are doing as well as the work that everybody is doing and the impact that it has. Right. So I'm not just giving people a laundry list of things I would like them to do, but when they are performing these tasks, you're celebrating those, you're sharing those within the company, you're enabling the Team A to share knowledge with Team B for how to do something and just really being that centralized point to have that communication and working well together happen across the entire company.

Alon Arvatz: And it also makes sense because Very often, engineers have [00:15:00] context that use affinit practitioners don't have it. They're very close to the business, they're very close to the application, they know the in and outs of the application, the requirements for the infrastructure, and sometimes you say, hey, it's low effort, tons of savings, but you don't have other context around compliance or performance or future plans that engineers have, and you don't.

So in many way, you say, Hey, I give you a mirror. These are the opportunities you have. If you don't do it, no problem. But you have to justify it. You have to explain what is the reason you're not taking action.

Dann Berg: Yeah, and I think one of the ways that people can be strong FinOps practitioners is to go into it seeking knowledge. Like, hey, I have this idea. Can you teach me why this is not a good idea? Right? If they are declining something, what is that knowledge? And then adding that to your tool chest for next time.

Because I think one of the best examples is, When you log into [00:16:00] any cloud platform or a vendor, often what you're going to see is a list of recommendations. And they're like, hey, right size all these boxes or turn these off. And a lot of times engineers are going to look at that and be like, okay, well, we can't do that here because of X, Y, or Z.

We can't do that here because X, Y, or Z. And one of. The ways to be a better FinOps practitioner is to start learning that internal knowledge so that you can be the filter to prevent those sorts of pointless tasks that they can instantly rule out from even getting to the engineers. You're kind of serving as that shield so that when they actually recommendation from you, they know, okay, it's already been vetted to a certain degree.

And maybe even like the amount of action I have to take is super small because they did a lot of work on the back end. And so that's kind of how I see it as well.

Alon Arvatz: And we already started talking about the engagement with engineers and how we provide them with the data and recommendations. And you shared a few tips already. For example, celebrating success, [00:17:00] not expecting them to do exactly what you want them to do or implement the recommendations as is. I want to talk about on the other side of it.

What do you think is the biggest mistake that Phoenix practitioners make when they engage with engineers?

Dann Berg: Ooh, the biggest mistake. Uh, I mean, I think it's sort of what we touched on is to see their role as trying to get engineers to take action. Um, or I mean, a lot of times. Uh, I've seen FinOps practitioners be so focused on just saving extra dollars that the effort to savings ratio just starts to go off, right?

Because a lot of times they're going to start with the big wins and you're going to start saving huge numbers. And then as you work down that list of tasks to do, the savings get smaller and smaller. And so you're going to be like, poking and prodding and trying to get work done to save small, uh, amounts [00:18:00] of money, uh, in reference to like the larger organization. And I think there's a certain point where you need to step back and kind of have the bigger picture idea of the company in your mind for knowing, where to push or if it is time to be like, okay, well, we don't actually need to save this extra money because it's too much work. And giving yourself permission to back off on things sometimes.

Alon Arvatz: And I see then many FinOps practitioners that spend a lot of time on chasing engineers to take action or to give them this feedback. Now let's assume we're still not in this phase where the savings are very, very small and not worthwhile. I still have like a big chance of savings that I would like my engineers, um, um, to do.

Okay. What's your recommendation around that? Like how to go about it? Like, do you feel that if a FinOps engineer is now [00:19:00] chasing his engineers, so he's in a bad problem, it means that he has a bad culture issue in his organization. Does that make sense? He does that. It's part of his job. What's your perspective?

Dann Berg: Yeah, I. I don't see myself as ever chasing engineers. Um, and I think this is why having an executive sponsor as part of the program is so important because I want the engineers to be beholden to their bosses. And so again, I want to be able to empower the entire organization from engineers all the way up to C suite with the data. And then if an engineer is choosing not to take action, that's okay. Maybe that's justified, but they're going to be answering to their manager or they're going to be answering questions about like, why didn't we do this from them? That way it doesn't come from me. I'm just giving people information and I'm hoping that's why, like I said, the executive sponsor and the senior level is going to trickle it [00:20:00] down.

And if they're asking questions about it, engineer who's not taking action is suddenly going to start taking action.

Alon Arvatz: And I also feel that a major part of making it happen and having success with that is also building trust with engineers. Uh, trust for me is built. You know, number one on data accuracy, but it has many components to it. What are your tips to building trust with the engineering organization?

Dann Berg: Yeah, I think this is super important because the way that I've seen FinOps be as effective as it can be as is as part of the engineering org. And as such, I work to be embedded on the engineering team. And I sort of see my role as to, uh, defend the engineering stance for doing things, right? And so if I ever have a recommendation, I have an idea for something to do, I'm working with those engineers to learn all [00:21:00] angles of that recommendation, why it can be done, why it can't be done. All of those sorts of things. And when you're really embedded in the engineering org like that, you build that trust and you build those relationships. And again, it's all about having more information and more knowledge, because then I can take that knowledge back when I'm doing my analysis, when I'm presenting to senior leadership and, and it all goes full circle.

So at the end of the day, I sort of see myself on the same. level and the same like team as the engineers. And I just have a slightly larger kind of, uh, pool of knowledge and, and data that I'm working with. Uh, but at the end of the day, I'm bringing that to the engineers. We're collaborating together to either get stuff done or choose not to.

And then that information gets disseminated out to the rest of the company.

Alon Arvatz: And actually you say that being part of the same organization with them is a major part of it. And it's very interesting. You mentioned the Finos [00:22:00] Foundation, uh, surveys. And in the past, they used to ask, who do you report to? And through the years, you can see that more and more FinOps practitioner report to the CTO or CIO and less to the CFO.

So it looks like what you mentioned, it's actually a trend today in the FinOps industry.

Dann Berg: Which I think is a fantastic trend. I think that's really great. Um, one of the really cool things about the space and about FinOps is I think that it, it has given a lot of people that are not engineers or technical by background, an opportunity or a path to get into more technical roles. And so I think we've seen a lot of people on the finance or FP& A side, sort of. see the opportunity and just start getting really deep into their knowledge with cloud, getting, start getting really embedded in engineering teams. And then the engineering teams are seeing just how valuable it is to have this sort of persona on your side. And so they're bringing them into the [00:23:00] fold.

And for anybody out there that is on the finance side and is interested in moving into engineering, because it's a great opportunity, It's super interesting. I, I really enjoy it. Uh, I think FinOps is a really great opportunity. And, uh, it just is, it provides a path. And there are a lot of people in the community who have that experience that are totally happy to help people figure out their own path that way too.

So I think it's really great.

Alon Arvatz: 100 percent and I think I've seen many like this. And if I'm not mistaken, you also don't come from a technical background, right? You actually studied in, in college, uh, English literacy, if I'm not mistaken.

Dann Berg: So I had a creative writing, uh, with an emphasis on playwriting as a college degree. Uh, and then I was briefly, as you mentioned, a journalist, so I wrote for Laptop Magazine and The Verge, and so it was always with tech and electronics, um, but I really found my first opportunity in tech working in data centers.

So I was working with vendors, buying servers, [00:24:00] network switches, sometimes actually going into the data center and racking servers, um, but From that perspective, I was working with finance to understand the cost implications of all the servers we were buying, and that company, MediaMath, was growing in the cloud at the time, and so I had an opportunity to step in and apply sort of what I was doing for the data centers to what was happening in the cloud. Uh, and then after that, I found an opportunity at Datadog, which is a hundred percent based on cloud spend. And that's sort of where I discovered that FinOps was a thing and that other people were doing it and really, uh, the career path really opened up in front of me and I started seeing a lot of the options available.

Alon Arvatz: Nice. And then for people that listen to us, they want to do this transition into a more technical FinOps role that is part of the engineering organization. Do you have any tips on how to bridge that technical gap?

Dann Berg: A study. I mean, there's, there's no way around that. Uh, fortunately, the [00:25:00] FinOps Foundation has a lot of really great free resources. They also have some really great certification courses if you want to kind of speed that up. Um, and then each cloud provider, AWS, GCP, Azure has different training that's available as well.

And I think it's going to be easier if you are currently working at a company where you can kind of, think the best way for people to move forward is to be able to identify an opportunity and then go towards that to say, Hey, I want to be doing this, or I want to be helping with this and really taking the initiative.

And so when it comes to advancing in this space or moving into FinOps, it's going to be a lot of. learning what you can from the free resources or the paid certifications, and then seeing, looking around where you can apply it, even if it is outside your current role, uh, working with the people that are doing it and wherever you can apply value, people are going to see that value [00:26:00] and they're going to want more of it.

And I think that's, that's the best way to move into these sorts of spaces when you want to.

Alon Arvatz: And if I go back to your observation that FinOps should be part of the engineer organization, do you feel that FinOps or the FinOps practitioner is more of a finance guy or more of an engineer?

Dann Berg: Ooh, that's a good question. I, I agree. I don't really think of it like that. I mean, at the end of the day, it is really a fairly even melding of both. Um, I mean, if I had to say one, I would possibly say more of an engineer, just because From a finance perspective, I would say it's a lot more difficult to make the bridge into learning all of the engineering stuff.

There's a lot of certification works, things like that, versus if you're starting from the engineering side. Getting a hold of the finance [00:27:00] stuff, given the foundation of knowledge, um, might be a little bit less of a lift. Although I imagine maybe there will be angry people sending me messages after that.

I don't actually know. Um, but just sort of my perspective, that's sort of what I've seen. So I kind of think of it more as like engineering, especially when it's embedded in the engineering org.

Alon Arvatz: Nice. And we talked about the trend of FinOps people moving from finance to engineering. I wonder if you see additional trends in the FinOps industry? that would shape this industry in the next five years or so.

Dann Berg: I mean, I, I think the, there's two things, and these are both things that the FinOps Foundation has identified, um, the first one is the shift left, uh, and if you ever hear that phrase and you're not sure what it means, it basically means FinOps often is a reactionary thing. There's a spike in the cost.

You've got to figure out what that is. You go back and do detective work. What [00:28:00] shift left means is shifting that process earlier so that you're using cloud caused data to inform decisions that people are making in terms of what to even develop. Uh, and so I see that happening more and more where people are Again, FinOps is just about data, right?

So they're providing that data at an earlier stage in order to make informed decisions. Um, and then the other thing is what the FinOps Foundation calls scopes. And that is. The FinOps practitioner have brought a lot of value when it comes to cloud cost. Can we use some of these practices when it comes to our data centers?

Or can we use some of these practices when it comes to other variable based spend SaaS applications that we're using? And I think kind of expanding and using the, the foundational practices that we've built and FinOps and applying it elsewhere is going to be what We see in the next five years,

Alon Arvatz: Very interesting. And I heard some people making a [00:29:00] distinction between SaaS solutions like Snowflake or, or, um, or Datadog and the like, and things like Salesforce and more classical SaaS solutions. Do you believe that FinOps will expand to Salesforce and more classical SaaS solutions as well?

Dann Berg: I see FinOps is partnering with procurement and that procurement department, but not necessarily replacing it. I think where the practices that have been developed under the FinOps umbrella, where that excels is with variable based usage based spend, right? And so that's going to be Datadog. That's going to be Snowflake.

Um, but if you have a contract that doesn't change over the course of 12 or 24 months, um, each month. It's less interesting from a FinOps perspective because you're not trying to evaluate usage to understand the cost. And so [00:30:00] I think it'll expand. I mean, you can put other SaaS, like. Flat spend, static spend, SAS in there just to bring visibility all in one place. Uh, but when it comes to the actual practices of optimizing the bill and optimizing usage, it's only going to be usage based stuff that really gets the bulk of the benefit from the practices that we're doing.

Alon Arvatz: And you think that if you don't have any dynamic costs, meaning you don't have costs that derive from usage because you don't use the cloud, for example, do you think it's worth even adopting a FinOps function or it would be an overkill for something like that?

Dann Berg: Now, it really depends on what you're calling FinOps, right? I mean, the sort of the way that I'm speaking about it today. answer is sort of yes, in terms of certain practices, just because, again, I sort of see FinOps as being really good at knowing what information to look for, and knowing who to [00:31:00] show that data to. And if you're not running in the cloud, you're just in a data center, there's going to be a lot of benefit in knowing what data to look for and knowing who to show it to. So if that's what you're calling FinOps, then yes, but that for a lot of people isn't called FinOps. That's just best practices or that's just common sense.

Right? And so it really depends on what you are calling it.

Alon Arvatz: Understood. And then you also had the opportunity to work with a very dynamic tech companies. You didn't work in more traditional industries, for example. Uh, do you see any difference? In doing FinOps in these type of companies in comparison to bigger, more traditional enterprises.

Dann Berg: Yeah, I think the more traditional enterprises, uh, and the ones that have been around longer, uh, there are different challenges than once they're cloud native from day one. Uh, cause when you have, Uh, a history of working at the data center and you have finance [00:32:00] organizations that are used to doing accounting a certain way, there's a lot more of a change and a shift to get them working with turning their CapEx to operational expenses.

And so, uh, I think been really fun for me working for a lot of companies that have been cloud native from day one, because you kind of are at the forefront of what the best practices are. And you're working in my experience, working with finance organizations that are really open to doing things new way, are really interested in the dynamic data that we have, and are forming new practices around it. And that's a lot of what I see. Um, but the thing I think that is heartening or makes me optimistic about the future is that I think a lot of those practices that were developed in these kind of cloud native forward thinking organizations are now moving towards the larger enterprises. And so we're seeing a lot of these bigger companies adopting these practices, because We're figuring [00:33:00] out, yeah, this I think is the best way to do this.

And so everybody is just starting to do that one thing that one way. And so I think pretty soon, I like, if we're still talking about the five year trend, a lot of companies, regardless of their size and scope and everything are going to do things with regards to FinOps in a similar way, because we're standardizing on what those things are.

Alon Arvatz: And do you think that doing FinOps for a cloud native company introduces special challenges that you won't face if you work for a more traditional enterprise?

Dann Berg: I mean, unique problems, but maybe unique in terms of. Talking to the rest of the community. Uh, so when I was at Datadog, um, and they were cloud native and we were working on certain levels of visibility and unit economics. Uh, when I went and talked to other people as part of the finops foundation, a lot of people were doing lift and shifts or moving from on-prem to the cloud.

So I sort of felt like. As a trend across the [00:34:00] industry, people were in the process of moving into the cloud, and that's sort of where we as a community were. But when I went back to my day to day job, we are working on things that were different. Um, and so I don't think that they were necessarily unique, but I do think that you have to kind of like pinpoint the other actors in this space who are doing the same thing as you, and then that can be your, your brain group for, for figuring this stuff out.

Alon Arvatz: Nice. And DDann we already learned a lot from you in these, uh, 30 minutes. I would like to spend a few minutes to learn more about you. And we already mentioned that you have a very, very interesting and diverse, uh, background. Uh, so today you live in New York, in Brooklyn.

Dann Berg: I'm in, uh, downtown Brooklyn. I've been in Brooklyn for about 20 years now. Uh, so yeah, Arizona previously, but I, I like Brooklyn. I moved here in New York for college and I just kind of fit. And so I've stayed,

Alon Arvatz: Very nice. [00:35:00] So if I take you now to your last day at college, what, what tip would you give to Dann? At that moment.

Dann Berg: oh man, I, I wouldn't give, I mean, I don't know. I wouldn't give him any tips because I feel like I. was able to have a lot of fun post college. Uh, when I say fun, I mean, I didn't get a big, high paying job right out the gate. Um, I worked in retail for many years. I spent a lot of time working in a piercing and tattoo studio, uh, not piercing or tattooing, but like working the counter. Um, so I, I feel like I had a lot of fun sort of doing. My own thing for a long time and I don't think it necessarily had a negative impact on my future career growth And so I would just tell him keep doing what you're doing and enjoy enjoy the ride

Alon Arvatz: And what do you do outside of work?

Dann Berg: Yeah, I mean as you mentioned I like to do [00:36:00] I like to write I have a website and I have a Um, I like to go and see movies, so I literally live right above a movie theater in Alamo Drafthouse, which I'm super spoiled by. Uh, and so often on weekends, if I just don't have something to do, I'll just pull up the app and book a seat and walk downstairs to see a movie.

Alon Arvatz: Nice. Sounds like, sounds like a dream. And do you write today?

Dann Berg: Do I write today?

Alon Arvatz: Yes.

Dann Berg: Uh, I'm not actively working on right now. I'm, I've been toying with a book in the FinOps space called FinOps for Startups. Been making a little bit of progress on that. But no other like creative writing or any process or any like projects going on right this minute.

Alon Arvatz: Understood. I can tell you that I wrote the book. It was extremely, extremely difficult. Maybe the hardest thing I've done in my life.

Dann Berg: Yeah,

Alon Arvatz: So if you

decide to go back on it, [00:37:00] Best of luck. That's all I have to say.

Dann Berg: I definitely still plan to do it. But yeah, it, it's It's challenging and it's lonely. Um, and I'm trying to figure out the best way to approach that. So I have some ideas. I want to get together some like brainstorming groups or some writing groups and things like that and really dive into it. Um, right now, like I said, I started at Squarespace a little less than a month ago.

So most of my energy, if not all of my energy, is focused to onboarding there. But I'm sure I'll get to a space where I'm kind of nights and weekends ready to, to play with a little something else on the side.

Alon Arvatz: Sounds good. Good luck with that.

Dann Berg: Yeah, thank you.

Alon Arvatz: And if anyone in the audience would like to reach out to you, what is the best way to do it?

Dann Berg: you can find me at my website, which is Dannb. org, and I spell Dann with two Ns, so D A N N B dot org. Um, you can go there. There's a few ways to contact me. You can read my blog. You can find my newsletter. Um, I'm on LinkedIn, pretty easy to find, uh, [00:38:00] cause I spell my name with two Ns. It's really good for SEO.

That's the joke I like to do. So if you Google my name, you can also find a lot about me too.

Alon Arvatz: Sounds good. So Dann, thank you so much for being with us today.

Dann Berg: Yeah. Thank you so much for having me.

Alon Arvatz: I would like to thank to all the audience that listen to our podcast. If you learned something new today, please share it with a friend. And again, big thanks to Dann who joined us today. This has been another exciting episode of FinOps in action. See you next time.