SRE Leaders Panel: Business Agility is what matters, SRE can help you get there

Blameless recently had the privilege of hosting SRE leaders Garima Bajpai, Founder at Community of Practice - DevOps Canada and Jason Fraser, Delivery Lead at VMware Tanzu to discuss the value of crisis during incident response, the best and worst tech transformations they’ve seen, how reliability impacts the flow of value, and more.

The transcript below has been lightly edited, and if you’re interested in watching the full panel, you can do so here.‍

Christopher Hendrix: Welcome everyone. My name is Christopher Hendrix. I am a staff software engineer and developer evangelist here at Blameless. Today we have Jason Fraser and Garima Bajpai. I'd like to start off with introductions.

Garima Bajpai: I'm Garima Bajpai. I'm based out of Ottawa, Canada. I'm the founder for the Community of Practice of DevOps in Canada which has three chapters: Toronto, Ottawa, and Edmonton. I'm also the organizer for the DevOps Summit Canada which will take place November 8-9 this year. We welcome you all to join that summit. I'm also associated with organizations like DevOps Institute as an ambassador, as well as Continuous Delivery Foundation as an ambassador.

Jason Fraser: Hi, my name is Jason Fraser. I am currently with Tanzu Labs at VMware, which was formerly Pivotal Labs. I'm still sporting the Pivotal logo. I've been with that organization for almost seven years now, mostly in product management roles. Currently I'm leading product management and design for the Tanzu Labs public sector team. I'm doing a lot of work helping mostly federal government organizations build successful software labs that can deliver outcomes for the American people. So that's a lot of fun. I was an early proponent of Lean Startup. I had a company prior to joining Pivotal that developed concepts around Lean user experience and helped to promote those concepts.

Christopher Hendrix: The title of this session is a little bit different than what would maybe be expected for an SRE Leaders panel. The title of this panel is actually “Business Agility is what matters, but SRE can help you get there.” I chose this topic particularly because I think our attendees, even if they might be ICs in the SRE space, deserve these cross-disciplinary learning and product-oriented practices, and they all touch the SRE space. Our audience could really benefit from contextualizing the SRE movement within the history of other big transformational movements.

I'd actually like to start with some foundational information for our audience. A lot of people have heard the term agile, and there's a lot of mistrust these days about what we'd call big "A" Agile practices. I'd like to roll it back and get to the root of what agility means. Why was Agile the term that was coined for these kinds of practices? Jason, could you tell us what the Agile Movement is from and what agility means?

Jason Fraser: People have been building software for a long time, right? And there are lots of ways to build software successfully. Agile is not the only way to do it, and it's been proven that you can build successful software without doing anything agile. But I think it was in 2001 that a group of people got together in Colorado. These were mostly engineers who had been thinking about not just how to write better code, but how to deliver better software products. And they landed on some core principles that you can find in the Agile Manifesto. And if you Google the Agile Manifesto it's just four core statements that are pretty easy.

The purpose behind it was really to deliver better outcomes. With the way the Agile Movement has proceeded since then, we have demonstrated that you can have a fairly small team deliver very high quality products relatively quickly if you embrace some of these practices and, more importantly, the mindsets that go along with the practices. I'm a fairly pragmatic practitioner of agile. There's the big "A" Agile, which for some people is like a Scarlet Letter A. If what you are practicing is helping you to deliver the outcomes that you need to deliver for your customers and your business, I don't care if you're doing SAFe. I don't care if you're doing scrum. I don't care if you're doing XP.

It's that you're doing it better than you were doing it before. The final point about agile is that it stands in antithesis to waterfall development, which has become kind of a curse word now I think. But the way that tools used to be created, software used to be created, was you would spend a bunch of time writing a spec, identifying requirements, and then you would task someone to build against those requirements. And when your process takes seven to 10 years, you find that a lot of things are obsolete before you actually get to delivery.

