How to Build Your Cloud Native Balance Sheet - Danielle Cook, Akamai & Simon Forster, Stackegy

This session, led by Simon Forster and Danielle Cook, explores the concept of a cloud-native balance sheet within organizations. They address the hidden costs associated with how teams operate, emphasizing that beyond infrastructure expenses, factors like people, processes, and policies significantly impact overall performance. The speakers present a framework for understanding cloud-native value by contrasting assets and liabilities, arguing that current financial measures often overlook elements crucial for driving cloud-native adoption. They advocate for a shift in focus from merely tracking costs to assessing the value generated by investments, such as in developer platforms and a blameless culture. By creating visibility around these metrics, organizations can better align financial strategies with operational efficiency and talent retention.

Welcome to this session on the cloud native balance sheet. My name is Simon Forster. I'm a technical architect. I work in financial services in London and I'm a CNCF ambassador. And I'm Danielle Cook. I'm also a CNCF ambassador, director at Akamai, and one of the co-organizers alongside Simon of the Cartographers Working Group. So we are here today to ask, are you an asset or a liability? So

within the cloud native community, within loads of organizations, people think infrastructure is their biggest cost. And yes, it is expensive. But what's also really expensive in your company is how your teams work. And we don't really have a great way of measuring that. And so we're operating with these invisible liabilities across our organization. So this is our kind of standard balance sheet view. So we have assets

on one side, liabilities, equity on the other side. And every every company has one of these balance sheets. If you haven't seen it, you can probably find it somewhere. But does your organization have one for cloud native? And can you actually identify what cloud native, like the value it's generating, and if it's creating any drag within your organization? So a few disclaimers that we want to make.

We are not accountants. My father's one. He would be horrified if I ever tried to present myself as one. We're not prescribing a very specific framework. There's loads of different frameworks out there. And we're not trying to replace the methodologies that already exist in market. We're just trying to help you bring that lens under one view. And it's also really hard to quantify some of these numbers.

We've had a go at it, um, but obviously, you know, attend and then give us your feedback. Great. So, um, we think that, um, a traditional balance sheet within an organization can often miss quite a lot. It's got assets, it's got liabilities, it's got equities. And we can see things like the cost of, say, cloud infrastructure and service provider costs, for example, or hardware. But we think

that people, process, and policy, we think these things are more opaque, um, and we think that they really actually help drive cloud native delivery. Um, we think, for example, that finance can tell us what we're paying for people, but it can't really tell us if they're getting ready to leave. Likewise, a balance sheet traditionally might tell us that we've got processes, but it can't necessarily tell us

whether those processes accelerate or or block Um, and, uh, it can tell us, you know, our finance team might tell us, "You're compliant with such and such a regulation." But it won't tell us whether we've got governance that actually enables compliance or really kills it. Maybe that's not its job, but we want to bring those things out. Just to point, these pillars, they come out of the

cloud native, um, computing foundation cloud native maturity model. Uh, and, uh, we're just using that as a framework, um, and, um, we're finally we're using a balance sheet because we want people who control budgets, investment, and investments to finally see what's what's really going So, we're going to look first at the problem of what we're doing today. So, we, um, we're solid at measuring infrastructure and the

cost of it, but we're ter- terrible at reporting like how work actually gets done, and that's a lot of what the value is for cloud native. So, digging into it, we have problem layer number one, the visibility gap. So, finance he's kind of servers, they see spend, they see savings, but it doesn't see, you know, slow deployments, manual approvals, developer frustration, different teams waiting on different teams,

and these liabilities are invisible. We also have capex versus opex, right? So, the real shift we see is this buying infrastructure versus building capability. And we don't have a great way of measuring that capability. We also know, everyone knows here about technical debt, but how about organizational debt? So, you know, we have the problem that, you know, manual processes, siloed teams, fragmented tools, like all of that,

