Kim Wier - FinOps as Product Part 1

Episode 4 • 26th April 2022 • FinOpsPod • FinOps Foundation

[00:00:00] Kim: Hi, I'm Kim Wier and this is FinOpsPod.

[00:00:04] Stacy: Let me tell you a story about a person. Her name is Kim.

[00:00:22] Joe: That is in the podcast.

[00:00:27] Stacy: That one wasn't meant to be . . .

that was me trying to read Slack while you were doing something else. And I can't even, I would say, let me redo that, but it would just get worse. So.

[00:00:48] Joe: Shall we introduce ourselves?

[00:00:50] Stacy: Let's introduce ourselves?

[00:00:51] Joe: I'm Joe Daly.

[00:00:53] Stacy: and I am Stacy Case

[00:00:55] Joe: This week, Stacy, on the podcast. We have Kim Wier from Target.

[00:01:00] Stacy: Kim. I like Kim and I'm not going to lie, Target's one of my favorite places.

[00:01:05] Joe: I know! It's so convenience, has everything. And it has a great FinOps team. They don't call themselves FinOps they call themselves Efficiency Engineering, which is great. I think FinOps

[00:01:17] Stacy: Yeah.

[00:01:18] Joe: easier to say, but Efficiency Engineering's got a nice alliteration sort of the E sound at the begining, so that's not too difficult to say.

Kim is incredibly active in the FinOps Foundation community. She's on the Technical Advisory Council. Is a FinOps Ambassador, and that's not all that would be more than enough for most people, but Kim also runs the Twin Cities Meetup, which is the friendliest meetup I've ever been a part of.

[00:01:47] Stacy: Yeah. I don't know if you know, this Kim spoke in our summit last year, May, 2021. I think in this, I could be lying about this, but I think that was the first time that she shared anything on the summit. She was a new practitioner spotlight, and it helped present something too. I remember this so clearly because I don't know if you remember this or know this a year ago.

It was when I started my cross country drive across from Oregon to Massachusetts. And, I had to stop for the summit to, to be on the call with J.R. and do that. And I was like, frantic I'm like, where am I going to go to do this? And I actually stopped at a Target parking lot boosted their wifi and I made a comment about it. And during the summit itself saying, Hey, thanks, Kim for having such great wifi in this parking lot. But I did it for my trailer in a parking lot. that's My random Kim's story. And then her and I started talking about traveling a little bit online after that.

Yeah.

[00:02:44] Joe: When we were talking to Kim she had just presented at the FinOps summit in March of 2022.

Noel and I got on the zoom with her and we , talked to her about it. Kim has a really interesting career path as she comes from a legal background. So we were

asking.

That's right. A legal

background.

[00:03:07] Stacy: path we usually see doing.

[00:03:08] Joe: No FinOps for lawyers was not, it's not a thing yet, yet. But this is a non-traditional path coming to FinOps. Kim is probably one of the most relatable people. We ask her about her career path and she sums it up by saying

[00:03:27] Kim: I'm a problem solver.

[00:03:28] Joe: That's a huge skill set you need in life. And as my wife likes to remind me, FinOps is just really life skills, and that you need to apply thoroughly. Well, listen to her, talk about how she took her law degree and it into real estate. And then to it infrastructure, she's been all over the place.

[00:03:49] Stacy: As one does, by the way, as one does.

[00:03:53] Joe: It's real life.

[00:03:54] Stacy: Awesome.

[00:03:55] Joe: and from there, she made a comment during the FinOps summit that at Target, they're building their own FinOps tool set, which Noel really wanted to dig into. So we'll jump in to the interview.

[00:04:10] Stacy: After this message from your sponsor.

If you are going to be around in June, I have a great suggestion for you. I think you should all meet us in Austin, Texas on June 20th and 21st for the first ever FinOps Foundation conference called FinOps X. So you can go to X.FinOps.org to find out more about it.

[00:04:30] Joe: Fantastic. I'm going to be there and Stacy are you going to be there.

[00:04:34] Stacy: Oh I'll be there with bells on or cowboy hats

[00:04:39] Joe: I'm going to get a big 10 gallon hat