Agile was meant to address the learning that happens during that period of building. You're not only learning about the code base that you're building (discovering things about the code base that you couldn't have predicted), but you're also learning more about how your customers and your business are thinking about the value that you're trying to drive. And as you're learning about that, as that value proposition changes over time, you need to be able to adapt. And that's what Agile is structured to allow you to do.

Christopher Hendrix: Garima, do you have anything to add to that? I heard the words adaptation, and to me that's really important. I'd like to hear your thoughts on it. What does it mean for a business to have agility?

Garima Bajpai: This has a multi-dimensional meaning. My experience comes from large, complex organizations. I can put some perspectives around when I started working with entrepreneurs and the startup ecosystem. What I got to know is that business agility actually goes beyond team or technical activity. It's beyond that working software. When you talk about Agile with a big "A" and a manifesto, a lot of focus has been put around how to deliver working software. But when we talk about business agility, it's more than that. There are various definitions available under various contexts, but for me business agility has three aspects.

The first aspect is how you rethink your operating model. The second aspect is long-term resiliency and that's where practices like SRE come forward and support your organization to have that value feedback loop, that data driven approach. And the third thing is your growth strategy in terms of how you are looking at your continuous product canvas and aligning it with something which is commercially viable. Business agility must focus on these three things. And then you can talk about various aspects and how you can unify and synergize it piece by piece whatever your organization or maturity level is.

Christopher Hendrix: So both of you spoke about delivering value, and I think delivering value quickly is where the term agility really hits home. If you think of physical agility, it's how well can you respond to changes in your environment? How well can you change your path? How quickly can you move ideas or move directions? Because if it takes you seven to 10 years to go from a business idea into actually delivering value, clearly the market, your customers, and everything else has changed around you such that your value proposition is probably not even correct anymore. And the likelihood that you're actually delivering on that value proposition is very low, seven to 10 years later.

There's a great talk that Garima gave about continuous product oriented practices. And one of the things you’ve mentioned is creating a short path or the shortest path to realizing value. A lot of companies these days are reorganizing themselves towards delivering value instead of just producing outputs. Waterfall can be thought of as just delivering various pieces of written documentation and shifting it amongst people until at the end somehow software ends up being birthed. I am interested in reliability engineering because, in the modern software development life cycle, the flow of value tends to be thought of as being finished when you deliver something into production.

I see reliability engineering is continuing this path and thinking about value in actuality as when customers interact with your written software. And so you must have resilience and reliability in order for them to interact and derive value from your software. Are there any other ways that you see kind of reliability as impacting the flow of value, or are there other things after delivery that we might also include in models for the flow of value?

Garima Bajpai: When we talk about the flow of value, I think the concept of value itself is very challenging and overwhelming. A lot of people in organizations find it very difficult to quantify what the value. It's essential and important to have a value reader and to take guidance from project to product. That's the kind of mindset which we have in the continuous product oriented practice. We focus on four things; features, risks, debts, and defects. So your features will create value, but your defects, risks, and debts which you are creating will also have to be part of your value radar. If you don't integrate them, that will create bottlenecks and friction at the end.

What is important to understand is that reliability is one of the components of your value radar and how you actually measure that value throughout in a unified way by designing some matrices is a challenge. You have to look at these four aspects and try to kind of integrate this in the entire value chain. That's where you will be able to identify the flow and expedite where the gaps are. And of course, do not over-deliver value to the customer. That's also essential and important. If you want to have a quick time to market, you have to assess what kind of risk and liabilities you're carrying by just not over-delivering value.

Christopher Hendrix: What's an example of over delivering value?

Garima Bajpai: So I talk to entrepreneurs on an ongoing basis. I was talking to one of the entrepreneurs who's actually developing and envisioning to deliver experiential news. Now, when you start deciphering that idea and you want to put perspectives around what kind of features you would have, what your minimum viable product is, you need to have a user segmentation in mind. If you don't have a clustering of user segmentation, you don't have a strategy how you can build those features quickly and get validation through your value feedback loops. Then it will be a problem for you at the end despite what a good idea it is.

What I have kind of interacted with is there are three types of entrepreneurs in this ecosystem. One is at the inception stages where they have this emotional journey of being connected to that idea, and deciphering it and making it big. But throughout this journey, they fail to build enough consensus with the investors and with the shareholders to put that idea to the market. I have talked to several entrepreneurs in that domain. The second life cycle we have seen is that entrepreneurs who are actually able to ship the product out, but are having challenges building consensus with their own team. How should your design team work with that feature, how should the development teams work, what kind of incremental funding investments do you need for developing this particular feature against another feature?

That's where a lot of entrepreneurs are getting stuck. Simplifying that value radar, making it measurable, always helps people to build consensus. The third and the last type is when people launch their products and then they say, "Okay, now we have launched the product." But the job has not ended. The job has just started, because you have so many other ideas. So how do you fine tune your product values? How you fine tune your product canvas is another challenge. And there is where you have to have that bigger picture view of what flow matrices you have and how you ensure that you build reliability as one of the value components.

Christopher Hendrix: We'll definitely be talking about collaboration later. One of the other things that was really interesting is the idea of incremental funding. That's one of those practices that comes with business agility beyond just software development agility. In order to be truly agile as a business, you need to combine and look at the agility of all of your business systems, including how you fund projects. Jason, I'd like to open up the same questions to you, where do you see reliability as fitting in to the concept of delivery of value?

Jason Fraser: As Garima said, the job doesn't stop at delivering software. Our goal is not to deliver software. Our goal is to have a functioning business that provides value to humans and that provides value back to the company that we're working with. If we allow our development and product teams to think, "Okay, I do this for a little while, and then I push to prod, and then I wash my hands and I walk away," that's output oriented thinking. That is exactly the antithesis of how we want to think about delivering products, because nobody cares about technology. I don't wake up in the morning and go, "I'm going to use my iPhone today." I wake up in the morning and go, "I'm going to check the weather."

If I just had an iPhone in my hand but it didn't actually do anything for me, the technology people could be very happy. Apple could be very happy that I spent $800 or whatever they are now. But I'm not going to be very happy, right?

If we can get to a place where our business as a whole, to align on the fact that their job is not to deliver code, their job is to deliver value, then nobody gets to pat themselves on the back if they ship something that doesn't provide any value.

There is no after delivery. Continuous delivery is a thing for a reason. When you've got a SaaS product especially, you're always building. I don't know how familiar people are with models like the Kano model, but it's a model that shows how the perception of feature value changes over time. Initially, there might be product features that customers consider to be delighters and other product features that customers consider to be baseline, like your thing has to do this or it's not even a viable product. And the model shows that, over time, features that were originally considered to be delighters on the map move towards a more commoditized place.

So what was once a delighter becomes a baseline feature. That means, if you don't want your product to just slide down the hill into a commodity space where the only place you can fight is over price, you have to be continually understanding your customer's perception of value so that you can include those delighter features and keep building on that. And hopefully you're removing things from your product as well. As a PM, my favorite moment is when I have clients who delete things from their backlog or delete things from their code base. It doesn't happen enough.

Christopher Hendrix: As an engineer, I will say that is also one of my favorite things. It doesn't happen as often as it should, but not using something because it's no longer providing values is a part of the reaping process of a value-oriented practice. I would love to talk about producing value versus producing outputs. I know that companies will often undergo a transformation in order to reorient themselves from producing outputs to producing value. Oftentimes we get stuck in systems where the only way we know how to operate is just by doing the work that's in front of me. I write the code. I throw it over the wall.

That hampers our ability to remain agile. It hampers our ability to think of value delivery as a whole and to respond to changes, and then deliver new value based on those changes. Jason, you co-founded the innovation and transformation practice back at Pivotal. When a company sees the writing on the wall, they often try to buy a transformation off the shelf. I'm interested in your take on whether or not a company can buy a transformation.

Jason Fraser: If you could buy a large volume of humans who understand, believe in, advocate for, and make decisions that are aligned with your vision of that transformation, if you could just buy this giant team of people who were capable of doing this, then yeah, you can buy a transformation. And some companies try that, right? Some companies will acquire an organization in order to bring in a capability that they don't already have. Depending on how they treat that acquisition, that can go well or it can not go so well. But ultimately transformations are not about technology. They're about the humans, and the humans have to understand and believe in what you're moving towards. Otherwise, nothing changes. We've seen fad transformations a thousand times over and they only work if people believe it.

Garima Bajpai: I would like to agree with what Jason said, and also bring one more context to it. When we talk about business agility, we also have to talk about rethinking your operating models. Until you start these transformations either outside-in or inside-out, you need to change the rules of the game and bring in new business models. The transformations which we do have a purpose, a reason, right? So your transformation should be able to bring new capabilities to the organization. Your transformation should be focused on the people assets. Your transformation should be aware that every organization will have unique challenges. And today's transformations are becoming more and more challenging because there is limited support from a literature perspective on how to do these transformations that are experiential in nature, which are based on newer practices like SRE and DevOps.

Every organization has to explore the potential of those transformations. And in the process, these transformations are becoming short in cycles and incremental. Also they're based on experimentation failures and creating new knowledge and new learnings. That new knowledge and new learning will have to be adopted in the organization. This becomes easier when these transformations are inside-out. But I don't deny the fact that you can bring people from outside, but you will only be able to bring them when you change the rules of the game. You have to bring them as partners. You cannot bring them as vendors.

Christopher Hendrix: That hits very close to home about being a partner in someone's transformation. Our most recent SRE leaders panel was actually about SRE being an organizational transformation effort. One of the things that I think people dislike about big "A" Agile is that leadership will see the writing on the wall, see that something needs to change, and so they'll choose a practice off the shelf and impose it on an entire organization. And then it becomes more about how well you are practicing the thing as opposed to how well you are unlocking the outcomes that were the reason why the organization was interested in transforming.

Some of our ICs in the audience might actually be a part of an organization that's currently undergoing this kind of thing transformation. I'm interested if either of you have any advice how someone who is a part of a transformation movement can hold leadership accountable to not do it thing-oriented, but instead do it outcome-oriented?

Jason Fraser: There's a lot to unpack there, because first, people have to be capable of discerning the difference between an output and an outcome. A lot of people have never been in a place where they really had to think about that. The corporate West is based on factory-like principles, right? You are assigned work, you do the work, you throw the work over the wall and you get paid. It's a very simple equation. And there isn't a lot of responsibility for the value on the other side of that wall, which we keep coming back to. And when you don't have that responsibility inherent in the work that you do, people tend not to think about it.

They tend to think, "I have to do X thing by the end of the week. That's my job." And that is output-oriented thinking. So one of the exercises that we do with people is we have a little worksheet that has a mix of statements on it that are outputs and the outcomes. And we have people check a box next to the statement. Is this an output or is it an outcome? People go through, read, and check the boxes, and then we have a conversation afterwards and we talk through each one. And it's really enlightening for people to see that the thing that they've always been working towards actually is just a thing.

These transformations that you described as thing-oriented transformations are really, again, about enacting the ritual of transformation without necessarily understanding the value that you're trying to drive. Being really pragmatic, you can do any kind of ritual you want. That part doesn't matter at all as long as it gets you to the outcome that you're trying to achieve.

Garima Bajpai: I agree with Jason. I also want to bring one other perspective because I belong to a complex, large organization, and when you start a dialogue with leadership, I think it's also about how you make them successful with this discussion about output and outcome. So what we essentially do is I look at how to reduce the cost of each value point. Let's have a discussion on that.

Once you actually put some kind of tangible valued items to where your stakeholders belong, then it becomes a more easier discussion. Then you can discuss value, what it means for an organization, how we will reduce the cost of that value over a period of time, your incentives and how you build those incentives for shared goals and objectives. Lastly, you can discuss how you generate value for the shareholders in continuum. That's where you will get buy-in and support from the leadership. Start steering their goals and objectives into the outcome you are actually trying to build or generate.

Christopher Hendrix: Yeah, really working with leadership to get them to reorient their own thinking towards outcome thinking as opposed to output thinking by allowing them to tie in what they know about. And using that to understand the cost to deliver value as opposed to the cost to deliver output. It opens up this wonderful world where everyone's actually aligned on what it means to be delivering value and what the risks and costs are. I'd like to move us back into the SRE space. One of the things that reliability engineering or SRE practices has taught people is the importance of managing production incidents.

They happen. Anytime you've released software, you end up finding out that one of your customers has degraded service. One of your customers can't derive value from your product. In the old days, that was handled by a support engineer or an on-call ops person who was often siloed from the rest of the organization. A lot of maturity in the SRE space is rethinking those models and how production incidents work, how people are communicating to each other, and to customers.

And one really interesting thing that I've seen in the SRE space is that the crisis that's generated from a production incident actually clears away organizational silos. You end up co-locating people in a war room, for instance, to handle a production incident. It doesn't matter your seniority, it doesn't matter your reporting structure. I would call what is generated out of this a balanced team approach, or a collaborative model. Can either of you talk to what collaboration really means functionally, and how SRE or production incidents help us think about collaboration?

Garima Bajpai: I want to connect the SRE practices, the collaboration between operations teams and other people. Collaboration happens when there is a shared goal and objective. So when there is an incident or SLA breach, everybody's impacted. I think that understanding and awareness and practices like SRE—building up those error budget policies—would help you align the organization. Practices like observability, which builds predictability in your own operational space, would also stitch the gaps and bring people together.

These kinds of new, modern practices help us to collaborate better. One more aspect which I have seen lately that has a big value when we talk about it in the context of SRE is value stream mapping. When you think about value stream mapping and connecting that dot with how you build your error budgets and how your SLAs are contracted, you integrate and come together to build a modern contract with your users, with your customers, and with your stakeholders. This will naturally help your teams to work together.

Jason Fraser: Garima mentioned these crisis moments causing teams to recognize they have a shared goal. Then you follow it up with other things about alignment. I think alignment is really a core theme to all of these transformative efforts, and to working together. Ultimately, if you think about it at the abstract level, collaboration is about alignment as well.

You mentioned these crisis moments where people come together and deliver in ways that they might not normally do. We break those organizational silos. And you related that to balanced teams. I think there are two things to talk about here. One, yes, that's what a balanced team looks like. If we think about extreme programming, which is a flavor of Agile software development, they looked at practices of software development like writing tests. They said, "Okay, if writing tests is good, why don't we write tests all the time? So we're going to do test driven development now." Or they looked at code reviews and they said, "If code reviews are good why don't we do code reviews all day every day? So we'll do pair programming."

This is analogous to when we see a team come together in a crisis moment in a way that we don't normally see them come together. They go in and they crush that crisis. Well, if that's good, why don't we do that all the time? Why shouldn't our operating model normally be that we all work together with no silos? PMs, designers, engineers, business people, marketing people, and whoever needs to be there in order to drive the value should be there. Balanced teams have been around as a concept for a long time, like 12 or 15 years. It started with a fairly small group of people who were trying to think about how we can incorporate product management and design into Agile engineering, because, as Agile was first starting up, it was a very engineering-focused practice.

One of the early members of that group was a guy named Tim McCoy. He coined this term product stewardship in contrast to product ownership. Product stewardship is about all of us being aligned on the value we're trying to deliver with our product, and all of us from our different roles contributing to steward that value with the product. If a thing works well in a crisis, maybe it works well all the time. One of the things that crisis mode triggers is a re-evaluation of risk, because suddenly there's one thing that really matters and there's a whole lot of other stuff that just doesn't matter that much.

It's easier to break down those silos because all of the risks that we ascribe to working together in this way are subordinated. We've got a tiger in our face, and we have to deal with that tiger right now. All these other little cats around here, they don't matter. That's an opportunity for us all to go, "Maybe those other cats don't matter all the time. Some of them might be on the big side, there might be a link in there somewhere. We want to watch out for the links of the mountain lion, but none of them are really the tigers that we thought they were."

Christopher Hendrix: I see the balanced team, XP practices, Agile practices, starting with engineering, then being driven to adopt product and design as part of their balanced teams. Then people go further and say, "What about bringing business folks in? What about bringing marketing folks in?" We've heard the terms like shift left and that has been ascribed to various transformational movements in DevOps. It was, shift ops left, shift security left, which really just means bringing them in earlier into the process, and bringing them in earlier is really just another way to say have them collaborate sooner and earlier.

So instead of the traditional software development model, why don't you just start with all of those folks in the same room, talking to each other every single day, working on incremental slices of value and delivering them? That's really what these production incidents do. You suddenly get a customer support person in the same room as someone from sales who's in the same room as your communications and marketing manager and your backend engineers. It really acts as this aligning function where suddenly you're like, "Oh yeah. It turns out that that piece of software that we wrote actually does deliver value to our customers. And what was the value that it delivered? And are we continuing to deliver that value if they are unable to access it?"

Let’s move into our Q&A section now. Our first one is, "How do you define debt in context?" Garima, you were talking about a value framework including risks and debts when you're looking at a particular value stream. What do you mean by debt?

Garima Bajpai: I have visualized that debt is created by temporized workarounds, which are created for quick product decisions or product shipment, or maybe to solve some kind of an urgent issue. That's how you lift up your debts. It's an important aspect of your product, and it should not be overlooked. It should be part of your value design matrix. And with that, we also have to focus on risks and the other aspects of feature delivery. So that's where technical debts grow.

Christopher Hendrix: My understanding from what you were talking about was like, if you are trying to have an accurate portrayal of the value of a particular engineering solution, when you're doing accounting principles, you can't just look at the value without also looking at the costs or the potential costs. Risk is one of those potential costs, and any built-up technical debt or any other form of debt is another one of those potential costs where you need the holistic picture in order to understand a particular feature.

Garima Bajpai: That's correct. It is also tightly connected with your value delivery because all the risks, debts and defects which you are creating will create zero value to the end user. It's something that you have to get rid of because it's overcoming the risk, overcoming the bottlenecks for reducing the shippable time of the product. The features are the ones which create value. And that's where your teams have to focus. But without actually having that clear identification view and strategy on how you will reduce debts, risks, and defects, you will not be able to achieve that.

Christopher Hendrix: We've got another question: "Thanks for the explanation on product stewardship. What are the panelists' thoughts on the importance of observability in regards to product stewardship?"

Jason Fraser: My assumptions are that it's around performance. How is your site performing from an engineering perspective? This is different from “how is your site performing from a product perspective.” Although they’re related, obviously, because if your thing doesn't work then you're not delivering value, which I think is the whole point of SRE.

And monitoring is about stability and the tool actually being live and functioning, and people being able to access it. So how does that relate to product stewardship? Historically, we haven't thought enough about that. Even from an enlightened product management perspective, we still think more about our customer-oriented metrics than we do about the performance of the actual site. And the clients that I have right now produce tools that literal lives count on. We've had to retool our product thinking to think not just about, can the user do the thing that we want the user to do in the interface, but can the user do the thing that we want them to do because the product is actually available for them to do it.

We've had to think up some pretty tricky mitigations for communications lines being down or managing a cloud-based tool when you're separate from the cloud. That's been a new thing for us that I think is probably new for a lot of people. There's still been a bit of a disconnect between product thinking and the site reliability side. We leave that to the operators, right? They get to monitor stuff, that's their job, but I feel like that's just throwing value over another fence. And I don't think that's the right thing to do.

Garima Bajpai: I want to add something here and give you a simple analogy. When my daughter was born and she was really kind of young, six-months-old, I used to monitor her. And I used to monitor her on a daily basis, on an hourly basis, on even seconds, right? But now she's six-years-old so neither I have the need to monitor her nor does she require to be monitored. What I do is I observe. Now I let her do her job, but we are observing if something happens externally which is showing the sign that's something I need to intervene with.

It's the same kind of concept. From a software perspective, if your product is nimble, it's in the inception stages, you would prefer to have monitoring rather than observability, but when you actually grow and mature, you will trust the product itself and you can bring observability. You can bring those components where it becomes a mechanism for you to assess the maturity of the product, of your design practices, of your architecture. And that's where I think a lot of value is created.

Christopher Hendrix: I see this in the way where we talk about how you slice the pyramid. Do you slice it horizontally or do you slice it vertically? We used to operate for such a long time where the product was built and then after it was built, you cared about the quality of the products. And so you wrote tests after, you started doing tests after. After you checked quality, you maybe thought about monitoring solutions and so you hooked up some metrics to it. All of these things that happened after the fact, and that was all part of your production readiness checklist. These days, observability is a key portion of appropriate product stewardship. Your product stewardship must include an observability strategy that you actually think about as part of the inception of a product or inception of a value stream.

Shifting left does wonders for both alignment and also ensuring that you're not going to get caught in a situation that's really uncomfortable later when you realize that you didn't include observability or monitoring solutions. Being more proactive about resilience and reliability is really a key component of modern product stewardship.

I wanted to come back to the idea of incremental funding which we spoke on briefly before. What is incremental funding and why is it an interesting practice that actually unlocks business agility?

Garima Bajpai: When you talk about incremental funding or the capital structures or the commercial strategy, they're all connected. What needs to happen is we need to have some kind of data-driven decision points, some kind of data stories which you can create where you can translate your decision-making into an incremental funding model. A lot of companies are talking about building a data strategy. That's a prerequisite. When you talk about an incremental funding model, you will have to look at the data-driven strategy you have in the organization, how to interpret that data, what kind of data stories you have, and if you can bring those data stories to the leadership team.

From a leadership perspective, I think it's equally important not only to build a capital structure which is incremental in nature, but also how to put that commercial strategy in place which is directly connected to your MVPs. You'll have to justify the return of investment of this particular MVP which you have created. If we get to a stage where we are all accountable for putting together these data stories and data points, I think we will be able to steer incremental funding and breaking down the capital structure silos which we have created from the past.

Christopher Hendrix: I want to make sure we also define what incremental funding is versus what it used to be. And I'll pose that to Jason when you talk about your answer.

Jason Fraser: Incremental funding stands in contrast to something like annual budgeting or things where you might say, "Well, we're going to give this team X amount of money for a year or two years or three or five. And then we're not going to think about it."

Incremental funding, where I come from with this take is from the Eric Ries School of Lean Startup. And one of the things that they implemented was this concept of growth boards. Growth boards were intended to be a mechanism for doling out incremental funding in order to direct your funding towards things that were being successful and to not waste your money on things that are not being successful.

The concept came from venture funding with startups. You've got a venture fund. You're going to meet with a bunch of startups and you're going to say, "I'm willing to drop $250K there. I'm going to put $500K there and a million there." And that gives each of those startups some runway. It gives them space to work. So they go and spend that money and, in a few months, they're going to come back and they're going to say, "Okay, we're ready for another round." But they have to prove to you as an investor that what they've been working on has actually been moving them forward.

This gets to some of the value metrics that Garima talked about, They need to demonstrate that they're on the right path. And what so often happens with large enterprises is that a project gets conceived and sanctioned and budgeted, and then ignored. Projects that are not generating any value can go on for years sucking away resources from the organization that could be spent doing things that actually matter.

Christopher Hendrix: I think that puts us at time. I'd like to thank all of our attendees for joining. I'd like to thank our panelists for participating. See you next time.