slow feedback loops, that all impacts or creates organizational debt, and that's all of the things that slow you down as a liability, and that never shows up on the balance sheet. We also reward bad behavior. So, you know, we'll celebrate a cost reduction, but it might slow down the team, or we might optimize team utilization and be like, "Yay!" But actually our team's completely burned out. We

might be trying to standardize on tools, and that is very, very, very, very valuable, but at the same time, it can reduce autonomy. So, we're not always financially incentivizing the things we want to see in practice. And then finally, like, what happens, what's the business impact? We have slower time to market, higher attrition, inconsistent delivery, and you know, these are things that you know, we finance might

think everything is under control, we're doing really, really well, but the real problems, they're not necessarily on the books. Um and so the system says you're healthy, but it's it's actually slowing you down. um let's let's take a look at this. You know, if we think that um CapEx and OpEx, for example, is a red herring, well, what should we actually be talking about? And just a

note on CapEx and OpEx, CapEx is buying servers, OpEx is paying for them effectively on an hour by ba- is so so minute by minute basis. Now, the old framing really was how much, you know, do we spend? And we think that it should be what did that spend actually enable? Um you know, many organizations with a let's say a relatively low maturity might not have a

lot of cost governance at all. And by the time they're mature, it actually becomes one of their most valuable assets. So, we think that um moving from um seeing FinOps as cost cutting to FinOps um it's something that um allows us to go and shape demand. You know, it's making sure that every dollar or euro of consumption, you know, leads to a proper business outcome. And we

think most critically that having finance, engineering, and product all looking at the same data, and not finance getting a bill monthly and passing it on to an engineering team to justify, is really where we we should be heading. So, we think that um with spend tracking, we move towards value governance as our main main argument. So, what do we think we should create? Well, we think that

the answer might be what we call a cloud-native balance sheet. This is um just a um a a a model or a way of looking at something. Again, we're not accountants. So, we think that every decision that we face within um a tech organization usually does one of two things. It can either create leverage or it can create drag. And then we think that that in turn

determines our ability whether we win or not. So we think it's really about how work flows throughout system. We don't think it's purely a finance thing. We think that almost anything can create drag or leverage. So this is what we think a balance sheet might start to look like. This is a really high-level and very simplistic version of it. On the left-hand side we've got things that

speed us up. And on the right-hand side we've got things that slow us down. We might see things on here like an internal developer platform. We think that's an asset. Manual approvals. If I have to go and log in to something and tick off something, it can be really frustrating. Automated definitely an asset. But that legacy monolith, that's expensive and difficult for us to maintain. A blameless

culture, that's really important particularly when things go wrong. But burning out our staff, we that's that's a real liability for us. We think that we're all familiar as individuals as engineers and and architects and developers with almost every item on this list. And we but we don't tend to track them in this way. So we think that when we start tracking them like this, the conversation can

change because we've got, if you notice, culture and process sitting next to technology on the same page. So in the next few slides, I'm going to walk you through a few examples technology and process and uh and people and um where you get the values for these items is really up to you. I want to make that clear. But we think that what matters is bringing them

together, so you can decide where we are and where we want to invest. And I will say that we do have um a uh QR code for you later, which will give you access to the sample balance sheet. So uh that's coming as well. Okay, so technology. So if we look at up here, we can see a few things. We've got fragmented and shadow tooling on the

left-hand side and monitoring blind spots and VM sprawl and actually a really obvious one, uncontrolled cloud consumption. Then we also see other things like flat networks and core segmentation in there Then if we look on the on the asset side, we've got IDPs, we've got um automated CI/CD pipelines, and we've got containers and Kubernetes adoption, which is always a great thing to see at KubeCon. And we've

got service mesh network policy. What we can see is that for every liability, we have sort of a an adjustment, an asset, or a different perspective. Now, we've not gone and put values against these, and again, we'll hand that over to you to think about what might work for you. Then we move on to process. And on process here, we've got a few things. Manual change approvals