[00:04:43] Stacy: oh, no,

they will not be happy with you. Alright And now, Kim.

[00:04:51] Joe: Let me just put the tape in. Here we go.

[00:04:59] Joe: Kim, last time , I was listening to you, you were presenting at the FinOps summit in March. How did it feel to participate in that?

[00:05:08] Kim: So I had participated in the summit early on in my experience with FinOps. So really I haven't been a FinOps member for all that long. Kind of how the story goes. My team has been charged with doing FinOps at Target and we call it Efficiency Engineering.

When my team formed. I had my team as a way to get them aligned to what our mission was. I had them do an exercise where they were tasked with going out and finding anything they could find related to efficiency engineering. We didn't find FinOps in that search, there were 10 or 15 of us searching for what we thought FinOps or what we thought Efficiency Engineering was, but we didn't find FinOps surprisingly.

So it was about six months into our journey that one of my peers, Ron Tatro saw something, read it and he was like, oh my gosh. This is what we're doing. And so he and I jumped in head first and started to get involved. And so with that, I had had a question for J.R.. And I reached out to him on slack and he responded so quickly. I was amazed. And so that was kind of the start of my involvement in doing things in the member meeting. So fast forward to now I was a little bit more comfortable doing the talk and participating. And I think you know, it was easy because it was just sharing my perspective of what the survey results were.

[00:06:48] Joe: Is good. And you mentioned your, your team and your team aspect is really interesting cause then it's a great story. I want to hear about it, but before we get to that, before Kim gets to FinOps and before Kim gets to Efficiency Engineering, you started in real estate. Can you talk about how you went from real estate to efficiency engineering?

[00:07:12] Kim: I'm going to have to go really far back into my career to explain this to you. My undergrad degree was in legal studies, so I came out of college as a paralegal.

And in that experience, I loved diving into, you know, the legal research and doing all of that kind of work. I worked for International Dairy Queen. I worked for SuperValu. I worked for Music Land all before I came to Target. And at each of those companies, they had a database of their legal rights and obligations related to their real estate.

So I started out as a real estate paralegal. I moved into the business of doing real estate, doing corporate real estate. And in that transition I then was kind of the perfect candidate for a real estate negotiator job at Target. Target being in the Twin Cities, Target is one of the best employers. And so I've always wanted to work for Target. So it was the job opportunity. Was there, my skills were there Target was there. So I, I moved to Target. When I came into Target. We had probably 1500 locations. I sat down ready to do my job, and I asked my boss where the database was and she said, what?

And I said, you know, all the information about what our legal rights and obligations were? And she said, Oh, no, we have this excel spreadsheet that has all of our location numbers on it. And then what you do is you try and figure out what the request is about what locations and about by looking at these three columns in Excel.

And I was pretty dumbfounded because going back, you know, years into my past all of those smaller companies had databases. That was the start of my push to get Target, to modernize and find a solution for the legal rights and obligations database. I ended up being the primary person in real estate who brought this technology in, and it was a huge project.

It included scanning all of our legal documents. It included abstracting all of the data out that was pertinent to what we needed. It probably took a year and a half. And so I was doing my day job of being a manager in real estate and bringing in this technology. At the end I just said, you know, we can't have business people doing all of this technology work, it just doesn't work. So we need somebody responsible for the technology strategy for real estate. So I made up my own job and I became responsible for the technology strategy for real estate. Fast forward. How did I get into infrastructure? When looking at my career, I was ready for the next position in the real estate department. My next job would have been a new store, real estate manager and my skills as a problem solver. Don't align with the skills of that job for being a negotiator. So really they do a lot of negotiation with developers and land owners and cities. And that just wasn't me. So I started to look for different opportunities.

And one of my last projects in real estate technology was to bring in a new document management system. While in infrastructure, there was an opening for a senior engineering manager for content management. So I convinced them that I knew enough about that and moved over to that. But I'll tell you. I didn't know, I did not know what I was in for.