or manual change management. We've got, you know, late-stage security gates. Sometimes it's a little bit too late when it's already in production. Uh we've got tribal knowledge and stale documentation. I've had that problem myself, and sadly I admit I've also created stale Um but then we've got great GitOps-driven workflows on the on the right-hand side. The point is is that what we can see threaded through here

is we've got a whole lot of process related activities, yet um they're not something that we would typically go and stick on a And And now onto the people side, and this is where it can get just a little bit political. You know, um a fear-driven or a blame culture is really difficult. It's difficult for people to be to to be within. Um and um dealing with

training debt or uh burnout and voluntary turnover. And key person dependencies as well. You know, um sometimes it's wonderful to think, "Well, I'll always have a job because I'm the only one can do it." But that actually creates a lot of stress for an individual and also for an organization. But on the right hand side, we see things like psychological safety and trust. And um also leadership,

cloud-native alignment. When our leadership is aligned with a strategy of cloud-native adoption, it is a real asset for us. So the point is again, we've got liabilities and assets that meet up. So if we look at this kind of in practice, we kind of are looking at one organization, same company, perhaps different teams. And we kind of have a level one, if you will, uh team that

has some legacy drag happening, and then kind of level five, if you're kind of reached high maturity in in the balance sheet. And we will be showing you one of those. Um so you know, on the left hand side with level one, we're looking at a culture of blame. We're looking at manual processes, maybe security is not necessarily up front in the process. We're also looking at

fragmented tools. Um on level five, we're getting away to or we're getting into a high trust environment. We have kind of fully automated CICD processes that's been sped up and we're using technology under a unified IDP um, and it really open source first, right? On the left you might be heavily reliant on a vendor, open source on the right. Um, so we're going to look at our

balance sheet. Um, so the idea here is not necessarily in every single number. We've kind of given you some sample numbers and ideas. And we want you to be thinking about this as a tool and not necessarily as kind of a full math equation cuz we're not accountants. Um, but you have here a list of assets and liabilities and then equity and how that works together. And

we've taken you through kind of a five-year look ahead into the future at this pretend Acme organization where at level one, you know, they're they're kind of making trade-offs um, and then getting, you know, five years in the future where they're a very mature again, um, the most important thing about this balance sheet is that it makes things that previously weren't visible visible. So, the numbers, they're

ones that are arbitrary in this example. They do add up, by the way. Um, now, um, just to go and step through a few of these things. At level one, we see that Acme is entirely underwater. You know, for every $5 or 5 euro uh, of debt, um, they have $1 of And their biggest liability isn't technology, it's actually in people and culture. Burnout, silos, and blame

might be costing more than the infrastructure itself. And then at year two, they're starting to cross the chasm from negative and into positive equity. And this is the moment where investments and IDPs, culture and policy start compounding. We're no longer just sort of fixing pro- problems, but we're actually starting to build up a just a little bit of momentum. And at level five and in the year

2030, uh we see that this company, you know, the model completely inverts. And for every 5 cents of debt that they're carrying, you know, um they've got 5 cents of debt for every euro. I'm sorry, of of capability. And that's up by 100 times. So, they go from minus 1.5 million up to 8 million in equity. So, what we're saying is that we think that cloud native

isn't just a cost optimization strategy. It can actually really create value across all aspects of an we think that organizations that understand that might win. And this is meant to demonstrate that value to people who might not understand the technology or the process behind cloud native. It's speaking a language that they're used to with a balance sheet. Yeah. So, we also wanted to bring up just a

few of the costs that, you know, we don't often talk about as well, which might be the cost of delay. So, just, you know, if we take take drill into some examples and you'll have access to the resources there. We can see that, what is the cost of delay if a job actually goes and sits within a queue? Well, in Acme's balance sheet, we found that manual

build and release, you know, ends up with a $68,000 liability and ticket driven provisioning adds another 80,000. So, that's 148,000 in drag. That's features not shipping and and value not realized. And then by level five, those same items drop to 34,000. So, that's freeing up 114,000 every year, not by cutting spends, but retiring process liabilities. And that's money that we're already losing. We're just not counting it.