I should have gone into a product team, not really into infrastructure. And it's funny. I, I did great. I have loved all 10 years of my experience in infrastructure, but I have to be honest, the like in the first week I was having a status with one of the engineers and the technology he was working on. The JVM went down, so he bounced it. And I was just like, what, what A: what's a JVM and B: what does it mean to bounce it? And so it, like, since that point, it's been a 10 year learning journey for me. And that's how I became here.

[00:11:46] Noel: So listening to that, I can tell you the one thing that I heard really clearly that said you're definitely going to work in FinOps was a spreadsheet of the buildings and locations. And that's what you use to work with. Because I would say nearly everyone I've met in FinOps started with spreadsheets, managing the costs and then migrated tools.

And I genuinely would like to ask you, cause I know you said that , the FinOps summit in March around you're developing your own tool in house, I'm interested in that there is some good products out there on, on, I know other companies who have developed their own tools. What was the logic reasoning?

Why did you choose to go down that road? Because I think it's interesting. I have an interesting story. If nothing else.

[00:12:36] Kim: Yeah, it is an interesting story. And it all I think aligns to when Mike McNamara became the CIO of Target, he has done incredible things to transform Target's IT position. He really shifted us from being waterfall to agile. His influence led us to a product model. The whole organization has changed under his leadership. And one thing he really believes firmly in is we need to have the knowledge here. He does not want to outsource the knowledge to other companies. Targets development by and large happens in house.

We built up a really strong software engineering culture and software engineers. And so we do all of that development internal.

[00:13:34] Joe: Does your team support the tooling that you use or do you leverage other teams inside of the technology department?

[00:13:43] Kim: We're a year into our journey and we spent basically last year doing a lot of work manually, and that was doing manual analysis and then partnering with the product teams who use Google cloud to, you know, auto scale and optimize their workloads. So we have this manual track happening while at the same time we had two teams.

One really developing the, the data pipelines and getting the data that we need for our Efficiency Engineering perspective and tooling. And then we had another team working on the engineer persona application. And then we actually had the data team also was working on dashboards for our leader persona.

[00:14:36] Joe: Explain to me, the engineering persona software perspective that you just mentioned.

[00:14:42] Kim: The application? So, yeah, , we have a product taxonomy, we have, you know, the application, the product ,product group all the way up to the portfolio. We know that an engineer is more interested in understanding the specifics at their application level or maybe even their workload level.

So we've built our tooling that gives them a tool to understand how their application or their workload is how efficient it is, how much it's costing, how much they're utilizing. Versus we have a dashboard for the leader persona that shows here's how much everything is costing. Here's how efficient your organization is.

That kind of thing.

[00:15:32] Joe: I understand better now. So you have a team that's pulling in all the data that you need for your Efficiency Engineering, and then you have are these two separate groups, a group that is focused on. Providing that data towards the leaders and then also another group providing that data towards the software application engineers.

[00:15:55] Kim: So we are one team, we're all under Efficiency Engineering, but to really optimize our development, we've naturally broken up into different sub teams. So doing more backend development and the data pipelines, and then doing that front end develop.

[00:16:13] Joe: That's really interesting. I've not met anyone who has a set up like this. So tell me more, how do you manage this team? How do you work? How do you build them and develop them and find

[00:16:25] Kim: That's going back to the whole transformation Target infrastructure has also transformed into a software engineering culture. And so where we used to have traditional systems administrators by and large, those roles are now software engineers. And so when they formed my team, it was really like a amalgamation of engineers from different parts of the organization whose jobs were changing. I got some people who were infrastructure in data science tools. I got some engineers who were system administrators in more traditional VM and server technologies. And so we created this team and part of our transformation has been really teaching them software engineering skills.

I would say every single person in my team has been transforming over the past year. I had a couple of engineers who had been doing software engineering before Efficiency Engineering. And so they've really helped guide the team and help to mature them in those software engineering tools. We have specific learning plans for each person and especially as new people join the team, here's the technologies you need to learn.

We give them time to actually learn. We commit time for them to learn. We do a lot of pair programming, which helps advance that learning. And eventually they become great, awesome software engineers on my team.

[00:18:06] Noel: It's a team of software engineers. There's no other skillsets in that grouping is that true?

[00:18:11] Kim: That is true. Yup.

Then we also have these early tech talent programs where, you know, getting tech talent is a challenge today. And if you think about getting FinOps tech talent, that's an even deeper challenge. We have these early technical programs where we're partnering with and sponsoring, diverse candidates, then interview for jobs at Target and are placed on teams. And so I actually have three, we call them emerging engineers on my team. And they have, you know, a 12 week bootcamp under their belt, and then we teach them everything else. I cannot tell you how incredible these three women are and how much of an impact they've made to our team. There's that. That's a whole nother learning journey. And then I'm on my own learning journey.

My background is legal studies. And then I have an MBA while now Target has this whole new education benefit. I'm currently pursuing my masters of science and information technology degree. So I am on a learning journey as well.

[00:19:23] Joe: That is awesome.

[00:19:26] Noel: It is. I want to ask questions, but I'm thinking I can't ask certain questions because you'd have to tell out trade secrets and then poor old Joe, just have to edit them out anyway.

[00:19:35] Joe: Yeah. I just delete them.

[00:19:36] Noel: I know. that's the thing, as, I don't know, do we want to go down

[00:19:39] Joe: I know.

[00:19:40] Noel: might be able to come back.

[00:19:41] Joe: That leads to this question, Kim, you're transforming people's jobs. A lot of you said some of your team came from the infrastructure background and you're teaching them how to become software engineers. In the meantime, you're pulling in all this cloud cost data from GCP. So your software engineers and your infrastructure engineering, while working together on this new way of working are also learning financial aspects of the cloud. I mean, maybe it's magic and you got it all right on the first time, but what were some of the road bumps and how did you get through this transformation?

[00:20:20] Kim: That's a great question. And it's yet to be seen if we were successful or not. I mean, we've definitely had a lot of learnings along the way, and even we just went live with our MVP and we already know , oh, we've got to change this. This part isn't going to work for us. Which I think is that whole product model, right? You start with an MVP and then you iterate. So one really fortunate thing happened early in the formation. We got two really seasoned engineers from the platform team that was managing Google cloud for target. So they really had a depth of knowledge of how GCP worked, how the billing worked.

I don't know if we would have been as successful as we are without those two individuals. They came in and helped guide the team and shared their knowledge. They shared their knowledge with me. They shared their knowledge with the team. I think having that depth of knowledge has really helped as well, but they are also in that software engineering transformation journey.

So they have that deep infrastructure knowledge. But now they're learning the software engineering side as well. So it just makes the whole team better. When you give people opportunities, you bring in the right knowledge. It just makes a stronger team.

[00:21:45] Noel: Let's Let's I go back there to something you said a second ago where you said that you just reached your first MVP. Straight away, you know, you need to make changes, improve. That's the whole idea of agile. Great. How did you get buy-in or support to create a brand new tool, knowing that there's a journey and that you're not going to start then two or three sprints, turn on, turn something out, right.

As opposed to saying, Hey, can we go and get something off the shelf? Use that initially and then develop something or was it a case of, because your culture sounds like it's developed in house and I liked that and I keep the knowledge in house and I liked that, but, was it easy to get that level of support to allow you to go yeah, here's a greenfield go build it.

[00:22:33] Kim: Yeah, it really is the culture. We didn't really have to go get support from anybody to develop it. My senior vice president believes in Efficiency Engineering and he sees the value in Efficiency Engineering and so, you know, it was under his leadership that we created this team.

So we have the support at the CIO level, at the SVP level, at the VP level. They help guide us, but they don't tell us how to do this. You know, we've made this a product and we're now responsible for building the best tool that we can. We actually just in the last three months, got a product owner. And I think that will help us mature this capability so much more in 2022.

[00:23:28] Joe: Tell us more about how you are able to... So many teams are small. They don't have that opportunity to build the product. How are you approaching building your own tool?

[00:23:40] Kim: I do think that we fortunate to have our leaders really driving this it's important to them. And so it's a priority. One thing that target does is when they have a priority, they really work to resource it adequately. I am fortunate to have the size of a team that can actually develop this product.