Yep. And then we moving on to the cost of a failure. Untested resilience. You know, outages that happen because we didn't bother testing the HA. It has happened. Um, late stage security gates and manual compliance checks. You know, when these things fail, we might say that for this company, that's added up to 171,000 in failure exposure. And that's incidents waiting to happen, breaches that haven't we haven't

caught, or compliance that gaps that we only find at audit time. And by level five, that drops down freeing up, you know, 132,000. So, these numbers don't appear on a traditional balance sheet, and we think that's a blind spot, and that's what we want to to address and make visible. So, when we talk about this cloud native balance sheet, we're not just trying to kind of theorize

about it. We're trying to help you articulate the investments that you want to be making as leaders at your organizations, or people who want to introduce, you know, IDPs at your organization. So, three kind of investment examples that we have here. So, an IDP where you take a bunch of fragmented tools and you actually create a golden path in a, you know, a platform that your developers

can use and self-service from. That's an investment that will help you eliminate tool sprawl, help you speed up delivery, and something that you can quantify as an asset on your balance sheet. Um, blameless culture. So, uh, you know, this is how we unlock people capital. We keep them happier. Uh, replacing a employee can um, cost 50 to 200% of their salary. So, if we can move to

a culture where we're, you know, helping people achieve what they want to, increase productivity, um, ownership, learning, then, you know, we're we're actually reducing our risk of turnover and the cost of that to the business. And then policy as code is another example. So, maybe some of you were Carvel on yesterday, but, you know, if we can implement policy as code and shift everything left, we can

catch things earlier and help reduce, um, the impact of, you know, breaches and whatnot on on the organization. So, across all three of these, you're making intentional investments, um, that increase your assets and actively retire some of your debt and risk. what are the next steps, you know? We think actually that, um, a practical step that we could undertake might be to do a balance sheet review.

And that might be to, um, get three people in a room, you know, from engineering, product, and finance. Not necessarily a steering committee, but really just three people that can make decisions. We might set aside 15 minutes each, go through assets and liabilities, score them, and then pick a liability to go and retire over the next quarter, for Agree on who owns it and agree on how

we might measure it. And we think that that's really is a great place to start and it can be as simple as that. Do it simply once a quarter, but most importantly, the conversation shifts from how do we cut costs to where do we actually, uh, invest for for leverage? Again, the resource sheet spreadsheet will be on the resources slide and you can scan the QR code,

but actually, we don't think you even need that to begin. You need to start with a conversation. So, uh, what we're proposing is kind of simple. It's a better way to kind of drive performance within your organization. So, you know, measuring what matters and speaking the language that finance teams and C-levels are speaking. Um it's recognizing that some of your biggest risks and some of your biggest

costs are invisible to you as an organization, so that review can help you articulate that. Um and it's taking the balance sheet and um shifting it from a cost discussion to a strategic conversation. And I it's not meant to be a replacement for finance. There's always, you know, we need that. It is kind of a metaphor for opening up that conversation. Um and have your first balance

sheet review when you get back to your office. Um these are the resources we talked about. So, we do have a um Google Doc sheet uh that has examples of a balance sheet. So, there's several tabs in it. There's liabilities versus assets at a high level. There's a more in-depth view of that. There's also a sample balance sheet as well as a more kind of worked example

of that balance This presentation's in it, as well as um we added our talk from last year's KubeCon around kind of documenting ROI and business impact of of cloud native because it's kind of complementary to it. So, um if you'd like to uh find out more, if you'd like to contribute, if you'd like to help really shape, again, the future evolution of the cloud native ecosystem, come

and join us. Um Danielle and I are part of the Cartographers working group. We produce artifacts for the cloud native ecosystem and to further adoption. We meet bi-weekly, and uh you'll find links to both the maturity model that uh forms part of the foundation of this, as well as our GitHub repo there as well. And uh yep, we're on Bevy or communities.cncf.io as well. We'd love to

meet you. And this is the QR code for feedback to our session. So, thank you all for attending. Thank you.