One thing that, from my legal background, I understand the importance of not copying other people's work. So we didn't go out and pursue, you know, have a demo from this vendor or that vendor. I didn't want us to be clouded with anybody's ideas and I don't want anybody in the end to say, well, you took that capability from me. We developed this. We didn't have anybody else's perspective as we did this. So, it's our own.

[00:24:34] Joe: It's this fascinating FinOps as a product, Efficiency Engineering as a product. You just mentioned you hired a product owner for the tool. I've not heard this story before in the industry, this is great. Do you have feedback loops for your stakeholders and what is that process like? What are they telling you?

[00:24:57] Kim: Yeah. So with the addition of the product owner, his first responsibility is going to be going out and talking to the engineers who are going to use the tool and get their feedback. You know, FinOps and Efficiency Engineering isn't like, well, what do your customers want? Honestly, they don't want any of this. They need this. And we want them to have this information. And so we developed the tool based on what we know and understand. We do have partners within our product engineering teams that we would go and say, hey, here's what we're doing. How does this look? How does this sound? How is this coming along? And they would give us feedback. But now that we're at MVP, we will be going back to many more of the product engineers to say, how do you want to see this information? One thing I think is also interesting is efficiency engineering at Target is just one and I know this is true of everywhere. Product engineers, they have so many priorities and it's hard for them to balance those priorities. They have developing new features. They have lifecycle management, they have incident and change and all of those things that are coming at them that are important, then how do you prioritize them?

And then you have this utilization. How are you utilizing your infrastructure? How much is it costing? You have performance, you have to understand your performance. Where we're headed is eventually we want to have a holistic platform for a product engineer to go to, to see all of the things, not just my tool efficiency engineering I need to have.

And my team has been building with this future perspective in mind. All I want is for the one surface where a product engineer goes to see how are things and do I have any opportunities? So we will build just a little efficiency indicator. Are you good or are you not good if you're not? Click in for more, and that's where they'll come to our application, but if they're good, they don't have to think about it.

[00:27:15] Joe: So can hear the listeners asking the question out loud, and let me step in and defend you Kim. Get off her back! She hasn't built it yet! They want to know and Noel, you may be able to give insight on this as well. If you're going to create a single pane of glass that has a lot of health metrics for an application team, and you want one metric to represent the Efficiency Engineering health check, what do you have in your mind for that one metric.

[00:27:46] Kim: That's really good. My team had created an efficiency indicator, it's a battery icon, and it tells how efficient an application or workload or product is. But that's the one feature that we want input on from our product engineers. So I don't actually have the vision for it yet. So it's going to be driven by the product engineers. What do they want to see? What's important to them in understanding where their efficiency perspective is at.

[00:28:20] Stacy: Joe, what was that noise? And also, are we time traveling? Cause you know, I'm only at the beginning of interviews, never at the middle. And I feel like we're in the middle of the interview now.

[00:28:30] Joe: We can be anywhere we want to be in an interview, Stacey, we're all over this podcast, but that was the noise of tape getting scratched, that was that very moment where Noel and I have the way we know how to do FinOps, just completely smashed in by Kim.

[00:28:48] Stacy: So, what you're saying is this is the exact moment where you and Noel had your mind blown.

[00:29:01] Joe: Exactly. So what you see is when I had a FinOps team, I ran it like finops as a service model. I had a third-party tool, a very common one, it's very good, and my team and I use that to measure the efficiency of applications. And what we would do is we would go to the applications and use our efficiency metrics. Pretty much preset by default. and we said, Hey, app team, you are efficient or inefficient. It was, what do they look like inside the box that we had created? pretty effective, for a lot of workloads. This is absolutely fine. And it's a very fast way to start going and to start reducing waste as

[00:29:45] Stacy: Got it. Okay. But, so what's the difference between that and then what Kim said.

[00:29:51] Joe: Well, Kim is running FinOps as a product model

[00:29:54] Stacy: Okay.

[00:29:55] Joe: the product model based on an application team input. So instead of Kim and her team saying what efficiency is. is asking the application team, how they are defining what efficiency is. It's very different. For out of the box solutions efficiency is basically the comparison of spend to how much of a resource is being used. Kim doesn't have that default built in equation. So that means that she could be basing what efficiency is based off of whatever metrics the application team is using. There could be factors that generate value for the business, like speed of transaction, or how quickly can it scale. There's all sorts of different things that the business may be looking in on that don't necessarily correlate directly to spend versus utilization of the resource. It's a completely different approach. And what you'll see is Noel and I kind of are a little bit shaken by this approach. And as we begin to wrap our minds around what it means and what it could do. It's pretty cool honestly.

[00:31:04] Stacy: So would you say we jumped back in and listened to the rest of this interview?

[00:31:08] Noel: I want to go back to your saying the the product engineers , the people that are writing the software, who are building the tools, building the apps and putting it out on the cloud. Right? You want them to tell you what's efficient? Have I heard that correctly? Because what I'm hearing is you want the poachers to tell the gamekeeper where they're going to be.

[00:31:33] Kim: Well, I think in the best interest of Target they want to utilize their infrastructure as well as they can. And so I think it is important to ask them how do they want to see how well they're using that infrastructure resource?

[00:31:53] Noel: I could dig in here because in my company where we're looking at this sort of thing in slightly different lens, but the same outcome? We've been using the tools that have been provided by our vendor to kind of say, Hey, look, this is what it's telling you. And they're giving us back reasons why, what they're being told is yeah, I can right size, but I don't because, right. So we're trying to take that information from them and create an efficiency score for them. and work it that way, but we're not letting them lead us. We're going to them with a score first asking them why it doesn't work and then going. Does that hold water? Is that a fair statement? And looking at their patterns of something like this.

I liked the way that you're asking them to, to help you build it. It's good. That's going to encourage them to buy into it as well. Right. And work towards it.

[00:32:39] Kim: And I think it does. You know, you have to understand the data and you have to understand what those recommendations are coming out of the analysis. So. You can all put that together. So I think it's very similar. I just think at where we're at in our journey, we see the indicator that we've created might not be what they would want to see.

And we just want to make sure that that it is what they would want.

[00:33:08] Noel: The way you're saying that or understanding the data. We see a lot of data in the whole FinOps space and it's very easy to see all the data to draw the conclusions and come up with a thing at the end of it. And one of the things I've learned from doing these interviews for the FinOpsPod right, is I looked at the data for one of the people we're interviewing and I came to a conclusion about that person and I was wrong. Right. But all the data said I was right. And it's a learning, I'm taking an into it. And when you're saying that, there's understanding that, but also getting the input from the people who generate that data to help my learning of it. Right. That's that's is it working? Is, is, is it helping, isn't making, as you said, you haven't developed your score, your what that number or what that is yet, but are you definitely heading in the direction?

[00:34:00] Kim: Yes. Yep. We are definitely headed in the right track.

[00:34:06] Joe: It makes a lot of sense to me because for two years in a row now in the State of FinOps survey data getting engineers, encouraging engineers to take action on opportunities has been a struggle. It's been one of the top struggles, if not the top struggle, but I have a theory based on my experiences , sometimes yeah, you have the engineer who just doesn't care, but more often times it's the engineer who has context that the FinOps practitioner doesn't understand. So based off my metric, my measurement of efficiency, they seem really inefficient. However, they're saying, yeah, I'm spending a lot of money, but I'm running this for a really short period of time and I'm not incurring additional, extra capital costs. Whatever the engineer is doing to support the business, doesn't match my efficiency metrics. May be nailing the business's efficiency metric, which is an interesting concept. I like the way you're approaching this.

[00:35:08] Noel: It's actually going to get engineers, developers doing the right things, as opposed to, Hey, we're going to measure your RI efficiency, how much RI you've got out there, right? Reservations and stuff. And they will buy reservations to ensure that they're getting measured correctly.

But yours is more well that may not be something that's important to you because to go back to what Joe said a minute ago, if they're going to be running an instance for six hours, a 24 hour, RI is no good to them. In fact, it's a waste and it's driving the wrong behaviors. So you will drive better behaviors, longterm, which is good, which is what we all want.

[00:35:43] Kim: Yeah. And that's in our product roadmap too. You know, we can spit out recommendations based on what our platform partners view as important to the platform. You know, when we make our recommendation, that engineering team might not be able to execute the recommendation. So we want them to have a feedback loop back to us to say we can't because we have this, that requires us to do it this way. And so that's in our product roadmap as well.

[00:36:15] Joe: This is interesting how creating your own tooling is creating processes on how to perform FinOps, Efficiency Engineering in your company. Out of, out of how you're building the tool. It's very interesting.

[00:36:32] Noel: I'm When going to use this as a thing way into our part of the podcast can't say savings plans for RDS. So my question is if you were the CEO or manager or owner of any of the kind of service providers out there, what one thing would you like to see them release for FinOps right. Well, one tool would it be, and it can't be savings plans for RDS.

[00:36:59] Kim: I think that the billing processes are overly complex. I think that it's hard to understand what's coming and going in your invoice. And when you get into the cloud bill this at the scale of Target or other large retailers or any large company, it's really complicated and hard to understand.

And so I would say just improving the billing would be a nice add or change.

[00:37:32] Noel: There is a section on the FinOps.org, I think, where they tried to take terminology from the bills and an equal it out. So that's, you know, what's in one is the same. Same the other. And I firmly believed that part of the reason that bill is so complex is so nobody understands it.

[00:37:49] Kim: Or, you know, it might be what differentiates them. They don't want any of that as part of the secret sauce. I don't know. I don't know why it's complex. But it is complex and it would be nice if it was easier to understand.

[00:38:00] Joe: My theory is that nobody wants to work on the billing team of a cloud service provider. You get folks who are on rotations and they get the okay into the billing closet and they have to work on the billing features and then they get out. So they could go work on the cool stuff, leaving us practitioners to painfully parse through the bills.

[00:38:24] Kim: That's an interesting perspective.

[00:38:27] Joe: That's that's my theory. It can be proven wrong, but maybe not. Kim, this has been a fantastic conversation. I want to continue tracking how you're coming with your product. As I'm sure all the listeners will as well after they listened to this. Cause you are confronting head-on what many practitioners wonder and think about And the most important thing is you're definitely coming back here in a year's time to tell us how you get in, how you're doing on this journey.

Absolutely

[00:38:59] Kim: I'll come back. Thanks for having me. It was fun chatting.

[00:39:02] Joe: Thank you so much.

[00:39:04] Stacy: wait, is it over?

[00:39:07] Joe: Unfortunately. Yes, Stacey. It is, but this clearly is just part one of a multi-part series. We'll check back in, on Kim in the future and learn how she's progressing. What challenges are a team going to run into and how are they going to solve them? Plus the 2000 questions. I'm sure our listeners are screaming for us.

And you know what, calm down. People podcasts don't work like telephones or snap chats or what apps you can hear me, but I can't hear you. It's a one-way communication style. We'll get your questions later, when Kim comes back again, but you know where there'll be two way communication styles, Stacy.

[00:39:50] Stacy: I do I do it. Could I answer this? I know the

[00:39:51] Joe: Yes!

[00:39:53] Stacy: It's going to be in June at FinOps X.

[00:39:57] Joe: That's right.

[00:39:58] Stacy: Texas.

[00:39:59] Joe: Two way conversations all over the place. Go check it out X.FinOps.Org. Register!. Come in on Sunday night, leave Wednesday. You got two full days of content.

[00:40:12] Stacy: And a day of training.

[00:40:14] Joe: It'll be fantastic. And I'll be walking around in a 10 gallon hat in cowboy boots, it'll be great. And I can't wait

That is it for today's FinOpsPod! You did it You made it to the end, you are a true FinOpstanaut! Thank you so much for listening. You don't want to miss when we release new episodes of FinOpsPod, give us a follow wherever you listen to your favorite podcasts.

Thank you so much, Kim Wier from Target for being our guest today on the show. Thank you to my co interviewer, Noel Crowley. And Stacy Case for being a great podcast host this with me.

FinOpsPod theme song "Cheesepuffs and Caviar" from Geoffrey Burch. Thank you so much.

That's it for today. We'll see you next time on FinOpsPod!

Share Episode

Shownotes

Transcripts

Follow

Links

Chapters

Video

More from YouTube